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.
I tried the wine
method but it didn't work. After installing the mono
and gecko support the wine wanted I got the following message from the
driver setup.
wine64 DWA-192_V1.03b04/Setup.exe
fixme:winediag:start_process Wine Staging 2.0-rc5 is a testing version containing
experimental patches.
fixme:winediag:start_process Please mention your exact version when filing bug reports on
.
fixme:service:scmdatabase_autostart_services Auto-start service L"MountMgr"
failed to start: 2
wine: Bad EXE format for Z:\usr\local\downloads\dwa192\DWA-192_V1.03b04\Setup.exe.
The messages were the same irrespective of whether I used wine64 or wine.
wlp4s6 may not be correct according to the naming conventions but that
is the device that was generated under both F23 and F24.
regards,
Steve