OpenWrt Forum Archive

Topic: packet jam when openwrt has br0 configed on same subnet

The content of this topic has been archived on 27 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Post #1
JasonStraight
29 Oct 2005, 14:48

This one has me stumped:

Scenario:
openwrt rc3
linksys is _CLIENT_ to wireless network - not the AP
Mode: Repeater
br0: inet addr:192.168.37.120  Bcast:192.168.37.255  Mask:255.255.255.0
- all other config is standard other than being setup as repeater -
My laptop on wired side: ath0 64.x.37.120 ath0:1 192.168.37.250


The network the wrt is bridging for is _NOT_ 192.168.37.x normally. That's just what I have setup so that I can get at it but it doesn't need to be accessible from the internet.

Problem: (note arping needs -b)
If I ssh to 64.x.37.1 (which is on the wireless side of the wrt) and arping my lappy on the 64 net everything is happy.

If I arping my lappy's 192 addy it hangs, it doesn't lose packets, but it just stops for a while, then spits out everything at one time like it's buffering then flushing the buffer.

I know this is happening at the wrt, I've verified with tcpdump. I can arping my 64 addy fine, but arping the 192 addy stutters. I've switched the network on the wrt to 64 and the problem reverses itself. So I know it's got something to do with the br0 being configured to the same subnet as the traffic it's trying to pass along. The arp replies make it to the wrt but it waits for some period of time before sending a bunch of buffered arp replies out eth1.

The first time I tried this I setup the wrt with a real IP the first time and had all kinds of problems with traffic "clogging-up".

Anyone have any ideas? We are a WISP (Wireless Internet Service Provider) and basically have a boner over the idea of having client radios with so many features, but we will sometimes need the ability to use real world IP#'s on them, which is going to cause problems for the client who is on the other side of them with the same subnet.

Thanks.

Post #2
JasonStraight
29 Oct 2005, 15:20

More clues:

running tcpdump on wrt sees the packets from wireless side reaching the wrt, but never going out vlan0 when it's hanging up. What I just dont' get is how can X ping -> wrt -> Y work, but Y -> wrt -> X have problems? As far as the wrt is concerned it's still just a packet marked with x destination. The only thing I can think of is that the wrt is getting confused which interface 192.168.37.250 is on (wired), and when 250 is pinging 1, the wrt is seeing those packets which is updating the bridge table and therefore reminding the wrt there 250 really is.

The discussion might have continued from here.