determine IP r without DHCP


I'm running linux on my laptop but my dhcp client doesn't always works when connecting to a hotspot.

Is there an easy way to determine the IP range and gateway of the connected hotspot without DHCP so I can setup my static IP accordingly?

tried kismet but that doesn't show the IP range with or without the "wepkey=$B:S:S:I,$wephexkey" option. Also ethereal only shows ARP packets....

The alternative now is to dual-boot into XP to see the correct values but that's always a hassle.



Reply to
Loading thread data ...

I think you're going at this from the wrong direction. XP isn't setting static IPs either - it just has a DHCP client with the correct configuration. So you need to establish what gets set up differently between Linux & Windows, then make sure that your Linux dhcp client (which one are you using) is set up correctly. ime, the only thing I've needed to play with is forcing it to send a hostname to the DHCP server (not likely an issue with a hotspot). I'm pretty sure figuring out why your DHCP client isn't working will be easier than any method of manually setting a static IP (especially one that won't interfere with operation of the hotspot).

Reply to
Derek Broughton

  1. What distribution/release?
  2. What DHCP client?
  3. What other network setup on the system?
  4. What firewall rules in place _before_ getting a DHCP lease? After?

Find out why your client isn't working. Faking it isn't going to be the right solution.

Sniffing may tell you what is going on - but how do you know what static address to choose? What you think might be unused could be idling while the user is getting another cup of coffee or what-ever.

IN THEORY, you can guess what the network range and mask are by noting the range of addresses seen - whether ARP, or DHCP requests, or what-ever. You may or may not get it right.

and runs into the same problem - is the address you guess going to be available or not. When you reboot, one of the things you are doing is telling the DHCP server that you don't need that address any more, and it _could_ be allocated to another.

Find out why your DHCP client isn't working, and fix that. Then you won't need to guess.

Old guy

Reply to
Moe Trin

Actually, it's the opposite. When you reboot, XP issues a DHCPRequest thus telling the DHCP server that you *need* that IP address. A DHCP Release is not issued during a reboot.


Reply to
David Taylor

"need"? I'm not an expert but it's more along the lines of "want", isn't it?

From my log: DHCPDISCOVER on eth1 to port 67 interval 5 DHCPOFFER from DHCPREQUEST on eth1 to port 67 DHCPACK from

at that point, the DHCP server said, "yes, here's your old IP of back". I think the DHCP server can also say DHCPNAK ("that IP is not currently available") at which point your client either gives up, or says "OK, give me anything you've got"
Reply to
Derek Broughton

Yeah ok, request that IP address.

What log is that from? Router or PC? PC running what because that's a complete DHCP address allocation? If that's linux then the behaviour is different to the NT OS.

Yes the DHCP server can Nack the DHCP request but the circumstances would be for a wrong subnet request as the most likely candidate at which point the whole DHCP process starts again.

All I was pointing out is that when XP starts, because it already has an address, it issues a DHCPRequest. There's a sublety in that if the machine has not been rebooted and needs to renew the address then it's a directed packet to the DHCPServer requesting the same IP address at 50% and then 87.5% of the lease time. However, if the machine is rebooted, XP still performs a DHCPRequest of the same IP address but this time as an IP broadcast. This is so that if the machine has moved and the subnet is now invalid, any DHCP server can nack the request and then XP moves to a DHCPDiscover.

If the machine has no valid address for the subnet then if it has moved, it cannot inform the original DHCP server that it is releasing the address, it can only obtain a new one from the new location.


Reply to
David Taylor Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.