Wireless Internet forum: Enterasys Wireless Enterprise Network Connectivity Issues

We knew of this issue and we don't have my cordless phones or bluetooth or microwaves or anything like that within the vicinity. Part of the problem is that we don't know when the stuff drops off... because we don't control the controller, we can see any thing on it. It's just odd to me that we have 2000 clients and half of them get on and half of them don't. The half that don't, half of those computers are actually online even though it says they're offline. The other half of the half that don't, connect right up as soon as anyone logs in. I just don't understand how this many things can go wrong when everything is done the exact same way. I need some ideas to go off of here... LOL! I'm stuck right now... I've tried everything I could think of to my knowledge.

It partially depends what you mean being online. I am assuming you are running a VPN type of encryption in addition to whatever wireless security. So are you dropping the wireless or the VPN.

There are a couple of things I have seen happen when running VPN over wireless.

The first is when you have a vpn client up it will in general force all traffic though the vpn. This includes things like DHCP renewals. So when your machine wants to send the DHCP renewal at 1/2 the lease time for the ip of the wireless network it will send this request though the vpn tunnel instead. (assuming split tunnel is disabled). Since the machine does not get a response back from the DHCP server on the wireless network (since it was sent to the vpn network) it will eventually hit the time limit and restart everything related to the ip address.
This happens a lot if you have your lease times set low.

Another issue with VPN and wireless is that they don't like you moving from 1 AP to another. The delays caused by this will many times kill off the VPN client. You need to set the point the machine moves from one ap to another to a value low enough to reduce this.

Now if you are using WPA2 with certificates you AP's may have a issue talking to your certificate/radius server. There are also large issues moving from AP to AP when you use certificates and the radius server, sometimes it has issues moving the authentication between the AP. Normally if you force all users to use a strong VPN encryption you can run the wireless with a simpler security.

Wireless is tough in a enterprise environment many companies have at least 1 person whose primary job is to just fix wireless.

"Now if you are using WPA2 with certificates you AP's may have a issue
talking to your certificate/radius server. There are also large issues
moving from AP to AP when you use certificates and the radius server,
sometimes it has issues moving the authentication between the AP."

Can you please expand upon this. Why are there issues when moving between AP's? Also, why could the AP's have issues talking to the radius server? I'm not saying you're wrong... you're very right... I just would like some more explanation if you have any.

I will try to summarize this. Cisco has a number of papers on this topic, look for fast secure roaming.

When you are running with radius both the AP itself as well as the client is authenticating with the radius server to prevent man in the middle attacks. The issue comes mostly if your radius server is not close (latency wise) to your AP. There is a lot of communication between the devices so any delays are added on each other. It does not take many errors for it to slow the process down. Sometimes if the delay is high enough the PC will just give up. The AP to AP is a extension of this issue. In general (unless you buy advanced systems) the AP do not talk to each other. This means that when you move to a new one it must go though the whole authentication and key exchange process from the start. When it works well you get a couple 100ms of delay but I have had it get stuck. Can't say why the users just clicks connect again and it works. Then again we were using consumer grade equipment that would not tell us why. The 2 brand of commercial AP I have used seemed to work better but even a couple 100ms outage kills off some applications one of our VPN clients in particular. The key here is to make sure it does not flap back and forth and spend all its time authenticating with AP rather than doing useful work.

The radius server logs tend to be a good place to start when you suspect a issue like this. Hard to say exactly but the logs look different than they do when it is running correctly. You see things like the same machine authenticate over and over.

That does sound like that's what our issue is. If, for example, I go to the non-working computer and log in with the local admin account, I can sync up to the network right away after clicking on it. The users (obviously) can't do this because they don't have the local admin account name/password...

So, thank you very much in helping me figure out the possible issue.

To solve this, I think the best thing to do would be to turn down the client's (laptop's) NIC power... I think one of the main issues is that because we have SO many laptops and AP's packed into a small area, the network thinks the laptops are roaming when they're not. This would cause the issue of the authentication and key exchange process to have errors... and I would assume that if one gets stuck, everything behind it gets stuck too, right?

Does that seem like a step towards making this entire process better (turning the NIC power down on the client side)? I don't have too much access to the controller side because all that is locked down by the NEC... but I can control what the clients do. And I think if we do everything we can on our side to fix the issue, they will be more willing to work with us...

If you have any more ideas, please let me know. LOL! I'm open to suggestions.

Bill012,

Is there any way I can e-mail you directly?

Excuse me for intruding but I need to say these forums do not encourage contact via email to discuss problems posted in these forums.

The members who help here are volunteers and they offer their time freely and for no reward. It is CNET's duty to preserve their privacy and while there is no ban on individuals agreeing to private contact via emails, it is not a course that these forums advocate.

Other than that, these forums are public and open for anyone to read. The main purpose of course is to solve problems for posters, but the options and solutions offered here are also helpful for those who may find these discussions via other means, search engines, referrals and so on. It would be a shame to deny others any help if a discussion is taken away.

I hope that explains the situation.

Mark

That's called a bug. You found it, I know about it but the makers and creators of the software, the OS and the industry don't consider it to be a big issue because it only affects a few folk.

This is no excuse so I suggest you ask the makers of all this to do better.

If you want to know, this is one of the reasons we used SUN workstations long ago. Because SUN actually had a process in place to report and deal with the issues. Then again, at 25K to 1M per work station, they had to deliver.
Bob

LOL!! I really wish I could tell my boss that and they would be okay with that answer... my job would be SO much easier!! HAHA! I have actually tried that approach... he wants me to find other possible solutions. So, here I am.

Long ago in a far off place (just 100 miles from where I am today) we had some box that required you to set the thumbwheels to some number such as A5 to run. Low and behold a new machine arrived and it was different. It require you to set the wheels to A7 to do the task.

After much to do about this, one of our production engineers fixed it by removing the cover and swapping the number 5 and 7 on the spin wheel.

Fast forward to now, and today. Since this on/off line indicator is broken, you as the administrator should hide it from view. If they need an on/off indicator you could write a new app for that.

Fixed!
Bob

LOL! NICE FIX!! I like it!!!!! If I could make it so the NEC (formally known as DOIM... or, as we like to call it, Doom...) could just see all the computers all the time and wouldn't shut them down by hiding the list somewhere... I would!!!