Re: bridged vlan interfaces

I managed to get rid of the SRW2024, so now my network looks like this:

(40xSM)<-T->(AP)<-T->(BH)<-T->o
(20xSM)<-T->(AP)<-T->(BH)<-T->o
(30xSM)<-T->(AP)<-T->(BH)<-T->o(PlainSwitch)o<-T->(in.2-br0-out)<-P->(gateway)
             ...               o             o<-T->o(SRW208)o(mgmt)
        (SRW208)o<-T->(BH)<-T->o

The The SRW208 are just there to put some equipment that doesn't speak 
vlan onto the right vlans, so they couldn't affect the groups of 
subscriber modules.

The exact same customers exhibit the exact same problem when I add, say 
in.4 to the bridge.  Again, I haven't actually enabled vlan4 on anything 
but the linux box.  APs and SMs only have vlans 1 and 2 configured. 
BackHauls do not even understand vlans at all, they're just ethernet 
bridges.  Yet when I add in.4 or in.3 to the bridge, my phone rings.

Doing a 'tcpdump -i in.2 -n ether host <mac-of-customer>' shows me a 
string of arp requests and replies for the gateway but practically no 
other traffic.  Then, I 'brctl delif br0 in.4' and traffic 
instantaneously flows, and the customer says their internet is back.

I'll have other customers happily surfing away through the whole 
process, this only affects some of them.  I've noticed no similarities 
in MAC addresses, and they all run on identical equipment to that of 
working customers (same firmware, etc.)

Since I'm only using plain switches now, I can't easily 'sniff' traffic 
beyond the linux box until I build myself some sort of portable little 
bridge box that I could place at different points on the network, so if 
you guys have any other ideas, please share.

Jonathan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/