[ath9k-devel] Bizarre one-way connectivity using ath9k

[Pavel Roskin <proski@gnu.org>]

On Tue, 2009-08-11 at 16:30 -0700, Patrick McMichael wrote:
> All,
> 
> 
> Hello I am new to the list and apologize if I am breaking etiquette,
> I've been searching on google for days to solve this annoying problem
> but maybe I just haven't hit upon the right search terms yes.  I'm
> hoping you can help because you probably know more about these
> wireless cards than anyone else, even the manufacturers.

No need to apologize.  Not all problems are widespread, some are rare.

> Anyway, my problem is this.  My card is recognized, ath9k is loaded as
> kernel module and the machine successfully obtains an IP-Address lease
> from the DHCP server, all without problem.  My machine (varie) has
> full connectivity to the local subnet and to the beyond (internet).
>  The issue is when other machines attempt to connect to it.  When I
> try to ping my machine (varie) from another machine (tessa) on the
> same subnet, usually I get the "Destination Host Unreachable" error.
>  If, on the other hand, varie has recently (say within 1 minute)
> ping-ed tessa, then tessa is able to find a route to varie and the
> ping is successful.  The issue is compounded by the fact
> that occasionally persistent TCP connections into varie are dropped,
> whereas outbound persistent connections are never dropped.  If, for
> example, I have an ssh session established from varie to tessa, the
> connection will never drop.  On the other hand, if tessa initiated the
> connection to varie, that connection will almost certainly die at some
> point while I am using it.

I don't think it's driver related.  It looks more like some firewall
misconfiguration.

However, you can run tshark or wireshark on both ends to see which
packets come true and which packets are lost.  It all the packets come
through, you have no reason to suspect the driver.

> Okay, hopefully that explains the issue well enough, now for some
> details:
> 
> 
> Model: Acer Revo (NVIDIA ION based)
> OS: Ubuntu 9.04
> Module: ath9k

That's actually the only "etiquette violation" in your message.  When
reporting a problem in software, please specify the version of the
software.  ath9k is a part of the kernel, so its version is shown by
"uname -r".  Not everybody runs Ubuntu and has time to figure out which
kernel it runs.

> root at varie:~# lsmod | grep ath
> ath9k                 263352  0
> mac80211              217592  1 ath9k
> led_class              12036  1 ath9k
> 
> 
> I tried following the instructions on how to debug, but I guess my
> ath9k module was not compiled with debug support, as there is no ath9k
> entry in /sys/kernel/debug/.

You don't need to guess.  I'm sure Ubuntu includes .config or autoconf.h
with its kernels.  Anyway, if /sys/kernel/debug is mounted and there is
no ath9k entry in it, then indeed it was compiled without debug support.

>   There are, however, some interesting entries
> under /sys/kernel/debug/ieee80211/phy0/:
> 
> 
> root at varie:~# ls -la /sys/kernel/debug/ieee80211/phy0/
> total 0
> drwxr-xr-x 7 root root 0 2009-08-10 23:33 .
> drwxr-xr-x 3 root root 0 2009-08-10 23:33 ..
> -r-------- 1 root root 0 2009-08-10 23:33 antenna_sel_rx
> -r-------- 1 root root 0 2009-08-10 23:33 antenna_sel_tx
> -r-------- 1 root root 0 2009-08-10 23:33 fragmentation_threshold
> -r-------- 1 root root 0 2009-08-10 23:33 frequency
> drwxr-xr-x 3 root root 0 2009-08-10 23:33 keys
> -r-------- 1 root root 0 2009-08-10 23:33 long_retry_limit
> drwxr-xr-x 2 root root 0 2009-08-10 23:33 netdev:wlan0
> drwxr-xr-x 2 root root 0 2009-08-10 23:33 rc
> -r-------- 1 root root 0 2009-08-10 23:33 rts_threshold
> -r-------- 1 root root 0 2009-08-10 23:33 short_retry_limit
> drwxr-xr-x 3 root root 0 2009-08-10 23:33 stations
> drwxr-xr-x 2 root root 0 2009-08-10 23:33 statistics
> -r-------- 1 root root 0 2009-08-10 23:33 total_ps_buffered
> -r-------- 1 root root 0 2009-08-10 23:33 wep_iv
> 
> 
> This is interesting to me because it's obviously wireless connectivity
> related, but there is no mention of ath9k anywhere.

That's because ath9k does only the hardware specific part, and the rest
is done by mac80211 and other common code in the kernel.

I'm not sure you have a wireless connectivity problem.  You would get
complete connection loss in that case, and you are seeing something more
high level, such as loss of TCP connections.

> I am new to this voodoo land, so please go easy on me.
> 
> 
> Any help would be appreciated, as long as it doesn't tell me to check
> firewall settings.  Believe me, I have been through
> iptables/tcpwrappers hell before, this is unlike any networking issue
> I've ever seen.  It's not a security thing, it's something much lower
> level.  That's why I'm talking to you.

Sorry, I'm not convinced.  You'll need to show that some packets
disappear, get mangled or get delayed too much while transmitted for it
to be a driver problem.

-- 
Regards,
Pavel Roskin