Hi Dan, hi all,
On 08/07/15 12:36, Dan Carpenter wrote:
The bug report says that it connects fine. Then in 10 minutes the
connection dies and reconnects. Is connecting an issue for you?
Oh, I was under the impression that the person who connects fine then
loses the connection sporadically had applied out-of-repository patches
-- guess you're right, that bug is a jumbled mess.
Here's what I see on my side. I'll try to be as thorough as I can.
I tried first with the Realtek driver (as in, the one available on my
github repo, that actually works), and scanned for access points using
NetworkManager, then manually with iwlist in order to rule out a problem
with NM. Then I repeated the same operations with the in-kernel driver.
I kept the logs of all cases (attached herein).
With the Realtek driver: the logs for when I load the module are in the
attached file, module-load-realtek.log. The driver itself isn't very
talkative, most of the logs are NetworkManager taking note of the device.
The logs of when I then tell NM to activate WiFi are in
nm-enable-realtek.log.
With that driver, NM scans and finds my access point, and autoconnects
to it.
I verified that after modprobing the driver, I can ifconfig the device
up, manually scan the neighborhood with 'iwlist wlan0 scan', and see the
access point.
Now, with the in-kernel driver. The logs for when I load it are in
module-load-inkernel.log. The logs are somewhat more verbose, though not
that much. I see nothing in there that would explain the problems.
When I then fire up the WiFi from NetworkManager, the logs
(nm-enable-inkernel.log) are mostly identical up until the point where
the interface state goes from ready to inactive. After this point,
however, NetworkManager doesn't see any access point, and stops there.
Once again, I used iwlist to scan for access points. Unlike with the
Realtek driver, this requires turning on the interface with the rfkill
command, but I don't think that's abnormal; I'm assuming this additional
level of control is a benefit of the in-kernel driver. With the
in-kernel driver, however, iwlist sees no access point (No scan
results). iw dev wlan0 scan doesn't show anything either.
There are no errors in the logs or on stderr. It's like the driver and
the wireless tools all think that everything is fine, they just fail to
see any access point, like the device just wasn't listening on its antenna.
Note: this is a slightly different from the behavior I was seeing way
back when I purchased that device and first discovered it was not
properly supported, somewhere around the time of kernel 3.10: back then,
the nearby access points WERE visible, but the connection would fail to
come up, like the device lost interest in listening to its antenna after
a few packets.
The TL;DR of that is the device doesn't work with the official driver
and I have no useful information to provide as to why, which sucks.
Note: I also tried loading the module with the swenc=1 parameter, as
suggested in the bug report thread, but the result was identical.
As well: I dug out a 32 bits bootable image with the same kernel I'm
running (3.19.0). The symptoms are identical to what I see on my 64 bits
kernel. I don't know if that's the expected outcome.
At this point I can only see a few general approaches:
1/ Is it possible dump packets from the wireless interface (with
tcpdump, for instance) before the connection to the access point has
been established? Would such a dump help?
2/ Bisect the in-kernel module until I find the exact patch where things
stopped working. (Do I need to be running that exact kernel version or
can I bisect only the module?)
3/ Get the module maintainer the same device I own and hope they can
reproduce the issue. (Is that a thing that people do?)
Otherwise... I'm kind of stumped.
And Greg wrote:
Why? That's better than you will get from any other operating system,
where you don't have access to the developers who wrote the code, nor
even the company. You have a chance here, much more so than anywhere
else.
I may have misunderstood the spirit of your comment! I thought you meant
that a theoretically supported device staying unusable for upward of two
years was business as usual, which was /definitely/ a discomfiting
thought. :)
Cheers,
-- P.
kernel: rtl8192cu: Chip version 0x11
kernel: rtl8192cu: MAC address: ec:1a:XX:XX:XX:XX
kernel: rtl8192cu: Board Type 0
kernel: rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
kernel: rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
kernel: ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
kernel: usbcore: registered new interface driver rtl8192cu
NetworkManager[829]: info (wlan0): using nl80211 for WiFi device control
NetworkManager[829]: info (wlan0): driver supports Access Point (AP) mode
NetworkManager[829]: info (wlan0): new 802.11 WiFi device (driver: 'rtl8192cu' ifindex: 6)
NetworkManager[829]:
