Re: [CampusManager] Problems with XP

I think there are 2 separate issues, here.

1.) 1394 adaptors bridged to the LAN interface.

2.) WLAN adaptor bridged to the LAN interface.

#1 is not a problem from a keeping the network working perspective. It's a
problem from the user perspective because it prevents them from registering,
and that prevents them from working.

We have been solving this problem by having the user unbridge the 1394 card
from the network card. They are then able to register. It must be useful
for something, but we have not yet run into a person where that has disabled
some other functionality that they needed/wanted.

#2 Only seems to be a problem for us in one scenario:
  --Wireless laptop is carried into an area that is covered by a wireless
base station
  -- Laptop is configured to connect to wireless network and does so.
  -- User of Laptop spots a nearby network jack on the wall and decides to
connect their laptop to it with an ethernet cable.
  
I had been avoiding it for a while, but I have come to believe that anything
that scares me about the Spanning Tree protocol is less scary than the
certainty that users will do this sort of thing. So, we've implemented
spanning tree across our network, and have not had this problem since then.

Spanning Tree has also saved us from another loop scenario that we have had
happen a couple times in the past. That is, that users moving their
computers around would manage to have an extra patch cord hanging from the
wall jack, see it, and think "oh that better be plugged in or my network
connection isn't going to work" so they plug it into another empty jack. If
the switch is a newer one that does Auto MDI/MDIX it completes the
connection, and they've created a loop.

Spanning Tree will automatically solve the second problem, but I can't
imagine how campus manager could be able to tell the difference between 2
machines on a hub plugged into a single CM managed network port, and the 2
mac addresses that would show up if a 1394 adaptor is bridged to the NIC.

The closest I've seen to an idea that starts to solve this problem came from
a discussion on another list. Someone on that list had written some code
that would reject Mac addresses where the vendor part of the mac address was
not on the list from the the IEEE of registered MAC addresses. With that
approach, they were able to keep the bridged devices off their network, but
also had found that students had some cheap network cards where the vendor
didn't register with IEEE, they just made up their own MAC addresses. So,
this approach was keeping these cards off the network as an unintentional
side affect.

On 2/7/04 1:23 PM, "Brett Schwartz" <bschwartz_at_FAYSCHOOL.ORG> wrote:

> At least I'm not the only one having this problem, only thing is.... the
> bridging (ie culprit laptop) takes down our network... The incident has
> happened about 3-4 time since XP has been out on the market. There is a
> ways where you can override the bridging manually . If interested here is
> the whitepaper:
> http://support.microsoft.com/default.aspx?scid=kb;en-us;283429&Product=winxp
> KB: Article # 283429 Overall, I think Microsoft made a huge mistake
> in this feature...but that is my opinion : )
>
> Rick, Are you guys working on a solution if a bridging machine is detected
> on the network, and is then cut off from the network? This would be a god
> send if you create this feature.
>
> thanks!
> -Brett
> Mark Bauer <mbauer_at_skidmore.edu> writes:
>> I am new to the list so if this has been posted before, please forgive
>> me.
>>
>> Skidmore went live with our Campus Manager 3000 for the spring semester.
>> It was certainly an eye opener as we found many hubs, switches and
>> routers.
>>
>> We also found a problem with windows XP
>>
>> It seems that by default, XP likes to bridge cards together. The
>> firewire adapter (1394 adapter) is the one that causes the most
>> headaches. When a computer is first plugged in it follows all the rules.
>> The traps alert CM and everything works according to plan. After the
>> reboot (which we require because it makes the instructions easy to
>> follow for our non-technical students), the trap springs again because
>> it sees the bridged second card (so far only 2 instances of the wireless
>> card causing this). The problem is that the bridged second card is not
>> connected and therefore didn't request a dhcp address. This means the
>> cycle is broken and the computer stays connected to a port that has been
>> put into the registration vlan.
>>
>> You can manually change the vlan but the next time the computer is
>> restarted, it happens again. I believe the CM is polling the switches
>> (even though that has been deleted from the scheduler) because I was
>> working on the wiring in a students room while her room-mate was using
>> IM. Out of the blue she suddenly stopped working. I checked the switch
>> and she was back in the registration vlan. I turned off the bridge in
>> her computer and reset her switch port to her normal vlan, and she has
>> been working fine since.
>>
>> So - after this long explanation - if you are having these issues with
>> XP, check for bridging.
>>
>> Mark
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> ------------------------
> Brett A. Schwartz, MCP, A+
> Network Administrator ӿլ
> T H E F A Y S C H O O L
> Office: 508-490-8249
> Cell: 508-958-7692
> Fax: 508-485-5381
> http://www.fayschool.org
> ------------------------------------------------------------------------------
> ------------------------
>
>
>
>
Received on Mon Feb 09 2004 - 20:06:29 EST