|Remember that I'm talking purely from the client PC's point of view. I have no control over the DHCP server. In this case the DHCP provider is a public WiFi provider, and their tech support is, shall we say, not that technical.|
I know about static addressing in DHCP - in fact years ago before DHCP was created I kludged a similar feature for DOS machines using "net config" to grab its MAC address to populate a bootp server's database - IOW, I know a little about networking. And static DHCP is how I normally configure my own wireless router's DHCP server config.
But I'm talking about the client here, not the server. My real point is under what condition would Windows XP's IP client software be either (a) really issuing a DHCP request even though it's disabled in the registry entry for that interface, or (b) why would ipconfig and the Network Connections status page report that it was waiting for a DHCP response from a server if the client IP stack didn't issue a DHCP request.
And what I'm talking about regarding 0.0.0.0 in ipconfig is that even though I've added a secondary address to the IPAddress key for that interface in the registry (the key data is "0.0.0.0 192.168.128.10") and the SubnetMask key ("0.0.0.0 255.255.255.0"), when I run the command ipconfig, it shows only the 0.0.0.0 address and netmask, not the other entries.
You do know something about secondary IP addressing in XP, don't you? Of course, Microsoft's GUI screws it up if you're not careful since Microsoft believes that there's no reason a user would want a DHCP primary and a manual secondary address on the same physical interface. It's much simpler to do in Linux (and I believe BSD, but I haven't messed with that since the 386BSD days).
Any gurus have a clue?