Wireless and DHCP issues

[Duke5A]

This one has me scratching my head a little. I work educational IT, and we use wireless quite extensively at the schools. Just a couple of weeks ago, we rolled out new student testing software for evaluation. It's nothing complex, just runs off of a share on our NAS, students answer a series of questions, and results are recorded. It can be a bit traffic intensive though, and the majority of students are using netbooks connected over G wireless to take the test. Loading times for the test software to come up aren't that long, and once it is running, performance isn't an issue.

 

Just a couple of days ago though I started getting complaints of the testing software unexpectedly closing, and dropping the students back to the desktop. Checking the system log in event viewer revealed a couple of hints...

 

Source: DHCP

Event ID: 1003

 

Your computer was not able to renew its address from the network (from the DHCP Server) for the Network Card with network address [MAC address goes here]. The following error occurred:

The semaphore timeout period has expired. . Your computer will continue to try and obtain an address on its own from the network address (DHCP) server.

 

And then right after that entry....

 

Source: DHCP

Event ID: 1000

 

Your computer has lost the lease to its IP address 10.10.32.230 on the Network Card with network address [MAC address goes here].

 

And finally...

 

Source: MRxSmb

Event ID: 50

 

{Delayed Write Failed} Windows was unable to save all the data for the file \Device\LanmanRedirector. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere.

 

So I can see exactly what is happening. The client's address lease is expiring, and it can't seem to contact the DHCP server within whatever the timeout period is after it sends a renewal request. The address gets dropped, and TCP/IP connectivity goes down. It sounds like a congestion issue, but I'm certain it isn't. There are no more than 15 clients associated to each access point, and the Cisco WCS reports low utilization on said access points. To further help things along, the one and two MB data rates on the B/G radio have long since been disabled. Aside from this issue, I can find no evidence this being a congestion issue.

 

To patch this issue for right now, I've increased the DHCP lease time from two hours, to eight so it'll last the school day without having to renew.

 

I'd still like to know what in the world is causing this. Any ideas guys?

[cpjitservices]

In a spare moment, I'd power down the Switch in which the AP is plugged into and Power down the AP itself. They may need a kick up the ars3, sometimes our clients lose DHCP altogether so we power down the AP and power it back on and it seems to solve the issue, if that doesn't resolve the issue I'd also do the same thing for your DHCP server.

 

Good luck.

[sted]

is it worth trying converting the leases for the affected pcs into reservation so "their" ip is always free?

[m25man]

I was going to say the same thing, why just 2 Hrs? are IP addresses in such short supply there?

 

Why is your wireless lan on the same range anyway?

Can you not VLan it off and run them on their own subnet?

 

A wired PC might just be able to cope with a 2 Hr lease without dropping its shares but a wifi client I dont think so.

 

A two hour lease might be suitable for a public hotspot where mac addresses come and go every few minutes but a classroom of laptops that are always in need of IP services.

I would leave it at 7 days and if you dont have enough IP addresses to go around sort that issue out first.

[bio]

I was going to say the same thing, why just 2 Hrs? are IP addresses in such short supply there?

 

Why is your wireless lan on the same range anyway?

Can you not VLan it off and run them on their own subnet?

 

A wired PC might just be able to cope with a 2 Hr lease without dropping its shares but a wifi client I dont think so.

 

A two hour lease might be suitable for a public hotspot where mac addresses come and go every few minutes but a classroom of laptops that are always in need of IP services.

I would leave it at 7 days and if you dont have enough IP addresses to go around sort that issue out first.

 

fully agree... this is the way to go

 

bio..

[Duke5A]

I was going to say the same thing, why just 2 Hrs? are IP addresses in such short supply there?

 

Why is your wireless lan on the same range anyway?

Can you not VLan it off and run them on their own subnet?

 

A wired PC might just be able to cope with a 2 Hr lease without dropping its shares but a wifi client I dont think so.

 

A two hour lease might be suitable for a public hotspot where mac addresses come and go every few minutes but a classroom of laptops that are always in need of IP services.

I would leave it at 7 days and if you dont have enough IP addresses to go around sort that issue out first.

 

I'm sorry guys, I should have included some more detail. The student WLAN is in its own VLAN with a 23bit subnet. The problem is that this WLAN spans six sites and available addresses are on the very edge of being used up (recently had an explosion of additional wireless netbooks added to the network). To add another WLAN and subnet, or just giving the existing student WLAN a 22bit mask is going to entail configuration changes on our core switch. This is something I know that needs to be done, it's just a matter of getting the vendor over here to do it. CatOS, especially on something in production, is a little over my head.

 

Anyhow, here is an update after upping the lease time to 8 hours. I'm still getting reports of the testing software occasionally spontaneously quitting out and dropping the student back to a desktop. Event Viewer paints a slightly different story this time though. There are no DHCP related events to be seen, only the last one from my first post.

 

Source: MRxSmb

Event ID: 50

 

{Delayed Write Failed} Windows was unable to save all the data for the file \Device\LanmanRedirector. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere.

 

Even though the DHCP issue in Event Viewer is cleared up, I'm still at square one. Further checking WCS reveals the utilization rates to be low on the access points, but some of them have upwards of thirty associated clients. Even though I'm still not entirely convinced it's a congestion issue, the only other option I see right now is to enable aggressive load balancing on the Wireless Control Server for the access points. Maybe forcing clients to another AP when a single AP has more than 20 associated clients to it might help things out.

 

Thanks guys and I'll keep you posted. I won't be able to try this out though until Tuesday.