phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf9120000, irq=17 I can't ssh into this box unless I walk round the table to it and make an outbound connection from it first. 'tcpdump -p' seems to indicate that it's not receiving ARPs.
It looks like it's just not receiving broadcast or multicast packets at all. I can log into it from outside the building -- obviously it's made an outbound connection recently, so the router has it in the ARP cache. But pinging it from another machine on the same subnet (myth) doesn't get any responses.... until the machine in question (dyn-253) sends an ARP request for something else, at which point 'myth' learns its MAC address and manages to send it a unicast packet. [root@acer ~]# tcpdump -i wlan0 -p not tcp port 22 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes #20:03:55.711449 arp who-has dyn-253.woodhou.se tell obelisk.infradead.org 20:03:55.711473 arp reply dyn-253.woodhou.se is-at 00:17:c4:5e:dd:55 (oui Unknown) 20:03:55.712127 IP dyn-253.woodhou.se.45852 > baythorne.infradead.org.domain: 14027+ PTR? 253.92.155.90.in-addr.arpa. (44) 20:04:00.711828 arp who-has baythorne.infradead.org tell dyn-253.woodhou.se 20:04:00.713099 arp reply baythorne.infradead.org is-at 00:11:95:dd:23:8d (oui Unknown) 20:04:00.717823 arp who-has phoenix.infradead.org tell dyn-253.woodhou.se 20:04:00.719316 arp reply phoenix.infradead.org is-at 00:c0:f0:31:0e:18 (oui Unknown) 20:04:00.719328 IP dyn-253.woodhou.se.53231 > phoenix.infradead.org.domain: 14027+ PTR? 253.92.155.90.in-addr.arpa. (44) 20:04:00.990292 IP phoenix.infradead.org.domain > dyn-253.woodhou.se.53231: 14027 2/5/7[|domain] 20:04:00.990494 IP dyn-253.woodhou.se.39798 > baythorne.infradead.org.domain: 32977+ PTR? 193.92.155.90.in-addr.arpa. (44) 20:04:01.002331 IP myth.infradead.org > dyn-253.woodhou.se: ICMP echo request, id 57684, seq 17, length 64 20:04:01.002823 arp who-has myth.infradead.org tell dyn-253.woodhou.se 20:04:01.004271 arp reply myth.infradead.org is-at 00:13:d3:5a:3f:e2 (oui Unknown) 20:04:01.004283 IP dyn-253.woodhou.se > myth.infradead.org: ICMP echo reply, id 57684, seq 17, length 64 20:04:01.079172 IP baythorne.infradead.org.domain > dyn-253.woodhou.se.39798: 32977 2/5/8[|domain] 20:04:01.079345 IP dyn-253.woodhou.se.39269 > baythorne.infradead.org.domain: 44535+ PTR? 195.92.155.90.in-addr.arpa. (44) 20:04:01.326662 IP baythorne.infradead.org.domain > dyn-253.woodhou.se.39269: 44535 2/5/9[|domain] 20:04:01.326911 IP dyn-253.woodhou.se.56306 > baythorne.infradead.org.domain: 17448+ PTR? 194.92.155.90.in-addr.arpa. (44) 20:04:01.379518 IP baythorne.infradead.org.domain > dyn-253.woodhou.se.56306: 17448 2/5/9[|domain] 20:04:01.379731 IP dyn-253.woodhou.se.37261 > baythorne.infradead.org.domain: 35455+ PTR? 199.92.155.90.in-addr.arpa. (44) 20:04:01.381493 IP baythorne.infradead.org.domain > dyn-253.woodhou.se.37261: 35455 2/5/9[|domain] 20:04:02.002350 IP myth.infradead.org > dyn-253.woodhou.se: ICMP echo request, id 57684, seq 18, length 64 20:04:02.002383 IP dyn-253.woodhou.se > myth.infradead.org: ICMP echo reply, id 57684, seq 18, length 64 20:04:03.002348 IP myth.infradead.org > dyn-253.woodhou.se: ICMP echo request, id 57684, seq 19, length 64 20:04:03.002375 IP dyn-253.woodhou.se > myth.infradead.org: ICMP echo reply, id 57684, seq 19, length 64 20:04:04.002343 IP myth.infradead.org > dyn-253.woodhou.se: ICMP echo request, id 57684, seq 20, length 64 20:04:04.002367 IP dyn-253.woodhou.se > myth.infradead.org: ICMP echo reply, id 57684, seq 20, length 64 20:04:05.002318 IP myth.infradead.org > dyn-253.woodhou.se: ICMP echo request, id 57684, seq 21, length 64 20:04:05.002364 IP dyn-253.woodhou.se > myth.infradead.org: ICMP echo reply, id 57684, seq 21, length 64 20:04:06.002351 IP myth.infradead.org > dyn-253.woodhou.se: ICMP echo request, id 57684, seq 22, length 64 20:04:06.002383 IP dyn-253.woodhou.se > myth.infradead.org: ICMP echo reply, id 57684, seq 22, length 64 20:04:06.078741 arp who-has dyn-253.woodhou.se tell baythorne.infradead.org 20:04:06.078758 arp reply dyn-253.woodhou.se is-at 00:17:c4:5e:dd:55 (oui Unknown) ^C 33 packets captured 33 packets received by filter 0 packets dropped by kernel
If I 'ifconfig wlan0 promisc' it suddenly starts seeing all the broadcast and multicast traffic... 20:10:17.048564 00:40:f4:28:95:9d > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 118: fe80::240:f4ff:fe28:959d > ff02::1: ICMP6, router advertisement, length 64 20:10:17.088835 00:17:c4:5e:dd:55 > 33:33:ff:5e:dd:55, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff5e:dd55: ICMP6, neighbor solicitation, who has 2001:8b0:10b:1:217:c4ff:fe5e:dd55, length 24 20:10:18.213479 00:17:c4:5e:dd:55 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 190: 90.155.92.253.mdns > 224.0.0.251.mdns: 0 [2q] [2n][|domain] 20:10:18.277137 00:40:f4:28:95:9d > 01:00:5e:00:01:01, ethertype IPv4 (0x0800), length 90: 81.2.98.174.ntp > 224.0.1.1.ntp: NTPv4, Broadcast, length 48 20:10:18.464032 00:17:c4:5e:dd:55 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 190: 90.155.92.253.mdns > 224.0.0.251.mdns: 0 [2q] [2n][|domain] 20:10:18.714533 00:17:c4:5e:dd:55 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 190: 90.155.92.253.mdns > 224.0.0.251.mdns: 0 [2q] [2n][|domain] 20:10:18.914959 00:17:c4:5e:dd:55 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 178: 90.155.92.253.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0[|domain] 20:10:19.989297 00:17:c4:5e:dd:55 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 178: 90.155.92.253.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0[|domain] 20:10:22.064711 00:17:c4:5e:dd:55 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 178: 90.155.92.253.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0[|domain] 20:10:23.807019 00:40:f4:28:95:9d > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 118: fe80::240:f4ff:fe28:959d > ff02::1: ICMP6, router advertisement, length 64
Inspired by commit b93bce2a5e8fd5c9f5d8c982efd6bca71a9b83f3 I tried adding 'rfilt |= 0x8000;' in ath_calcrxfilter(). Now it seems to be working fine. The device receives ARP and IPv6 RA correctly.
Adding some debugging shows me... ath9k_hw_setbssidmask fffffffd 0000ffff wlan0: authenticate with AP 00:06:25:4b:55:f8 wlan0: authenticated wlan0: associate with AP 00:06:25:4b:55:f8 wlan0: RX AssocResp from 00:06:25:4b:55:f8 (capab=0x411 status=0 aid=1) wlan0: associated ath9k_hw_write_associd 4b250600 0001f855 rfilt 8017 ath9k_hw_write_associd ffffffff 0000ffff ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready rfilt 8017 ath9k_hw_reset ffffffff 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff ath9k_hw_reset ffffffff 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff ath9k_hw_reset ffffffff 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff ath9k_hw_reset ffffffff 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 rfilt 8017 rfilt 8017 ath9k_hw_write_associd ffffffff 0000ffff ath9k_hw_reset ffffffff 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff ath9k_hw_reset ffffffff 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff ath9k_hw_reset ffffffff 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff ath9k_hw_reset ffffffff 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017
Adding an appropriate WARN_ON() shows me that the associd registers are being reset when a scan is started... but never being put back to their normal state. ath9k_hw_setbssidmask fffffffd 0000ffff wlan0: authenticate with AP 00:06:25:4b:55:f8 wlan0: authenticated wlan0: associate with AP 00:06:25:4b:55:f8 wlan0: RX AssocResp from 00:06:25:4b:55:f8 (capab=0x411 status=0 aid=1) wlan0: associated ath9k_hw_write_associd 4b250600 0001f855 rfilt 8017 ath9k_hw_write_associd ffffffff 0000ffff ------------[ cut here ]------------ WARNING: at /home/dwmw2/ath9k/hw.c:3859 ath9k_hw_write_associd+0x66/0x97 [ath9k]() (Tainted: G W ) Hardware name: Extensa 5230 Modules linked in: ath9k nfs lockd nfs_acl auth_rpcgss bridge stp llc bnep sco l2cap bluetooth sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 p4_clockmod dm_multipath uinput arc4 ecb acer_wmi pcspkr serio_raw joydev snd_hda_codec_intelhdmi snd_hda_codec_realtek i2c_i801 iTCO_wdt snd_hda_intel iTCO_vendor_support yenta_socket rsrc_nonstatic snd_hda_codec snd_hwdep snd_pcm mac80211 snd_timer cfg80211 tg3 snd soundcore snd_page_alloc wmi i915 drm i2c_algo_bit i2c_core video output [last unloaded: ath9k] Pid: 19076, comm: phy4 Tainted: G W 2.6.29.1-111.fc11.i686.PAE #1 Call Trace: [<c0436bfa>] warn_slowpath+0x7c/0xa4 [<c043ba7f>] ? do_softirq+0x68/0x7e [<c0693ff6>] ? dev_queue_xmit+0x40c/0x440 [<c071569a>] ? printk+0x14/0x1a [<f8bb430d>] ath9k_hw_write_associd+0x66/0x97 [ath9k] [<f8bc3015>] ath9k_configure_filter+0x49/0x4e [ath9k] [<f848a78f>] ieee80211_start_scan+0x1d1/0x209 [mac80211] [<f848f7ba>] ieee80211_sta_work+0x879/0xdcf [mac80211] [<c0432693>] ? dequeue_task_fair+0x5c/0x61 [<c0427fa8>] ? dequeue_task+0xf5/0x104 [<c0408099>] ? __switch_to+0x7b/0xfd [<c043197f>] ? finish_task_switch+0x85/0x9f [<c0715ec5>] ? schedule+0x70b/0x791 [<c0445353>] run_workqueue+0x8e/0x118 [<f848ef41>] ? ieee80211_sta_work+0x0/0xdcf [mac80211] [<c0445498>] worker_thread+0xbb/0xc7 [<c04485bd>] ? autoremove_wake_function+0x0/0x34 [<c04453dd>] ? worker_thread+0x0/0xc7 [<c04482e4>] kthread+0x41/0x65 [<c04482a3>] ? kthread+0x0/0x65 [<c0409dbf>] kernel_thread_helper+0x7/0x10 ---[ end trace 5fbc5836811c986b ]--- ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready rfilt 8017 ath9k_hw_reset ffffffff 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff rfilt 8017 ath9k_hw_setbssidmask fffffffd 0000ffff
*** Bug 498662 has been marked as a duplicate of this bug. ***
Created attachment 342516 [details] Assoc ID fix test Please try this patch
That seems to fix it; thanks. Note that you'd have spotted this error almost _immediately_ if you were doing even the most basic functional testing with IPv6. With no infrastructure or configuration at all and just 'ping6 -I wlan0 fe80::217:c4ff:fe5e:dd55' from another machine on the same network (where you use the address shown in ifconfig for your _own_ card, of course, not mine), you'd have seen it fail.
Building now... http://koji.fedoraproject.org/koji/buildinfo?buildID=101070
Can this be closed now?