Bridging ath0 interface create packet loss

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.

also odd: once the bridge error starts on the WRAP, the AP can be taken down and the forwarding/disabling/learn cycle continues. I have to wlanconfig ath0 destroy the AP after I down it to make the WRAP bridge quit cycling.

tried the same hardware with svn 1453 on the station- has the same issues when I enable the bridge. Wonder if it's the AP (it's rev 1454).

Also tried:

ifconfig eth0 0.0.0.0 up ifconfig ath0 0.0.0.0 up (after setting all the wlanconfig/iwpriv/iwconfig & ath0 was associated) brctl addbr br_court brctl addif br_court eth0 brctl addif br_court ath0 ifconfig br_court 192.168.4.11 netmask 255.255.255.0 up

the bridge comes up (as usuaal), the two ports enter learning stat, then the ath0 port starts to cycle as described above. (The difference in this test is the 0.0.0.0 ip assignments to eth0 & atho)

Tried changing the madwifi rev on the associated AP (leaving the bridged WRAP alone). Upgrading to madwifi 0.9.0 on the AP had no new impacts on the WRAP bridge. I'm still wondering if there is some bit of NAT or WPA invocation buried in a script that I haven't yet sussed out. I should never get any packets across the bridge and associated AP in that case. In some of these trials the transfer rate is very low, just a few packets.

As reported elsewhere, routing and NAT work fine. I installed shorewall 3.07 on the WRAP (no other changes) and configured it to behave like a bridge (ACCEPT policies all around and some explicit routing), and preliminary tests show no issues- associations are clean, there are no lost packets and the ping floods are 100%. The configuration, as before, is WRAP.Eth0->net and WRAP.ath0.sta associated with an AP. The eth0 and ath0 are passing all data packets for the routed networks, and act a lot like a bridge.

I'll move on to a routed iptables solution, as needs must.

Using the same hardware, creating an adhoc network, bridges between eth0 and ath0 or between ath0 and ath1 (2 cards, 2 wifi devices, 2 frequencies, separate ad hoc networks) all work fine. Creating adhoc VAPs vs sta VAPs eliminates the problem. This also removes the AP from the picture too, so I'm not able to say if it's the sta, the AP, or an interaction.

I got exactly the same problems with this setup also with svn 1675. I paste will paste the mail here i dropped to the ml:

i currently testing the briding stuff. At first i give you a overview about the setup

Hardware overview: client1----[Ethernet]---->Node1----[Wlan]---->Node2-----[Wlan]---->client2

Software overview: Node1-Hostapd(ath0)-->Node2-Wpa_supp(ath0) |Hostapd(ath1)---->Client2-wpa_supp

All nodes and clients got the latest svn and 2.6.* Kernel. Bridge-utils 1.1 are used. On all devices hostapd and wpa_supplicant are running the version 5.4. Wpa_supplicant and hostapd are compiled with the same madwifi headers which the driver is running on the systems.

Node1 setup: ath0 + eth0 are in a bridge called br0 Hostapd is running with the bridge option (bridge=br0) and the interface for hostapd is ath0. Its no problem to connect from client on to node1.

Node2 setup ath0 + ath1 + eth0 are in abridge called br0 Hostapd is running with the bridge option (bridge=br0) and the interface for hostapd is ath0. Wpa_supplicant is runnung with the options: "wpa_supplicant -D madwifi -b br0 -c /etc/wpa_supplicant.conf -i ath0 -B". Its no problem to ping,iperf, and do tcp stuff from node2 to client1 - that really works good over a long time.

The Problem: When client 2 connects to node2 over WPA or WEP - it works for a view seconds - i can ping client1 - then it stops. When it stops i got the following debug output on node2:

br0: port 2(ath0) entering disabled state
br0: port 2(ath0) entering learning state
br0: port 2(ath0) entering disabled state
br0: port 2(ath0) entering learning state
br0: port 2(ath0) entering disabled state
br0: port 2(ath0) entering learning state
br0: port 2(ath0) entering disabled state

That messages are repeating all over the time. So at the same second when for example a ping stops - the first message on node2 comes out.

I tested it with wep and with wpa its no difference so i dont think that that hostapd is the problem.

I have turned on ip_forwarding and iwpriv athX wds 1 on - also i run iwpriv ath0 bgscan 0. Im building the bridge with this options:

rmmod ath_pci
wlanconfig ath0 create wlandev wifi0 wlanmode sta
iwconfig ath0 essid test
iwpriv ath0 wds 1
iwconfig ath0 channel 10
ifconfig ath0 up

wlanconfig ath1 create wlandev wifi1 wlanmode ap
iwconfig ath1 essid aptest
iwpriv ath1 wds 1
iwconfig ath1 channel 1
#iwconfig ath1 key s:KEY
ifconfig ath1 up

brctl addbr br0
brctl addif br0 eth0
brctl addif br0 ath0
brctl addif br0 ath1

ifconfig br0 inet 192.168.1.33
ifconfig br0 up
echo 1  > /proc/sys/net/ipv4/ip_forward
route add default gw 192.168.1.5
hostapd /etc/hostapd/hostapd.conf -B
wpa_supplicant -D madwifi -b br0 -c /etc/wpa_supplicant.conf -i ath0 -B

Thats all...

This isn't really a wpa_supplicant bug. It's caused by most wireless adapters not being able to change the hardware MAC address, which is needed to have multiple virtual NICs work through the physical adapter, or for routing packets from other hardware adapters with a different MAC. I've heard that cards with Prism2 chipsets are able to do it. Also see blogs dot msdn dot com and search for "Networking and Wireless network adapters" for a vague hit and miss solution.

I was having the same problem with svn 2584, which is more recent than 0.9.3.

Changing the rate control to either amrr or onoe fixed the problem of the ath0 device bouncing up and down like a yo-yo when I ran iperf through it. I think there is a new rate control, but I haven't tried it, yet.

The sample rate control seems to get overly excited when iperf jams packets through ath0. I have ath0 and eth0 bridged, and I have wds set to 1.

I'd runs tests here with athdebug flags set, if I knew what athdebug flags I should set to debug the problem.

I've the same problem with last madwifi snapshot. I've setup two madwifi boards, the first one as an ap working with an ethernet board in a bridge. And the second with wpa_supplicant and an ethernet board in a bridge. When we do a ping from an other computer connected to the ethernet board of the client wifi (wpa_supplicant pc), a few packets are lost. This is enough to lock some network software, as sftp, nfs, for some periods of time.

bgscan is set to 0. Wds is to 1, on both wifi side, otherwise bridging failed to work at all, why ? This is a simple wifi link with 2 wifi boards...

In that configuration. Using non-bridged wpa_supplicant configuration seems to work fine.

Why theses packets are silently lost ? Is this an unwanted channel scanning ?