Date: Thu, 31 Dec 2009 02:16:40 -0500 From: Russell Yount <russell.yount@gmail.com> To: freebsd-stable@freebsd.org Cc: Russell Yount <russell.yount@gmail.com> Subject: atheros broadcast/multicast corruption with multiple hostap's Message-ID: <c62ff5ca0912302316o59c01ec5wd9efd008afd59c7f@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
It seems AP to client broadcasts/multicasts traffic is broken when using WPA2/802.11i with multiple hostapds in 8.0. Only the SSID associated with the last hostapd to be started has AP to client broadcasts/multicasts being delivered correctly. The AP and client are 8.0 freebsd systems althought I see same problems with windows XP as a client. The AP has 4 hostapds configured to use TLS with client certificates for authentication. (hostapd recompiled with HOSTAPD_CFLAGS=-DEAP_SERVER) The AP and client radio are shown as ath0: AR5212 mac 5.9 RF5112 phy 4.3 in dmesg. Client authenticate using client certificates associate correctly to all 4 SSIDs. Unicast traffic flows correctly between clients and AP for all for 4 SSIDs. Client to AP broadcast/multicast traffic works on of 4 SSIDs. AP to client broadcast/multicast traffic only works on 1 of the SSIDs. I have documented this using ARP broadcasts, but normal IP broadcasts also observed to corrupted. When an ARP request is send through the AP to an associated client it seems to be trashed on any of the SSID except the one associated with the last hostapd to be started. Here is the output of client side tcpdump showing the problems. In the first client side tcpdump with the hostapd associated with the SSID being associaed with the last hostapd started and the traffic flowing normally. In the second client side tcpdump with the hostapd associated with the SSID being not the last hostapd started the ARP request is resent multiple times and appears corrupted. I would really like to find a fix for this. Any help would be greatly appreciated. -Russ ---- tcpdump -e -n -l -i wlan0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes 00:53:46.565936 00:00:24:c9:b0:90 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 56: Request who-has 192.168.13.220 tell 192.168.13.115, length 42 00:53:46.565975 00:11:95:87:d1:d8 > 00:00:24:c9:b0:90, ethertype ARP (0x0806), length 42: Reply 192.168.13.220 is-at 00:11:95:87:d1:d8, length 28 00:53:46.567269 00:00:24:c9:b0:90 > 00:11:95:87:d1:d8, ethertype IPv4 (0x0800), length 98: 192.168.13.115 > 192.168.13.220: ICMP echo request, id 35599, seq 0, length 64 00:53:46.567302 00:11:95:87:d1:d8 > 00:00:24:c9:b0:90, ethertype IPv4 (0x0800), length 98: 192.168.13.220 > 192.168.13.115: ICMP echo reply, id 35599, seq 0, length 64 00:53:47.567919 00:00:24:c9:b0:90 > 00:11:95:87:d1:d8, ethertype IPv4 (0x0800), length 98: 192.168.13.115 > 192.168.13.220: ICMP echo request, id 35599, seq 1, length 64 00:53:47.567950 00:11:95:87:d1:d8 > 00:00:24:c9:b0:90, ethertype IPv4 (0x0800), length 98: 192.168.13.220 > 192.168.13.115: ICMP echo reply, id 35599, seq 1, length 64 00:53:48.569792 00:00:24:c9:b0:90 > 00:11:95:87:d1:d8, ethertype IPv4 (0x0800), length 98: 192.168.13.115 > 192.168.13.220: ICMP echo request, id 35599, seq 2, length 64 00:53:48.569824 00:11:95:87:d1:d8 > 00:00:24:c9:b0:90, ethertype IPv4 (0x0800), length 98: 192.168.13.220 > 192.168.13.115: ICMP echo reply, id 35599, seq 2, length 64 ^C 8 packets captured 8 packets received by filter 0 packets dropped by kernel ---- tcpdump -e -n -l -i wlan0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes 00:55:19.938900 00:00:24:c9:b0:90 > ff:ff:ff:ff:ff:ff, 802.3, length 64: LLC, dsap Unknown (0x2a) Group, ssap Unknown (0x32) Command, ctrl 0x6d3d: Supervisory, ?, rcv seq 54, Flags [Poll], length 50 00:55:20.940261 00:00:24:c9:b0:90 > ff:ff:ff:ff:ff:ff, 802.3, length 64: LLC, dsap Unknown (0x1a) Individual, ssap Unknown (0x36) Command, ctrl 0xbb45: Supervisory, Receiver not Ready, rcv seq 93, Flags [Poll], length 50 00:55:21.942119 00:00:24:c9:b0:90 > ff:ff:ff:ff:ff:ff, 802.3, length 64: LLC, dsap Unknown (0x0a) Group, ssap Unknown (0x6a) Response, ctrl 0x76aa: Information, send seq 85, rcv seq 59, Flags [Response], length 50 00:55:22.943974 00:00:24:c9:b0:90 > ff:ff:ff:ff:ff:ff, 802.3, length 64: LLC, dsap Unknown (0xec) Individual, ssap Unknown (0xd4) Command, ctrl 0x47b9: Supervisory, Reject, rcv seq 35, Flags [Poll], length 50 00:55:23.945911 00:00:24:c9:b0:90 > ff:ff:ff:ff:ff:ff, 802.3, length 64: LLC, dsap Unknown (0x96) Group, ssap Unknown (0xc6) Response, ctrl 0xf890: Information, send seq 72, rcv seq 124, Flags [Response], length 50 00:55:24.947772 00:00:24:c9:b0:90 > ff:ff:ff:ff:ff:ff, 802.3, length 64: LLC, dsap Unknown (0x68) Individual, ssap Unknown (0xfa) Command, ctrl 0x0a22: Information, send seq 17, rcv seq 5, Flags [Command], length 50 00:55:29.957213 00:00:24:c9:b0:90 > ff:ff:ff:ff:ff:ff, 802.3, length 64: LLC, dsap Unknown (0xa0) Group, ssap SNA (0x04) Command, ctrl 0x9110: Information, send seq 8, rcv seq 72, Flags [Poll], length 50 ^C 7 packets captured 7 packets received by filter 0 packets dropped by kernel ----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c62ff5ca0912302316o59c01ec5wd9efd008afd59c7f>