Flushing MAC-tables(?)
Dear list-members!
I am using OpenWRT (www.openwrt.org) on two accesspoints. Within OpenWRT, the wireless interface and the ethernet interface are bridged to one interface (br0).
Those two accesspoints are standing quite far from one another. Their WLAN-cells do not cross each other, meaning I have an area in between the two accesspoints, where there is no accesspoint of the two
accessible: a dead spot.
Now I use two WLAN-telephones (Cisco 7920). I start calling one of the phones inside the same radio cell and I answer this call. Now I start moving away to the other accesspoint. As soon as I see myself assiciated to the "new" accesspoint, I am able to hear my mate on the other phone in the "old" cell, but he cannot hear me. This stays this way, until a certain point of time is reached. In our tests, he has been able to hear my voice recurring at :30 each minute. Take these examples:
05:40:20 I roamed to the "new" AP
05:40:30 my mate could hear me
05:43:35 I roamed to the "new" AP
05:44:30 my mate could hear me
05:47:03 I roamed to the "new" AP
05:47:30 my mate could hear me
...and so on.
So at a certain point of time, there seems to be a flushing of some bridge-tables, but I don't know, how I could influence this behaviour. Is this "flushing" somehow to be done manually? Or is there a timer, which sets this behaviour?
I sniffed the WLAN a little while my tests have been done and the result is, that the "old" accesspoint seems to still believe me in his radio cell. So he sends out data for me all of the time, but since my telephone has moved away, there is no more client to ACK these packages. After the time mentioned before has passed, these packet are away and the communication goes on the way it should. So I assume, there is a timeout, that tells the AP to flush its old bridge-MAC tables of clients, that he did not hear of since XX seconds...
Any help would be appreciated. Thanks a lot in advance,
Dennis
Quoted 4 lines · Dennis Borgmann
So at a certain point of time, there seems to be a flushing of some bridge-tables, but I don't know, how I could influence this behaviour. Is this "flushing" somehow to be done manually? Or is there a timer, which sets this behaviour?
in recent kernel (not in 2.4, and maybe only in recent 2.6) you can flush the FDB using sysfs:
/sys/class/net/%s/bridge/flush (whole bridge)
/sys/class/net/%s/brif/%s/flush (single interface)
If you want you can lower the ageing timer from the default 300sec using brcl setageing
Maybe you can just force your phone to register more frequently so the bridge will just learn the new port when you move.
Francesco
Hi Francesco,
I already tried playing around with the ageing timer, but it did not help me.
Since I am using Kernel 2.4: is there no way of flushing the FDB?
Thanks so far,
Dennis
Quoted 18 lines · Francesco Dolcini
Quoted 4 lines · Dennis Borgmann
So at a certain point of time, there seems to be a flushing of some bridge-tables, but I don't know, how I could influence this behaviour. Is this "flushing" somehow to be done manually? Or is there a timer, which sets this behaviour?
in recent kernel (not in 2.4, and maybe only in recent 2.6) you can flush the FDB using sysfs:
/sys/class/net/%s/bridge/flush (whole bridge) /sys/class/net/%s/brif/%s/flush (single interface)If you want you can lower the ageing timer from the default 300sec using brcl setageing
Maybe you can just force your phone to register more frequently so the bridge will just learn the new port when you move.
Francesco
There's a simpler solution: at association-time the wlan stack should emit (up to linux) a bcast frame w/ the source address of the associating station. That frame will serve to notify the local and remote bridges of the move.
-Mark
Quoting Dennis Borgmann <[email protected]>:
Quoted 28 lines
Hi Francesco,
I already tried playing around with the ageing timer, but it did not help me.
Since I am using Kernel 2.4: is there no way of flushing the FDB?
Thanks so far,
DennisQuoted 16 lines · Francesco Dolcini
Quoted 4 lines · Dennis Borgmann
So at a certain point of time, there seems to be a flushing of some bridge-tables, but I don't know, how I could influence this behaviour. Is this "flushing" somehow to be done manually? Or is there a timer, which sets this behaviour?
in recent kernel (not in 2.4, and maybe only in recent 2.6) you can flush the FDB using sysfs:
/sys/class/net/%s/bridge/flush (whole bridge) /sys/class/net/%s/brif/%s/flush (single interface)If you want you can lower the ageing timer from the default 300sec using brcl setageing
Maybe you can just force your phone to register more frequently so the bridge will just learn the new port when you move.
Quoted 9 lines
Quoted 2 lines
Francesco
_______________________________________________
Bridge mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/bridge
Mark S. Mathews
AbsoluteValue Systems Web: http://www.linux-wlan.com 721-D North Drive e-mail: [email protected] Melbourne, FL 32934 Phone: 321.259.0737 USA Fax: 321.259.0286
Quoted 7 lines · On Fri, 28 Sep 2007 10:38:37 -0400 "Mark S. Mathews" <[email protected]>…
There's a simpler solution: at association-time the wlan stack should emit (up to linux) a bcast frame w/ the source address of the associating station. That frame will serve to notify the local and remote bridges of the move.
-Mark
With 2.6 if you set the ageing time to 0 then no forwarding table entry is made (it will always flood). Or you could set it real short time.
2.4 code is fossilized at this point and your limited to setting a real short ageing time. You can go down to 1 HZ value so that should work.
Signature · 1 line
Stephen Hemminger <[email protected]>
Quoted 12 lines · Dennis Borgmann
Dear list-members!
I am using OpenWRT (www.openwrt.org) on two accesspoints. Within OpenWRT, the wireless interface and the ethernet interface are bridged to one interface (br0).
Those two accesspoints are standing quite far from one another. Their WLAN-cells do not cross each other, meaning I have an area in between the two accesspoints, where there is no accesspoint of the two
accessible: a dead spot.
Quoted 5 lines
Now I use two WLAN-telephones (Cisco 7920). I start calling one of the phones inside the same radio cell and I answer this call. Now I start moving away to the other accesspoint. As soon as I see myself assiciated to the "new" accesspoint, I am able to hear my mate on the other phone in the "old" cell, but he cannot hear me. This stays this way, until a
This seems not to be a bridging problem then, since your pal didn't move to a new access point, his information should be correct in all bridges (either correct interface or no entry). Therefore packets sent to him should be correctly delivered. OTOH his outgoing packets could be blocked by his access point as long as it thinks you are locally attached (the first packet coming in via the other access point should disillusion it without need for a timer).
The behavior you are seeing is opposite, therefore I think you have misidentified the cause. Can you use VOIP software on a real computer, and run packet capture software? It might be very informative to have a connection phone <-> computer and also computer <-> computer in order to see if any packets are actually being missed, and in which direction.
Most likely your phone clears the routing table when you dissociate from the other access point, and the routing table isn't rebuilt until dhcp runs at the new location. This affects outgoing packets more than incoming, since your adapter still may honor packets destined to your MAC address and broadcast within its range. Of course it may not be the routing table either.
certain point of time is reached. In our tests, he has been able to hear
Quoted 35 lines
my voice recurring at :30 each minute. Take these examples:
05:40:20 I roamed to the "new" AP
05:40:30 my mate could hear me05:43:35 I roamed to the "new" AP
05:44:30 my mate could hear me05:47:03 I roamed to the "new" AP
05:47:30 my mate could hear me...and so on.
So at a certain point of time, there seems to be a flushing of some bridge-tables, but I don't know, how I could influence this behaviour. Is this "flushing" somehow to be done manually? Or is there a timer, which sets this behaviour?
I sniffed the WLAN a little while my tests have been done and the result is, that the "old" accesspoint seems to still believe me in his radio cell. So he sends out data for me all of the time, but since my telephone has moved away, there is no more client to ACK these packages. After the time mentioned before has passed, these packet are away and the communication goes on the way it should. So I assume, there is a timeout, that tells the AP to flush its old bridge-MAC tables of clients, that he did not hear of since XX seconds...
Any help would be appreciated. Thanks a lot in advance,
Dennis
_______________________________________________
Bridge mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/bridge
Good catch Richard, I forgot about the stale association problem.
Actually, my note about having the 'new AP' wlan stack generate a bcast frame in reponse to the association event should take care of this problem as well. When the old AP's wlan stack sees a frame coming in from above (i.e. off the wire) with a source address equal to one of its associated stations, it _should_ immediately disassoc that station thus breaking the mac-level STA-to-STA frame path.
I think this 'send a bcast to the wire upon assoc' behavior is listed in a recommended-practices somewhere (been a long time). It's basically a trick to enforce the 'STA shall be associated to one-and-only-one BSS within an ESS' rule.
-Mark
Quoting "[email protected]" <[email protected]>:
Quoted 41 lines · Dennis Borgmann
Quoted 12 lines
Dear list-members!
I am using OpenWRT (www.openwrt.org) on two accesspoints. Within OpenWRT, the wireless interface and the ethernet interface are bridged to one interface (br0).
Those two accesspoints are standing quite far from one another. Their WLAN-cells do not cross each other, meaning I have an area in between the two accesspoints, where there is no accesspoint of the two
accessible: a dead spot.Quoted 5 lines
Now I use two WLAN-telephones (Cisco 7920). I start calling one of the phones inside the same radio cell and I answer this call. Now I start moving away to the other accesspoint. As soon as I see myself assiciated to the "new" accesspoint, I am able to hear my mate on the other phone in the "old" cell, but he cannot hear me. This stays this way, until a
This seems not to be a bridging problem then, since your pal didn't move to a new access point, his information should be correct in all bridges (either correct interface or no entry). Therefore packets sent to him should be correctly delivered. OTOH his outgoing packets could be blocked by his access point as long as it thinks you are locally attached (the first packet coming in via the other access point should disillusion it without need for a timer).
The behavior you are seeing is opposite, therefore I think you have misidentified the cause. Can you use VOIP software on a real computer, and run packet capture software? It might be very informative to have a connection phone <-> computer and also computer <-> computer in order to see if any packets are actually being missed, and in which direction.
Most likely your phone clears the routing table when you dissociate from the other access point, and the routing table isn't rebuilt until dhcp runs at the new location. This affects outgoing packets more than incoming, since your adapter still may honor packets destined to your MAC address and broadcast within its range. Of course it may not be the routing table either.
Quoted 37 lines
certain point of time is reached. In our tests, he has been able to hear
Quoted 35 lines
my voice recurring at :30 each minute. Take these examples:
05:40:20 I roamed to the "new" AP
05:40:30 my mate could hear me05:43:35 I roamed to the "new" AP
05:44:30 my mate could hear me05:47:03 I roamed to the "new" AP
05:47:30 my mate could hear me...and so on.
So at a certain point of time, there seems to be a flushing of some bridge-tables, but I don't know, how I could influence this behaviour. Is this "flushing" somehow to be done manually? Or is there a timer, which sets this behaviour?
I sniffed the WLAN a little while my tests have been done and the result is, that the "old" accesspoint seems to still believe me in his radio cell. So he sends out data for me all of the time, but since my telephone has moved away, there is no more client to ACK these packages. After the time mentioned before has passed, these packet are away and the communication goes on the way it should. So I assume, there is a timeout, that tells the AP to flush its old bridge-MAC tables of clients, that he did not hear of since XX seconds...
Any help would be appreciated. Thanks a lot in advance,
Dennis
_______________________________________________
Bridge mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/bridge
Mark S. Mathews
AbsoluteValue Systems Web: http://www.linux-wlan.com 721-D North Drive e-mail: [email protected] Melbourne, FL 32934 Phone: 321.259.0737 USA Fax: 321.259.0286
Quoted 10 lines · Mark S. Mathews
Good catch Richard, I forgot about the stale association problem.
Actually, my note about having the 'new AP' wlan stack generate a bcast frame in reponse to the association event should take care of this problem as well. When the old AP's wlan stack sees a frame coming in from above (i.e. off the wire) with a source address equal to one of its associated stations, it _should_ immediately disassoc that station thus breaking the mac-level STA-to-STA frame path.
Quoted 4 lines
I think this 'send a bcast to the wire upon assoc' behavior is listed in a recommended-practices somewhere (been a long time). It's basically a trick to enforce the 'STA shall be associated to one-and-only-one BSS within an ESS' rule.
Most stations will send a broadcast upon association even without help from the AP (DHCP-REQUEST for example).
In this case, the station that moved can still hear the other station, which makes me believe there is not a stale association, or stale MAC entries, because the stationary node obviously found the new location of the mobile node correctly. It's the mobile node that can't transmit. That's backwards from the breakage you'd get from a stale association/stale bridge learn table.
-Mark
Quoted 1 line
Quoting "[email protected]" <[email protected]>:
Quoted 19 lines · Mark S. Mathews
Quoted 10 lines
Good catch Richard, I forgot about the stale association problem.
Actually, my note about having the 'new AP' wlan stack generate a bcast frame in reponse to the association event should take care of this problem as well. When the old AP's wlan stack sees a frame coming in from above (i.e. off the wire) with a source address equal to one of its associated stations, it _should_ immediately disassoc that station thus breaking the mac-level STA-to-STA frame path.
Quoted 4 lines
I think this 'send a bcast to the wire upon assoc' behavior is listed in a recommended-practices somewhere (been a long time). It's basically a trick to enforce the 'STA shall be associated to one-and-only-one BSS within an ESS' rule.
Most stations will send a broadcast upon association even without help from the AP (DHCP-REQUEST for example).
Quoted 6 lines
In this case, the station that moved can still hear the other station, which makes me believe there is not a stale association, or stale MAC entries, because the stationary node obviously found the new location of the mobile node correctly. It's the mobile node that can't transmit. That's backwards from the breakage you'd get from a stale association/stale bridge learn table.
Too true. I had to reread the problem description and you're quite correct, sorry for the confusion.
The 'most stations' note though...;-) we've learned the hard way that there are plenty of mac/driver/host combinations that only issue DHCP requests on ESS transitions.
-Mark
Mark S. Mathews
AbsoluteValue Systems Web: http://www.linux-wlan.com 721-D North Drive e-mail: [email protected] Melbourne, FL 32934 Phone: 321.259.0737 USA Fax: 321.259.0286
Quoted 5 lines
The 'most stations' note though...;-) we've learned the hard way that there are plenty of mac/driver/host combinations that only issue DHCP requests on ESS transitions.
Didn't think of that. I guess seamless roaming would require that handoff isn't considered as a disconnect and reconnect.