On 29.01.2017 22:42, Stephen Morris wrote:
> On 27/01/2017 21:20, poma wrote:
>> On 26.01.2017 22:12, Stephen Morris wrote:
>>> On 24/01/2017 15:12, poma wrote:
>>>> On 23.01.2017 21:14, Stephen Morris wrote:
>>>>> On 23/01/2017 08:27, poma wrote:
>>>>>> On 22.01.2017 21:49, Stephen Morris wrote:
>>>>>>> On 23/01/2017 00:43, poma wrote:
>>>>>>>> On 21.01.2017 21:00, poma wrote:
>>>>>>>>> On 17.01.2017 22:12, Stephen Morris wrote:
>>>>>>>>> [...]
>>>>>>>>>> The lsusb output for that device is also below.
>>>>>>>>>>
>>>>>>>>>> Bus 010 Device 002: ID 2001:331a D-Link Corp.
>>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> D-Link DWA-192 - Realtek RTL8814AU WiFi USB 3.0
>>>>>>>>>
>>>>>>>>>
https://wikidevi.com/wiki/D-Link_DWA-192
>>>>>>>>>
http://support.dlink.com/ProductInfo.aspx?m=DWA-192
>>>>>>>>> ftp://files.dlink.com.au/products/DWA-192
>>>>>>>>>
https://openitforum.pl/index/recenzje/karty/d-link-dwa-192-r225
>>>>>>>>>
>>>>>>>>>
https://wikidevi.com/wiki/Edimax_EW-7833UAC
>>>>>>>>>
http://www.edimax.com/edimax/download/download/data/edimax/global/downloa...
>>>>>>>>>
http://www.edimax.com/edimax/mw/cufiles/files/download/Driver_Utility/EW-...
>>>>>>>>>
>>>>>>>>>
https://github.com/pld-linux/rtl8812au
>>>>>>>>>
https://github.com/diederikdehaas/rtl8812AU
>>>>>>>>>
>>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>
>>>>>>>>> $ unzip EW-7833UAC_linux_4.3.21_kernel_3.16-4.4.zip
>>>>>>>>> $ cd
EW7833UAC_linux_4.3.21_kernel_3.16-4.4/EW7833UAC_linux_v4.3.21_17997.20160531/
>>>>>>>>>
>>>>>>>>> $ curl -s
https://raw.githubusercontent.com/pld-linux/rtl8812au/master/disable-debu... | patch
-p1
>>>>>>>>> $ curl -s
https://github.com/diederikdehaas/rtl8812AU/commit/e6d6beb.patch | patch -p1
>>>>>>>>> $ curl -s
https://raw.githubusercontent.com/pld-linux/rtl8812au/master/linux-4.7.patch | patch -p1
>>>>>>>>> $ curl -s
https://raw.githubusercontent.com/pld-linux/rtl8812au/master/linux-4.8.patch | patch -p1
>>>>>>>>>
>>>>>>>>> $ make -j3
>>>>>>>>> $ su
>>>>>>>>> # cp 8814au.ko /lib/modules/$(uname -r)/updates/
>>>>>>>>> # depmod
>>>>>>>>> # modinfo 8814au | grep 2001
>>>>>>>>>
>>>>>>>>> # modprobe -v 8814au
>>>>>>>>> # dmesg:
>>>>>>>>> ...
>>>>>>>>> RTL871X: module init start
>>>>>>>>> RTL871X: rtl8814au v4.3.21_17997.20160531
>>>>>>>>> RTL871X: build time: Jan 21 2017 20:04:38
>>>>>>>>> usbcore: registered new interface driver rtl8814au
>>>>>>>>> RTL871X: module init ret=0
>>>>>>>>> ...
>>>>>>>>> # modprobe -rv 8814au
>>>>>>>>> # dmesg:
>>>>>>>>> ...
>>>>>>>>> RTL871X: module exit start
>>>>>>>>> usbcore: deregistering interface driver rtl8814au
>>>>>>>>> RTL871X: module exit success
>>>>>>>>> ...
>>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>
>>>>>>>>> Wifi ball works now?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> HW add.
>>>>>>>>>
https://wikidevi.com/wiki/ASUS_USB-AC68
>>>>>>>>>
https://www.asus.com/Networking/USB-AC68/HelpDesk_Download
>>>>>>>>>
>>>>>>>>>
https://wikidevi.com/wiki/TP-LINK_Archer_T9UH
>>>>>>>>>
http://www.tp-link.com/en/download/Archer-T9UH.html
>>>>>>>>>
>>>>>>>>>
https://wikidevi.com/wiki/TRENDnet_TEW-809UB
>>>>>>>>>
https://www.trendnet.com/support/supportdetail.asp?prod=100_TEW-809UB
>>>>>>>>>
>>>>>>>>> SW add.
>>>>>>>>>
https://github.com/abperiasamy/rtl8812AU_8821AU_linux
>>>>>>>>>
https://github.com/austinmarton/rtl8812au_linux
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> OR
>>>>>>>> according to "rtl8814au? #10"
>>>>>>>>
https://github.com/diederikdehaas/rtl8812AU/issues/10
>>>>>>>>
>>>>>>>> $ git clone -b driver-4.3.21
https://github.com/uminokoe/rtl8812AU.git RTL8814AU-uminokoe
>>>>>>>> $ cd RTL8814AU-uminokoe/
>>>>>>>> $ git revert -n 9260f77 8d33100
>>>>>>>> // "Disabled debugging code."
>>>>>>>> $ curl -s
https://github.com/diederikdehaas/rtl8812AU/commit/3e80ebc.patch | patch -p1
>>>>>>>> // Enables CONFIG_MP_VHT_HW_TX_MODE
>>>>>>>> $ sed -i '/CONFIG_MP_VHT_HW_TX_MODE/s/n/y/'
Makefile
>>>>>>>> $ sed -i '/CONFIG_MP_VHT_HW_TX_MODE/s/#//'
Makefile
>>>>>>>>
>>>>>>>> OR
>>>>>>>> $ git clone
https://github.com/diederikdehaas/rtl8814AU.git RTL8814AU-diederikdehaas
>>>>>>>> $ cd RTL8814AU-diederikdehaas/
>>>>>>>> // Adds missing Vendor/Product ID
>>>>>>>> $ sed -i '/0xA834/ a\\t{USB_DEVICE(0x7392, 0xA833),
.driver_info = RTL8814A}, /* Edimax - Edimax */' os_dep/linux/usb_intf.c
>>>>>>>> // "Added VHT capabilities."
>>>>>>>> $ curl -s
https://github.com/uminokoe/rtl8812AU/commit/5f75242.patch | patch -p1
>>>>>>>> // Enables CONFIG_MP_VHT_HW_TX_MODE
>>>>>>>> $ sed -i '/CONFIG_MP_VHT_HW_TX_MODE/s/n/y/'
Makefile
>>>>>>>> $ sed -i '/CONFIG_MP_VHT_HW_TX_MODE/s/#//'
Makefile
>>>>>>>>
>>>>>>>>
>>>>>>>> $ make -j3
>>>>>>>> $ su
>>>>>>>> # cp 8814au.ko /lib/modules/$(uname -r)/updates/
>>>>>>>> # depmod
>>>>>>>> # modinfo 8814au
>>>>>>>>
>>>>>>>> # modprobe -v 8814au
>>>>>>>> # dmesg:
>>>>>>>> ...
>>>>>>>> RTL871X: module init start
>>>>>>>> RTL871X: rtl8814au v4.3.21_17997.20160531
>>>>>>>> usbcore: registered new interface driver rtl8814au
>>>>>>>> RTL871X: module init ret=0
>>>>>>>> ...
>>>>>>>> # modprobe -rv 8814au
>>>>>>>> # dmesg:
>>>>>>>> ...
>>>>>>>> RTL871X: module exit start
>>>>>>>> usbcore: deregistering interface driver rtl8814au
>>>>>>>> RTL871X: module exit success
>>>>>>>> ...
>>>>>>>>
>>>>>>>>
>>>>>>>> Hello Diederik,
>>>>>>>> it seems there are only two Linux RTL8814AU users, so
far.
>>>>>>>>
>>>>>>>> Morris, when you catch some time, would you mind to run a
couple iperf tests with DWA-192,
>>>>>>>> to see real network throughput results.
>>>>>>> I can't run any at the moment because Fedora is refusing
to actually use
>>>>>>> the device at all.
>>>>>>>
>>>>>>> I have also just upgraded to F25 and nothing has changed.
>>>>>>>
>>>>>>> The last time I used this device was on 08/10/2016 and it was
using the
>>>>>>> ATH9K driver. The main reason I upgraded to this USB device
was that I
>>>>>>> upgraded my router to a faster version, and I found that
unlike the
>>>>>>> DWA182 I didn't have to compile my own driver, the kernel
had inbuilt
>>>>>>> support for the DWA192.
>>>>>>>
>>>>>>> It is possible that I have managed to Blacklist the device in
some way,
>>>>>>> not by the conventional Blacklist.conf, and I have forgotten
how so I
>>>>>>> can't find where I've done it to reverse it.
>>>>>>>
>>>>>>> Also, having never done it before, I also don't know how
to run iperf tests.
>>>>>>>
>>>>>>> regards,
>>>>>>> Steve
>>>>>>>
>>>>>> Did I understand you correctly, what you're saying here is
that:
>>>>>> D-Link DWA-192 - Realtek RTL8814AU WiFi USB 3.0
>>>>>> therefore the USB based device, was driven by:
>>>>>> $ modinfo --description ath9k
>>>>>> Support for Atheros 802.11n wireless LAN cards.
>>>>>>
https://wireless.wiki.kernel.org/en/users/drivers/ath9k
>>>>>> "ath9k is a completely FOSS wireless driver for all Atheros
IEEE 802.11n PCI/PCI-Express and AHB WLAN based chipsets."
>>>>>>
https://wiki.debian.org/ath9k
>>>>>> "Atheros 802.11n PCI/PCI-E devices (ath9k)"
>>>>> Yes, when the device was working iwconfig reported the driver as
being
>>>>> ATH9K, but if refused to use the 5GHz channel. Following a suggestion
on
>>>>> this list I tried compiling my own kernel and setting a recommended
>>>>> flag, but that had no effect on its ability to use the 5GHz channel.
It
>>>>> was from compiling my own kernel I found that it looked like the
ATH10K
>>>>> driver would support the 5GHz channel, which Winfried de Heiden is
>>>>> confirming, so at the time I couldn't work out why the system
wasn't
>>>>> assigning the ATH10K driver instead of the ATH9K driver.
>>>>> From what you are saying it sounds like that various updates to
F24
>>>>> (and in F25 which I am using now) have changed the functionality of
>>>>> ATH9K to not support USB devices, which would potentially go a long
way
>>>>> towards explaining why my adapter is no longer recognized any more.
>>>>> Also it seems to me that you are suggesting that I need to go back
to
>>>>> compiling a driver for this card again (if I have to do this will
the
>>>>> driver support the 5GHz channel), if this is so given that from when
I
>>>>> first started using this adapter up until 08/10/2016 there was
native
>>>>> support in the kernel for the device, why has this support been
dropped?
>>>>> I first started using this adapter in F23.
>>>>>
>>>>> regards,
>>>>> Steve
>>>> This should show the WiFi devices that are connected to the machine:
>>>> $ echo ; lspci -knn -d ::0280 ; echo ; lsusb ; echo ; lsusb -t ; echo
>>>>
>>>> Would you mind copy and paste the output here.
>>> I have input the commands and the output is listed below.
>>>
>>> echo ; lspci -knn -d ::0280 ; echo ; lsusb ; echo ; lsusb -t ; echo
>>>
>>>
>>> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>>> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 005 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
>>> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 004 Device 002: ID 045e:0750 Microsoft Corp. Wired Keyboard 600
>>> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>>> Bus 011 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>>> Bus 010 Device 002: ID 2001:331a D-Link Corp.
>>> Bus 010 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>>> Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>>
>>> /: Bus 11.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
>>> /: Bus 10.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
>>> |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=, 480M
>>> /: Bus 09.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
>>> /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
>>> /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/4p, 12M
>>> /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
>>> /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/5p, 12M
>>> |__ Port 2: Dev 2, If 0, Class=Human Interface Device,
>>> Driver=usbhid, 12M
>>> |__ Port 2: Dev 2, If 1, Class=Human Interface Device,
>>> Driver=usbhid, 12M
>>> |__ Port 2: Dev 2, If 2, Class=Human Interface Device,
>>> Driver=usbhid, 12M
>>> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/5p, 12M
>>> |__ Port 1: Dev 2, If 0, Class=Human Interface Device,
>>> Driver=usbhid, 1.5M
>>> |__ Port 1: Dev 2, If 1, Class=Human Interface Device,
>>> Driver=usbhid, 1.5M
>>> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M
>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
>>>
>>> Bus 010 Device 002 is the usb wifi adapter that is not recognized anymore.
>> Bus 10 Device 2
>>
>> lsusb:
>> Bus 010 Device 002: ID 2001:331a D-Link Corp.
>>
>> lsusb -t:
>> /: Bus 10.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
>> |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=, 480M
>>
>>
>> 8814au.ko when built, installed and loaded,
>> should show up as assigned to the device:
>>
>> /: Bus 10 [...]
>> |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=8814au, 480M
> I can rebuild that driver like I was with the DWA-182 usb device when I
> had it, but when I purchased the DWA-192, under Fedora 23 there was
> native support for DWA-192 in the kernel, hence I did not have to
> compile a driver anymore. At the time I also raised a Bugzilla around
> the fact that the ATH9K driver (which is the driver the commands I
> issued at the time, that I was advised to on this list, told me was the
> one being used) did not provide access to the 5 GHz channel. That driver
> was being used through F23 and F24, or at least native kernel support,
> was provided up until 08/10/2016 at which time I switched over to an
> Ethernet Home Plug interface to networking (this was because the device
> became problematic in retaining connection to the network).
> Now that I have switched back to the wifi device, because even on the
> 2.4 GHz channel this wifi device is faster than the Ethernet device, I
> have found that the DWA-192 device appears to no longer be supported
> natively by the kernel.
> Why has support for this device been removed from the kernel? As a side
> issue to this, I have also noticed that this device has exactly the same
> non-support issue under Ubuntu 16.10.
>
"Dlink DWA-192 not Properly Supported"
https://bugzilla.redhat.com/show_bug.cgi?id=1346465
Apparently Fedora Kernel Team know less than you there ;)
Morris, would you mind try to read the following lines with care and understanding;
= DWA-192 win driver location:
http://support.dlink.com/ProductInfo.aspx?m=DWA-192#Download
ftp://ftp2.dlink.com/PRODUCTS/DWA-192/REVA/DWA-192_REVA_DRIVERS_1.03.B04_...
= A brief review of the aforementioned driver,
part of the installation via Wine -
https://winehq.org
$ unzip DWA-192_REVA_DRIVERS_1.03.B04_WIN.ZIP
$ wine DWA-192_V1.03b04/Setup.exe
...
See "Wine installation RTL8814AU D-Link DWA-192.png" (attachment)
...
$ dos2unix < ~/.wine/dosdevices/c\:/Program\
Files/D-Link/DWA-192/Drivers/Win7x86/D_netrtwlanu.inf | grep '8814AU\|2001\|331A'
%DWA-192_331A.DeviceDesc% = RTL8814auDLink.ndi, USB\VID_2001&PID_331A
;; Dlink 8814AU installation
DWA-192_331A.DeviceDesc = "D-Link DWA-192 AC1900 Wi-Fi USB 3.0 Adapter"
DWA-192_331A.DeviceDesc.DispName = "D-Link DWA-192 AC1900 Wi-Fi USB 3.0
Adapter"
= Conclusion:
D-Link DWA-192 AC1900 Wi-Fi USB 3.0 Adapter -is- related to Realtek RTL8814AU 4T4R
802.11ac, USB 3.0 Chipset,
which again correlates with the Linux kernel case - 8814au.ko.
~~~~~
"Dlink DWA192 Partially Supported in Kernel?"
https://lists.fedoraproject.org/archives/list/users%40lists.fedoraproject...
What you mentioned in this thread - "4.3.5-300 kernel", can be found here:
https://kojipkgs.fedoraproject.org/packages/kernel/4.3.5/300.fc23/x86_64/
"kernel-core-4.3.5-300.fc23.x86_64.rpm" and
"kernel-modules-4.3.5-300.fc23.x86_64.rpm"
are sufficient for the installation and testing:
# rpm -ivh --oldpackage kernel-*-4.3.5-300.fc23.x86_64.rpm
so that we can examine the output of:
$ networkctl status <IFNAME>
to see the driver assigned to the device
Of course you can repeat:
$ echo ; lspci -knn -d ::0280 ; echo ; lsusb ; echo ; lsusb -t ; echo
and paste the output here, also.
~~~~~
What you also mentioned in the above-mentioned thread -
[...]VNAIKQSTZVULRQKBYR5EDDOMBWRYWXXI
is the name assigned to the device - wlp4s6, which really does not correlates with the
naming scheme, explained here:
"How does the new naming scheme look like, precisely?"
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInter...
https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_...
i.e. "wlp4s6" seems to be a PCI based device, however D-Link DWA-192 is the USB
based device.
Just further to my previous email, I have compiled the 8814au driver
following your instructions above and that has created device wlp3s0u2,
but the network is unable to activate it. The messages from dmesg are as
follows (what I haven't determined yet is whether or not the failure is
because I am currently using the ethernet interface).
[ 1363.001100] usb 10-1: USB disconnect, device number 2
[ 1366.435600] usb 10-2: new high-speed USB device number 3 using xhci_hcd
[ 1366.604162] usb 10-2: New USB device found, idVendor=2001, idProduct=331a
[ 1366.604166] usb 10-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 1366.604169] usb 10-2: Product: 11ac Adapter
[ 1366.604172] usb 10-2: Manufacturer: Realtek
[ 1366.604175] usb 10-2: SerialNumber: 123456
[ 6094.157799] RTL871X: module init start
[ 6094.157802] RTL871X: rtl8814au v4.3.21_17997.20160531
[ 6094.298894] RTL871X: rtw_ndev_init(wlan0) if1 mac_addr=6c:72:20:00:ac:c4
[ 6094.299451] usbcore: registered new interface driver rtl8814au
[ 6094.299452] RTL871X: module init ret=0
[ 6094.384280] rtl8814au 10-2:1.0 wlp3s0u2: renamed from wlan0
[ 6094.404086] IPv6: ADDRCONF(NETDEV_UP): wlp3s0u2: link is not ready
[ 6094.880887] IPv6: ADDRCONF(NETDEV_UP): wlp3s0u2: link is not ready
[ 6094.888146] IPv6: ADDRCONF(NETDEV_UP): wlp3s0u2: link is not ready
[ 6094.940359] IPv6: ADDRCONF(NETDEV_UP): wlp3s0u2: link is not ready
[ 6095.058090] IPv6: ADDRCONF(NETDEV_UP): wlp3s0u2: link is not ready
[ 6095.244405] RTL871X: assoc success
[ 6095.244668] RTL871X: set group key camid:1, addr:00:00:00:00:00:00,
kid:1, type:TKIP
[ 6095.245211] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0u2: link becomes ready
One question I have, in the 8814 instructions above you mentioned:
// Adds missing Vendor/Product ID
$ sed -i '/0xA834/ a\\t{USB_DEVICE(0x7392, 0xA833), .driver_info = RTL8814A}, /*
Edimax - Edimax */' os_dep/linux/usb_intf.c
Should the values inside the USB_DEVICE brackets be the idVendor and idProduct numbers
mentioned in the dmesg output above?
regards,
Steve