viper001
asked on
IP address locked on HP-UX
My company is running an HP 9000/800 server using HP-UX 10.20. Every so often the T-1 connection in our WAN may go down or a Win '95 workstation may crash and the IP address the machine was using is now locked. Even after rebooting the workstation. It happens with static IP's and dynamically assigned IP's. When the server is rebooted everything goes back to normal. The only workaround we have come up with is assigning the machine a new IP address until the server is rebooted. The problem comes when we have a printer that is attached to a workstation and shared through the HP box. When we change the IP we have to change other config files as well. What a pain. Any idea on how to free the locked IP?
Thank You,
William Adams
Thank You,
William Adams
bchew
Try running winipcfg and select "release all", then "renew all"
ASKER
This problem occurs with Static and Dynamic IP's. When you have a Static IP assigned in Windows, the release and renew options are not available. Not to mention I have tried that already with the dynamically assigned IP's and it did not work. Plus when I reboot the IP should renew when a request is sent to the DHCP server.
Any other ideas?
Thank You,
William
Any other ideas?
Thank You,
William
Kill inetd an restart it.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I do not know why the server does not check the hardware address of the client and verify it according to the DHCP daemon. I am not at the location where this problem is happening. I am trying to help them diagnose it remotely. Unfortunatley their understanding of Unix is very limited and I have to walk them through everything. I use Linux not HP-UX at my location so commands and such are slightly different. The Problem also happens however when I specify an IP address on the Windows '95 box instead of relying on the dhcp server to assign an address. At this point the Windows box should generate an IP conflict error if the Unix box thinks the address is still in use. However this is not the case. The windows box can ping every other machine on the network including going over routers and such, but cannot ping or talk to the HP box in any way. This is very strange. It is as if the HP box is just not allowing any requests form the locked IP. Maybe this has something to do with some sort of security setting on the HP? Maybe the HP thinks the Windows box is trying to spoof it's IP since it thinks it is already in use? Any other thoughts?
If this is a "normal" HP-UX and not one with C2 or higher security level (which i am not knowledgeable), then this shouldn't be a problem with some security policy or settings.
Are you assigning the same IP address to the Win95 box ? I mean the same that was assigned by the DHCP server ? If not, then probably here is what happens -- other machines (not DHCP servers) has already flushed their ARP cache, at least for that Win95 box in question. So next time you ping some other machine/router, it will issue ARP request, your machine will reply from the NEW IP address, and voala -- the other machines will know your new IP address and relate it with the hardware (ethenet) address. However, the DHCP server, probably because of some optimization, will not clear the ARP cache, until the lease forIP address has not expired. If this is the case, try to clear the ARP cache on the server, arp -d if I am not mistaken.
But if you assign the same IP address, well it becomes more complicated. Tell me which one it is.
Are you assigning the same IP address to the Win95 box ? I mean the same that was assigned by the DHCP server ? If not, then probably here is what happens -- other machines (not DHCP servers) has already flushed their ARP cache, at least for that Win95 box in question. So next time you ping some other machine/router, it will issue ARP request, your machine will reply from the NEW IP address, and voala -- the other machines will know your new IP address and relate it with the hardware (ethenet) address. However, the DHCP server, probably because of some optimization, will not clear the ARP cache, until the lease forIP address has not expired. If this is the case, try to clear the ARP cache on the server, arp -d if I am not mistaken.
But if you assign the same IP address, well it becomes more complicated. Tell me which one it is.
ASKER
We have assigned the SAME address...Hopefully this does not add too much more complexity...
William Adams
William Adams
Well, that's interesting. If this is really important issue that you have to address and resolve ASAP, then go and get a protocol analizer. Attach to the HP's NIC and listen.
Otherwise, use packet dump tool, like snoop (on Solaris) or tcpdump. Now I can only speculate. Can you check/list the content of the DHCP server's db ? At the time when you manually assigned IP address to that Win95 box (which was not able to communicate with the HP), is the server still believing the lease for that IP address is in effect ? Definitely, the DHCP server gets confised, and prevents the upper layer, be it ICMP or TCP/UDP to process your ping requests.
You realize that you create a contradiction -- once you declare the address to the IP pool, and then you manually, statically, assign it to some machine (Win95). However it is not the client that should detect the conflict, but the server. The client hs got its address, and probably does not even care to support dhcp client code (and why should it). It is the server that behaves strangely.
Were you able to lower the timeout value for the lease between the DHCP server and clients ?
Otherwise, use packet dump tool, like snoop (on Solaris) or tcpdump. Now I can only speculate. Can you check/list the content of the DHCP server's db ? At the time when you manually assigned IP address to that Win95 box (which was not able to communicate with the HP), is the server still believing the lease for that IP address is in effect ? Definitely, the DHCP server gets confised, and prevents the upper layer, be it ICMP or TCP/UDP to process your ping requests.
You realize that you create a contradiction -- once you declare the address to the IP pool, and then you manually, statically, assign it to some machine (Win95). However it is not the client that should detect the conflict, but the server. The client hs got its address, and probably does not even care to support dhcp client code (and why should it). It is the server that behaves strangely.
Were you able to lower the timeout value for the lease between the DHCP server and clients ?
Note in HP-UX side,
1) You can start troubleshooting by using the "lanscan". This will show something like
Path address so on ...
the two important info are the hardware state and software state.
If hardaware is UP and Software is DOWN, you can restart it by issuing "landiag lano UP", lan0 is your lan card special file.
If on the other hand the hardware is down, you need to reset the card using "landiag", and coosing reset from the menu. Of couse all this tools will need root provilege. If there is and NFS use in the HP-UX side, it can lock the mount when the lan goes down. It will try to mount the NFS with a very high priority, and then say that the NFS it STALE. The way around is to set the NFS remount mont to a limit samll reattempts. The easy way would be the use of SAM, Sya Adm Tool, provided by HP.
HP has network spy and info aquisition tools. They need to be set for the address you want to monitor, and the amount of info, you want to collect. The nettl is the tool.
1) You can start troubleshooting by using the "lanscan". This will show something like
Path address so on ...
the two important info are the hardware state and software state.
If hardaware is UP and Software is DOWN, you can restart it by issuing "landiag lano UP", lan0 is your lan card special file.
If on the other hand the hardware is down, you need to reset the card using "landiag", and coosing reset from the menu. Of couse all this tools will need root provilege. If there is and NFS use in the HP-UX side, it can lock the mount when the lan goes down. It will try to mount the NFS with a very high priority, and then say that the NFS it STALE. The way around is to set the NFS remount mont to a limit samll reattempts. The easy way would be the use of SAM, Sya Adm Tool, provided by HP.
HP has network spy and info aquisition tools. They need to be set for the address you want to monitor, and the amount of info, you want to collect. The nettl is the tool.
ASKER
Thank You all very much for all you help and comments. I am waiting for this problem to creep up on me again to test out the suggestions yoiu have given me...Thank You,
William Adams
William Adams