Toshiba WinXP laptop fails to acquire (DHCPREQUEST) new IP after connection to different network

Question

My laptop is a Toshiba Satellite Pro with French Win XP SP3 with all current updates; Toshiba includes a software Tool "ConfigFree" for quick change of Network parameters.

Until ~December it worked fine, DHCP in more than 3 different networks (wired networds in 2 universities and at home, as well as some WLANs) always acquired an IP address properly; I didn't need to change any Network parameters. Roughly since I've moved to a new flat (where a new DSL modem & router were installed), I'm having a weird problem (which might just happen to coincide with the move).

After a reboot, the machine always acquires an DHCP address correctly. But if I put it into standby while I'm in Lab A and take it either home or to Lab B, it fails to switch over to the new network. That means, the laptop sends DHCPDISCOVER, the DHCP server sends DHCPOFFER but never receives an DHCPREQUEST from the laptop. The laptop seems to be deaf to the response from the server and keeps trying for a while before assigning itself a useless 168.x.x.x address. "Repairing" the connection doesn't work, neither does ipconfig /renew. Disactivating/Reactivating the network card does not help. A reboot DOES help, but I would like to understand what's wrong so I can fix it.

The same problem occurs in different networks that I was able to connect to successfully (without reboot) until a few months ago, but I don't recollect changing anything on my machine, apart from allowing semi-automatic software updates (Windows etc.). I've analyzed it systematically only for wired ethernet connections, but I have seen the same problem happening for a VPN tunnel (FortiClient) and wireless connections.

When the DHCP has failed, I can manually (or using the FreeConfig tool, see above) switch to a static IP (if I happen to know what range to pick from); I've successfully used this workaround for a while now since it avoids rebooting. I can later go back to Standby, go back to Lab A (where the laptop was initially booted), switch back to DHCP without problems.

Update

I reflashed the BIOS even though I'm quite sure it was up to date, then reinstalled & updated the network drivers (network card & wireless). I reset TCP/IP using netsh int ip reset c:\resetlog.txt and Winsock using netsh winsock reset as suggested in this SU post. The former command removed some integration with my Firewall/VPNClient/Antivirus solution FortiClient, so I had to reinstall that to get IPSEC VPN working again. After all this, the problem seems to have gone down - DHCP now works on first reconnect after standby.

If I disconnect / reconnect the network cable at home (or switch off the wireless transmission and then back on) the corresponding device shows the same old symptoms (no DHCP) again, even if it had just worked the first time some seconds ago. Reinstalling the network driver gives me another shot at acquiring an IP ;-).

After some more playing around, I realized that this remaining problem actually seems to be caused by the Firewall in FortiClient - deactivating it temporarily resolves the issue. So I guess I will contact the company Fortinet to see what they have to say about this...

Answer 1

It does sound like a driver issue. At the very least, reinstall the original driver. A patch may have changed its configuration or dependencies.

Optimally, update your mainboard (chipset) drivers and your network drivers and see what this does.

Also, Windows' built in networking has the abilities to switch networks, securely store multiple wireless profiles in a preference-sorted list, and just about everything else useful the Toshiba ConfigFree application tried to do. I have yet to find an add-on or OEM application (every hardware manufacturer has these special bloatware apps loaded on their machines now) that does more than Windows does with sufficient difference to outweigh the cost of running these often bloated and more design-savvy than function-savvy applications.

I'd recommend removing the ConfigFree app. You can always download the latest version and reinstall it if you find it has functions you absolutely need. But if you're just shuttling between three different networks, Windows can handle that on it's own.

Also, it will be one less possible point of failure in troubleshooting.

Finally, in my experience drivers and standby or hibernation are less than busom buddies. The fact that they worked before means they should work now, but differences in supported power states by various drivers can cause untold frustration. I've found most the problems with laptops occur with hibernated or stood-by laptops being undocked, which is a relatively significant hardware change for an essentially paused system. But network changes have also caused problems.