[ednog] wireless bridging problem

Jeff Murphy jcmurphy at oss.buffalo.edu
Wed May 18 14:11:08 EDT 2005

the following is a forwarded message of a problem we're having here at
UB. the last paragraph has some possible solutions. i'm wondering if
anyone has any other solutions? 


Over the last semester we have had several complaints of intermittent
connectivity within resnet. We investigated and could find no physical
level problems that would cause this. We did find that our network gear
in these buildings experienced the same problem. Upon investigation we
determined that the mac address of our network gear was showing up on
resnet user ports. This would cause our gear to alarm as the packets
destined to the switch would instead go to the user port. The problem
would clear itself once the mac address timed out. 

The only way the switches mac address could show up on a user port is if
the user was spoofing mac addresses or bridging the network back on
itself. We do not believe the users are spoofing mac addresses as the
mac addresses affected seem pretty random. We do believe that the user
is bridging the network back onto itself with wireless. We have seen
this before, laptops come standard with built in wireless cards and have
the Ethernet bridged to the wireless. If a user where to plug in their
laptop to a wired Ethernet port and also have a wireless access point
near by, the network will get bridged back onto itself. Wireless access
points are installed by the users in resnet and are becoming more common
with our recommendation for the users to install routers. They install
wireless routers as they are cheap and more flexible. 

We currently have no way to automatically find the users in resnet doing
the bridging. While we run spanning tree on all resnet building
switches, it did not detect a loop or span out any of the ports. We
believe this is because the devices doing the bridging are smart enough
not to bridge spanning tree packets. The duration of the problem is so
short that most methods will not be able to catch it in time. The only
accurate way we could track this problem down was to do it manually as
we noticed the switch start alarming. We spent considerable time this
last semester tracking down these users and found about 20 of them. We
stayed on top of the problem and aggressively found and disabled users
to keep the problem under control. The help desk visited several sites
and found mixed results. Most had some combination of a laptop with
wireless, a wireless router, or an access point. They could find no
common thread or device to attach the problem too at this point.

We believe that this problem will only increase in frequency in the fall
semester as wireless routers and laptops will become more popular. We
believe there are several options in trying to solve this problem. We
could start a user education program on what not to do. We could ban
wireless in resnet so this problem does not happen. We could try to
automatically detect this problem and disable the port when it does
happen. We could move to a mac locking design to try and prevent this
problem from happening.

More information about the ednog mailing list