* [ath9k-devel] Bizarre one-way connectivity using ath9k @ 2009-08-11 23:30 Patrick McMichael 2009-08-12 16:11 ` Pavel Roskin 2009-08-12 20:23 ` Tor Krill 0 siblings, 2 replies; 5+ messages in thread From: Patrick McMichael @ 2009-08-11 23:30 UTC (permalink / raw) To: ath9k-devel 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. 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. Okay, hopefully that explains the issue well enough, now for some details: Model: Acer Revo (NVIDIA ION based) OS: Ubuntu 9.04 Module: ath9k 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/. 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. 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. Thanks for any help or redirection, Regards, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090811/8bdaf9e3/attachment.htm ^ permalink raw reply [flat|nested] 5+ messages in thread
* [ath9k-devel] Bizarre one-way connectivity using ath9k 2009-08-11 23:30 [ath9k-devel] Bizarre one-way connectivity using ath9k Patrick McMichael @ 2009-08-12 16:11 ` Pavel Roskin 2009-08-13 17:28 ` Patrick McMichael 2009-08-12 20:23 ` Tor Krill 1 sibling, 1 reply; 5+ messages in thread From: Pavel Roskin @ 2009-08-12 16:11 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [ath9k-devel] Bizarre one-way connectivity using ath9k 2009-08-12 16:11 ` Pavel Roskin @ 2009-08-13 17:28 ` Patrick McMichael 0 siblings, 0 replies; 5+ messages in thread From: Patrick McMichael @ 2009-08-13 17:28 UTC (permalink / raw) To: ath9k-devel Pavel, Thanks for the help, and the pointer on my etiquette. I'll do better next time. "uname -a" really should've been an obvious thing to post... You're right that it does feel and look like a firewall issue, but I really am pretty sure that it is not. It may be as you say outside of the wireless portions of the network stack, but it is below TCP for sure (it effects ICMP as well). Thanks again, Patrick On Wed, Aug 12, 2009 at 9:11 AM, Pavel Roskin <proski@gnu.org> wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090813/ee13a39d/attachment.htm ^ permalink raw reply [flat|nested] 5+ messages in thread
* [ath9k-devel] Bizarre one-way connectivity using ath9k 2009-08-11 23:30 [ath9k-devel] Bizarre one-way connectivity using ath9k Patrick McMichael 2009-08-12 16:11 ` Pavel Roskin @ 2009-08-12 20:23 ` Tor Krill 2009-08-13 17:28 ` Patrick McMichael 1 sibling, 1 reply; 5+ messages in thread From: Tor Krill @ 2009-08-12 20:23 UTC (permalink / raw) To: ath9k-devel Hi Patrick and others, On tis, 2009-08-11 at 16:30 -0700, Patrick McMichael wrote: > All, . . > 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. Not sure if this is of any help. But i ran into similar problems a while back. Described here: http://thread.gmane.org/gmane.linux.drivers.ath9k.devel/1716 I never got any reply. But i strongly suspect that broadcast/multicast where none functional in ath9k in that kernel. I now run 2.6.30.x and it actually seems to work now. So maybe the driver in ubuntu 9.04 has the same problems? Have you tried wireless-compat available for ubuntu? http://wireless.kernel.org/en/users/Download#Getting_compat-wireless_on_Ubuntu Regards, /Tor ^ permalink raw reply [flat|nested] 5+ messages in thread
* [ath9k-devel] Bizarre one-way connectivity using ath9k 2009-08-12 20:23 ` Tor Krill @ 2009-08-13 17:28 ` Patrick McMichael 0 siblings, 0 replies; 5+ messages in thread From: Patrick McMichael @ 2009-08-13 17:28 UTC (permalink / raw) To: ath9k-devel Tor, Wow, the issue you described there sounds exactly like what I'm seeing! It's encouraging to know that someone else has experienced a similar problem and the issue went away with future versions. I'm hoping your right and it's just the driver in ubuntu 9.04 that has this problem In the meantime I'll take a look at the wireless-compat package and see if maybe just updating to a newer driver works. Thanks for that link as well. Regards, Patrick On Wed, Aug 12, 2009 at 1:23 PM, Tor Krill <tor@excito.com> wrote: > > Hi Patrick and others, > > On tis, 2009-08-11 at 16:30 -0700, Patrick McMichael wrote: > > All, > . > . > > 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. > > Not sure if this is of any help. But i ran into similar problems a while > back. Described here: > > http://thread.gmane.org/gmane.linux.drivers.ath9k.devel/1716 > > I never got any reply. But i strongly suspect that broadcast/multicast > where none functional in ath9k in that kernel. I now run 2.6.30.x and it > actually seems to work now. > > So maybe the driver in ubuntu 9.04 has the same problems? Have you tried > wireless-compat available for ubuntu? > > > http://wireless.kernel.org/en/users/Download#Getting_compat-wireless_on_Ubuntu > > Regards, > > /Tor > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090813/0219a505/attachment.htm ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-08-13 17:28 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-08-11 23:30 [ath9k-devel] Bizarre one-way connectivity using ath9k Patrick McMichael 2009-08-12 16:11 ` Pavel Roskin 2009-08-13 17:28 ` Patrick McMichael 2009-08-12 20:23 ` Tor Krill 2009-08-13 17:28 ` Patrick McMichael
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.