Russell Yount wrote:
On Sat, Jan 16, 2010 at 3:21 PM, Sam Leffler <s...@errno.com
<mailto:s...@errno.com>> wrote:
Russell Yount wrote:
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.
This sounds like the crypto encap of the frame is clobbering the
mbuf contents. You can verify this by setting up multiple vaps w/o
WPA. If this is the problem look for the mbuf copy logic for mcast
frames and make sure a deep copy is done.
Sam
The four VAPs broadcast traffic works find without WPA if I do not start
hostapds on them
I have been trying to discovery why broadcast traffic only works
correctly on the VAP associated with the last hostapd to be started. I
have move with VAP has the working broadcast traffic by restarting the
hostapd
associated with it.
It would seem something in the WPA/802.1x layer initialization remembers
which hostapd was started last and that affected the crypto encap.
I keep looking but do not see any place in the code that could account
for this.
It seems the corrupt crypto encap also happens on broadcast between
stations.
Please correct me if I am wrong:
but when using hostapd normally traffic is bridged withing the card.
So if a station sends to the VAP a broadcast it is actaully sending a
non- broadcast frame to the AP
and the AP sends the frame to all the other stations.
I told you waht the likely problem is. Look in the net80211 layer in
the kernel for the problem.
Sam
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
