2357:0100 [Gigabyte 965P-DS3] USB Wifi TP-Link WN8200ND cannot associate to access points

I noticed that my apport file was truncated - I will try to report again with the full file in the evening (after 12 hours).

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1298802

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Peter Schüller, it would be best to just plug the dongle into Precise, have your computer already connected to the internet via ethernet or working WiFi, and then execute:
apport-collect 1298802

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

I connected the 14.04 via cable to a computer that has internet and reported this way, directly with apport-collect from the 14.04.

After that I noticed that the original rtl8192cu module was still blacklisted from installing the patched module (see [1] above).

lsusb shows no device for the 2357:0100

If I remove the blacklisted original module then it is loaded in lsmod but lsusb still does not show more than 2357:0100 ... nothing after that.

Should I run apport-collect again on this issue now that I have removed the blacklist from /etc/modprobe.d/ ?
[Will it replace the files that are already uploaded or add new files?]

Peter Schüller, as a potential WORKAROUND, would using the driver provided by Realtek work via http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true#2772 ?

So far I ignored that particular driver because it specified that it is for a wrong kernel version.

I tried to use that driver, but it does not build because create_proc_entry was deprecated.

Then I checked the diff between the realtek driver and [1], and the only difference is that the procfs code is commented out in [1].

So to summarize:
*) yes, if the realtek driver is patched a bit as in [1] then I can connect to accesspoints
*) but I cannot connect to all accesspoints that I can connect to with another wifi equipment, and
*) for those accesspoints that work, the connection is less reliable than with other wifi equipment.

Peter Schüller, thank you for the requested information.

Could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-3.14-rc8

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

I installed
* linux-headers-3.14.0-031400rc8-generic_3.14.0-031400rc8.201403242335_amd64.deb
* linux-headers-3.14.0-031400rc8_3.14.0-031400rc8.201403242335_all.deb
* linux-image-3.14.0-031400rc8-generic_3.14.0-031400rc8.201403242335_amd64.deb

With that kernel I can connect to my cellphone access point, but not to the other network that allows my laptop to connect easily.

So the situation is better than in the repository kernel, but there is still a bug that needs to be fixed.

(hiding previous comment, will do more research on file downloading, please ignore previous comment [i found no way to delete it])

After some more testing with 3.14-rc8 I can confirm that the situation is just a tiny bit better than in the repository kernel:
* associating to the cellphone accesspoint does not always work and the syslog shows several attempts until it works if it works
* if the connection is there, it is unstable and sometimes disconnects with traffic
* packet loss and ping times are bad (see belowresults for pinging my personal homepage (hosted in switzerland) via my cellphone accesspoint

pinging from the computer with the 3.14-rc8 kernel and the WN8200ND hardware: ping-8192cu.txt

--- www.peterschueller.com ping statistics ---
28 packets transmitted, 28 received, 0% packet loss, time 27045ms
rtt min/avg/max/mdev = 157.014/496.532/2018.405/510.937 ms, pipe 3

pinging from my laptop (centrino ultimate-n 6300 wifi card):

--- www.peterschueller.com ping statistics ---
29 packets transmitted, 21 received, 27% packet loss, time 28101ms
rtt min/avg/max/mdev = 367.968/867.568/4077.452/835.474 ms, pipe 5

So the average roundtrip is actually better with the 8192cu but the deviation is greater and the packet loss is 27% compared to 0%.

When I say "Turn Off" in the network manager, the syslog shows garbled content like a mismanaged buffer or uninitialized memory. I have attached the part of the syslog and a hexdump of the garbled two lines.

Peter Schüller, just to clarify your 3.14-rc8 test, would this be without using your partial WORKAROUND https://github.com/pvaret/rtl8192cu-fixes or with it? The intent of the request is to see if the kernel allows the USB device to work without any end-user modifications (ex. installing Realtek drivers, etc.).

Despite this, the issue you are reporting is an upstream one. Could you please report this problem through the appropriate channel by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked.

Thank you for your understanding.

Yes, this test was done after deinstalling the rtl8192cu-fixes and after removing the module blacklisting for the native module.

I will do the upstream bugreport (hopefully today).

Peter Schüller, regarding https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1298802/comments/22 :
>"With that kernel I can connect to my cellphone access point, but not to the other network that allows my laptop to connect easily."

Could you please advise on the manufacturer, model and firmware version of this other network access point?

This other network is a public access point, I have no access to the hardware but the password was provided to me.

Looking at the logs it shows MAC is 18:28:61:56:ec:bf which gives "AirTies" on the Mac/Vendor lookup http://www.coffer.com/mac_find/

The following syslog line contains some more information about the used protocol:
wpa_supplicant[2689]: WPA: Key negotiation completed with 18:28:61:56:ec:bf [PTK=CCMP GTK=TKIP]

I tried to use the "Use as a Hotspot" option in the NetworkManager and it does not create a hotspot that is visible to my laptop or my phone, also I get garbled syslog messages again when disconnecting. Again the SSID of the SIOCSIWESSID syscall is broken in the syslog.

Mar 31 17:54:16 oldie kernel: [ 2656.279160] =>rtw_wx_set_essid
Mar 31 17:54:16 oldie kernel: [ 2656.279164] ssid=f2^M<B7>1X<A3>Z%]^E^WX<E9>^<U+052B><B2><CD>ƛ<B4>T^Q^N<82>tA!=܇<E0>zs<C2>, len=32
Mar 31 17:54:16 oldie kernel: [ 2656.279167] Set SSID under fw_state=0x00000008
Mar 31 17:54:16 oldie kernel: [ 2656.279177] <=rtw_wx_set_essid, ret 0

I think this is a duplicate of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1186253 which was closed because the reporter gave up and changed his hardware ...

Meanwhile I tried ndiswrapper without success:

ndiswrapper from ppa:crass/ndiswrapper https://launchpad.net/~crass/+archive/ndiswrapper on kernel 3.11.0-20-generic #34~precise1-Ubuntu SMP Thu Apr 3 17:25:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

I downloaded the vendor drivers from http://www.tp-link.com.de/support/download/?model=TL-WN8200ND&version=V1 where I used the newest version TL-WN8200ND_V1_131119

After installing ndiswrapper and unpacking the windows drivers I created symlinks such that the path to the .inf file does not contain spaces (I found a hint online that ndiswrapper fails with spaces in the path).

I tried all four 64bit driver versions with the following result:
* winxp driver is detected as valid driver by ndisgtk, plugging in the USB dongle shows the log line of the USB connect in the syslog and then the whole computer freezes, no CTRL+ALT+DELETE works, no CTRL+ALT+F1 works. after rebooting more lines of the syslog are missing

* windows vista and windows 7 drivers are detected as "invalid driver" by ndisgtk

* windows 8 driver is detected as valid driver, plugging in the USB dongle gives errors in the syslog (see attached ndiswin8syslog.txt) but the computer does not freeze but the dongle also does not work, no network device appears

(I have also blacklisted the native modules to make sure they do not interfere.)

I have the same issue with
Bus 001 Device 002: ID 0b05:17ab ASUSTek Computer, Inc. USB-N13 802.11n Network Adapter (rev. B1) [Realtek RTL8192CU]

Wolfgang Schupp, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Not sure why opening a duplicate of this bug would make sense. I have the same chipset and exactly the same issues as the reporter.

If you still want me to open a new bug, I can ofc do that.

Is there anything I can do to help with this problem?

The hardware is still effectively unusable for me and I tried every possible workaround (except for giving up on Linux which is not an option).

Hi! Same bug affects me. Any update on this thread? Regards!

Santiago, it will help immensely if you filed a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.