frustrated by carl9170

frustrated by carl9170

[Brad Bellomo]

I have a NetGear wireless n draft dongle that uses the carl9170 driver
on an Arch system.  This module works for anywhere from several
minutes to several hours.  Then I have lose all ability to use TCP/IP
over my wireless until I modprobe -r carl9170, modprobe carl9170, and
reconnect my network.  Although ar9170usb worked fine, I would rather
troubleshoot this than revert to a deprecated driver, or at worst
case, buy a better supported device.  I do not see anything relevant
in my dmesg log.  Does this device log errors somewhere else?  Is
carl9170 actively being developed?  I don't mind digging into code
myself, but if no one is working on carl9170, I would rather buy new
hardware (recommendations appreciated) than spend time fixing
something with no future.

Re: frustrated by carl9170

[Christian Lamparter]

Hi,

On Monday, January 23, 2012 05:59:18 PM Brad Bellomo wrote:
> I have a NetGear wireless n draft dongle that uses the carl9170 driver
> on an Arch system.  This module works for anywhere from several
> minutes to several hours.  Then I have lose all ability to use TCP/IP
> over my wireless until I modprobe -r carl9170, modprobe carl9170, and
> reconnect my network.  Although ar9170usb worked fine, I would rather
> troubleshoot this than revert to a deprecated driver, or at worst
> case, buy a better supported device.  I do not see anything relevant
> in my dmesg log.  Does this device log errors somewhere else?  Is
> carl9170 actively being developed?  I don't mind digging into code
> myself, but if no one is working on carl9170, I would rather buy new
> hardware (recommendations appreciated) than spend time fixing
> something with no future.
There's not a lot of debug information in your post. e.g.: what's
the exact hardware? From where is the carl9170 driver coming from,
[kernel-version, or compat-wireless?] what's the firmware version?
Furthermore, a bit of background information about your setup wouldn't
hurt either.
[e.g.: What AP (and firmware)? Do you use HT20/HT40? which frequency band
and encryption setting].

When the device "stops". Do you know if it fails to receive
any data or if it has problems with outgoing traffic? Also what
is wpa_supplicant doing at the time when it fails?

The driver itself exports a debugfs interface under
/sys/kernel/debug/ieee80211/phy$X/carl9170

Of course, you are welcome to debug and run experiments on your own.
If you come across something peculiar (which can be reproduced) then
let me know.

Regards,
	Chr

Re: frustrated by carl9170

[Christian Lamparter]

Please keep the CC.

On Wednesday, January 25, 2012 02:39:38 AM Brad Bellomo wrote:
> There isn't much debug information as I was hoping people would help
> tell me how to debug this, rather than trying to debug it for me via
> e-mail.
Ok, but then were do we start? There's a lot more than just a driver
and a firmware that could be buggy. So, if you want to debug this
all by yourself, then be prepared to be frustrated a whole lot more.

> Does this driver log anything outside what I see as dmesg or
> debugfs?
No, the more interesting stuff is logged by the stack above.
You can take a look what the wpa_supplicant is doing in the
syslog [or wpa_cli] and mac80211/cfg80211 has an event viewer
[iw event] and trace points [needs to be enabled in the
kernel config at compile time of course]

> I don't have a debug directory under my kernel, is there
> something I need to do?
There no directory called debug? Well, then I assume that
the "debug Filesystem" (CONFIG_DEBUG_FS) wasn't enabled at
compile time. I'm afraid you have to enable it yourself
and build a kernel. I hope ARCH Linux has a few good wiki-pages
on the subject because you'll definitely need it.

> Is this driver being actively developed or should I just give
> up and buy new hardware?
I think it is :D.  But seriously, if you want to buy something else
go ahead. There's ath9k_htc, but you may end up having the same
problem [so, I would go for cheap products first].

> If it helps:
> 
> I am using a NETGEAR WNDA3100.
Not really, I have three of those and they are working fine in my
setup. Of course, I'm aware that my testing environment is just "mine"
so I won't even think about claiming that the driver/fw will always
work anytime for anyone anywhere.

> The question about outgoing or incoming or both being stopped is a
> good one, but I don't know how to check this.  I won't be able to ping
> to or from the machine either way.
Well, the debugfs interface exports a few statistics like tx and rx counters.
But you could also setup a monitor interface and wait until it dies.
If you still see incoming frames [e.g.: beacons from the AP] you know that
the device is still able to receive. And if you see ACKs and other responses
directed to your device MAC you know that it also sends alright. 
 
> I have replaced both the firmware and driver many times
> troubleshooting this problem, so I don't know where the current driver
> came from, but believe I am using the driver from the 3.0 kernel and
> firmware 1.9.4.  All other versions that I have tried that load (i.e.
> not mismatched driver/firmware) behave the same.
good to know.
 
> I am unsure about HT20/HT40 - I have not messed with this, so it is
> probably the default.
ar9170usb never supported 11n, so you may want to modprobe the module
with a noht=1 parameter to see if it also misbehaves when 11n is
turned off.

Reagards,
	Chr