Wireless laptop dhcp-related problem

[Nozza]

In our school we get continued problems with laptops not connecting. The problem is sporadic but frequent enough to be a PITA.

The usual fix is to wire them up and reboot.

I've noticed that when the problem occurs the laptop only has an APIPA address. So i tried adding a fixed IP to the alternate configuration and this solved the problem without recourse to hard wiring. It would seem that hard wiring them allows them to get a DHCP address.

This does explain why they cannot get the DHCP address in the first place but this could be just a poor connection at the time or something.

Is it possible to get windows to issue a different range of alternate addresses rather than the APIPA ones? Otherwise I can reserve a range and manually add them to the alternate configs.

One thing I have noticed is that the laptops I experimented with didn't release those alternate IPs on their own. They still had them 2 or 3 boots later.

Any ideas welcome.

Thx

N

[sted]

ive had an odd laptop that wouldnt wireless unless i gave it a reservation in dhcp after that they worked fine no idea why a reserved address is bnetter than a random one to them but solved the problem

[plexer]

Is the fact they are not getting dhcp addresses because the wireless implementation is not working well?

What is your wireless setup?

Ben

[jam3s]

We seem to have the same problem with wireless clients not receiving DHCP

Ive found they seem to work if you give them a static ip address though!

I think the problem for us maybe the layer 2 broadcast size of our network!

[ChrisL]

Sorry to hijack this thread, but it looks remarkably similar to one that I was about to post myself..

We have a trolley of 30 netbooks which generally work absolutely fine, albeit after adding a second access point to get all 30 connected at once (3Com left that little detail out of the small-print!) Recently though, we've found that they will randomly refuse to connect to the domain and thus the users cannot log on. We have also found that simply rebooting once whilst hard-wired fixes whatever is broken and the wireless starts connecting again and authenticating users logons.

We've not really got enough data as yet to find any patterns, but gut-feeling is something timing out after a certain time. Signal strength is fine as the block it pretty well covered, and it's certainly not affecting all of the netbooks. Of the 30, we've had maybe 8-10 'break' in total, whilst the remaining ones have worked throughout.

We're going to try the suggestions above of setting static IPs to see if that helps. We have tried setting a 'broken' one to a static IP and it has NOT started working, but there's a thought that maybe having a static IP will stop it from breaking in the first place. The time to failure seems to be in to order of 20-30 days, so unfortunately, we probably won't know if any fixes have worked immedaitely.

Any other thoughts or suggestions would be gratefully recieved!!

Chris

[Nozza]

I've ended up setting half the trolley with a fixed alternate IP, with the others on DHCP. I cannot, as yet, be sure if this has worked - partly because we also had a wireless network fault fixed during the test period.

I'll try to check them today to see how many of them are stuck on using the alternate and how many are on DHCP. Maybe that will give an indication as to whether this setup has at least kicked in.

One thing I'm looking into is the "Always Wait for Network at Computer Startup and Login" policy which was suggested to me by someone.

[Oops_my_bad]

Are you using windows to manage the wireless connection and not 3rd party? If not you may have to enable the wireless utility to "connect before logon"

Also check GPO "Computer Configuration\Administrative Templates\System\Logon" and enable always wait for network

If that fails then the vendor/hardware manufacturer aren't implementing wireless properly.

[broc]

We have had similar problems over the last year or so with this. Eventually when I got time to really dig into the problem I found switching on some traces on the client really useful.

netsh ras set tracing * enable

The traces get logged in a folder called tracing in the windows directory on the client. There is a lot of detail in the traces and they need some serious time devoted to working through.

In our case the RASCHAP log revealed all.... and a bit of research in the www pointed to KB904943 and problems with machine only authentication.

[m25man]

I have seen issues recently with some HP wireless laptops where they have associated and negotiated WPA2 connections but fail to then get an IP address.
This was because the driver used did not fully support the final implementation of WPA2 but everything else worked.
We had to force the driver update by using an HP Support Pack which resolved the issue.
Trying to manually update the driver didn't work as after a reboot it showed the old 2006 driver not the 10/2008 driver it should have!

Make sure that you have the correct drivers installed, upgrade the machines firmware if applicable.

Test by turning off all encryption.

If you can connect, get a DHCP IP and see the LAN with security off, it is most likely to be related to the above.

I also had an instance where a major manufacturers AP firmware was bugged when WPA/PSK was selected on the AP it actually only spoke WPA2 to the clients!
Not helpful if your clients are not WPA2 ready! Some worked others did not.

I spoke to the vendor and after a firmware update of the AP it correctly negotiated with both types of clients!

[ChrisL]

Okay, we're going for the plan of changing to static IPs to see if that helps the situation. We've set half the cabinet to static and left half as DHCP and hope to find that any more failures are from #16 upwards.

Slight side issue with doing this, setting the IP to static breaks the ISA Firewall Client as it uses the WPAD data as sent out with DHCP to identify and connect to the proxy. The way around this we found is to configure DNS to include a mapping for WPAD so that the static computers can now find the proxy directly.

[chilbs]

You could try setting DHCP to Unicast from multicast.

This was taken from an extricom thread but may work.


"In order for your Windows clients to receive DHCP responses by unicast rather than broadcast, you need to configure the DHCP server accordingly to allow clients to request a unicast response. To do so, you must modify the registry on the DHCP server (assuming a Windows-based DHCP server).

1. On the server, open the Registry Editor and navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\DHCPServer\Parameters.

2. If the IgnoreBroadcastFlag value does not exist in this key, create it as a DWORD value.

3. Set the value of IgnoreBroadcastFlag to 0 to allow the clients to request unicast.

4. Close the Registry Editor and restart the DHCP server service."

Chilbs

[ranj]

You could try setting DHCP to Unicast from multicast.

This was taken from an extricom thread but may work.


"In order for your Windows clients to receive DHCP responses by unicast rather than broadcast, you need to configure the DHCP server accordingly to allow clients to request a unicast response. To do so, you must modify the registry on the DHCP server (assuming a Windows-based DHCP server).

1. On the server, open the Registry Editor and navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\DHCPServer\Parameters.

2. If the IgnoreBroadcastFlag value does not exist in this key, create it as a DWORD value.

3. Set the value of IgnoreBroadcastFlag to 0 to allow the clients to request unicast.

4. Close the Registry Editor and restart the DHCP server service."

Chilbs

Does this setting work on 2008 DHCP servers?