Bug 498502 - ath9k not receiving multicast/broadcast packets
ath9k not receiving multicast/broadcast packets
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-30 15:00 EDT by David Woodhouse
Modified: 2009-06-01 13:53 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-01 13:53:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Assoc ID fix test (77 bytes, text/plain)
2009-05-05 14:44 EDT, Luis R. Rodriguez
no flags Details

  None (edit)
Description David Woodhouse 2009-04-30 15:00:52 EDT
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.
Comment 1 David Woodhouse 2009-04-30 15:10:36 EDT
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
Comment 2 David Woodhouse 2009-04-30 15:11:14 EDT
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
Comment 3 David Woodhouse 2009-04-30 17:26:45 EDT
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.
Comment 4 David Woodhouse 2009-05-01 04:49:03 EDT
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
Comment 5 David Woodhouse 2009-05-01 04:56:58 EDT
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
Comment 6 John W. Linville 2009-05-01 14:56:21 EDT
*** Bug 498662 has been marked as a duplicate of this bug. ***
Comment 7 Luis R. Rodriguez 2009-05-05 14:44:53 EDT
Created attachment 342516 [details]
Assoc ID fix test

Please try this patch
Comment 8 David Woodhouse 2009-05-05 19:49:33 EDT
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.
Comment 9 John W. Linville 2009-05-06 13:48:16 EDT
Building now...

   http://koji.fedoraproject.org/koji/buildinfo?buildID=101070
Comment 10 Luis R. Rodriguez 2009-06-01 13:45:27 EDT
Can this be closed now?

Note You need to log in before you can comment on or make changes to this bug.