#674: Bridging ath0 interface create packet loss
----------------------------------+-----------------------------------------
Reporter: anonymous | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: madwifi: driver | Version: trunk
Resolution: | Keywords: bridge
Patch_attached: 0 |
----------------------------------+-----------------------------------------
Comment (by p0g0):
I am seeing this too: WRAP W/ CM9 voyage 0.2 (updated and not {stock 0.2
tarball download w/ madwifi r1611} ) w/ madwifi rev 1611, HAL 0.9.17.0,
kernel 2.6.15-486-voyage.
The ath0-sta/eth0 bridge on the WRAP is quiet until the sta associates.
Then the bridge detects a topology change on ath0, then cycles across
forwarding/disabled/listening. It cycles every few seconds, tho
intermittantly.
Ping -f has packet losses that vary from 3% to 20%, with periods of no
loss, then about 1-2 seconds of high loss. The bridge disable is probably
in synch with the ping flood loss.
Athstats nor iwconfig show anything odd (no nwids for example).
One can 'fix' the ath0 topology change, ping timeouts, and all other 'ath0
bridge issues' by isolating the WRAPS eth0 from other legs of the bridged
network. For example, when the bridge on the WRAP is 192.168.4.10 and
it's ath0 Sta associates to AP 192.168.4.31 (another madwifi that has no
other IFs, no routes, no neighbors), when the eth0 side of the WRAPs
bridge is plugged into a hub that has NICs in the 192.168.10.0 and
192.168.11.0 networks, there are no WRAP ath0 bridging messages. Flood
pings from the 192.168.4.31 AP to the bridge IP 192.168.4.10 under these
conditions are perfect with no timeouts or lost packets.
Plugging in a cable to that same hub that carries 192.168.4.0 net traffic
causes the WRAPS ath0 to report the bridge topology change and puts the
WRAP bridge back into the forward/disable/learning loop. The ping errors
to the bridge IP return too.
--
Ticket URL: <http://madwifi.org/ticket/674>
MadWifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity_______________________________________________
Madwifi-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/madwifi-tickets