Dhcp Client Suddenly Stopped Working

Neither my Land line nor my Wireless will pick up a DHCP signal anymore. It looks to the DHCP server and requests and address but never applies it to the configuration.

As the administrator I can see the DHCP logs on our SLES 9 server and I see the DHCP

requests ( client )
ack ( server )
offer ( server )
discover ( client )

commands but my system isn't accepting the address offered. It sits there and coninues to look but then never actually applies the offered address.

I can manually configure the Nic through network manager to use a static , but I don't see an option to set a default gateway and this becomes a real hassle as it reloads my BCM43xx driver everytime.



Stats :

Nic ( plugged in ) bcm5751
Wireless bcm4318 ( blacklisted bcm driver and using ndiswrapper )

It was working up until yesterday and for some reason can't today.



Any help would be greatly appreciated.

Use

route add default gw <IP-address-of-gateway>

to add your default gateway.
(See man route).

Btw in my system YaST > network Devices > Network Card has a tab Routing. Very easy!

Use

route add default gw <IP-address-of-gateway>

to add your default gateway.
(See man route).

Btw in my system YaST > network Devices > Network Card has a tab Routing. Very easy!
[/b]

Thank you for this , but I think my biggest concern is the DHCP options ,... While looking in the System log I found this :



dhcdbd: dhco_input_option: Value -1 cannot be converted to Type L

dhcdbd: dhco_parse_Option_settings: bad option setting; old_dhcp_lease_time: = -1

dhclient: bound to 127.0.0.61 -- renewal in 939630695 seconds

dhclient: caught deadly SIGTERM

dhclient: could not restore resolve.conf : no such file or directory

dhclient DHCP RELEASE




This continues to loop over and over until it decides to accept the defaulted 169.x.x.x address.

I am afraid I can only give some assistance in details (like above, it was only to give you a bypass).

You mention in the error messages: resolve.conf. Is that a typo? Should be resolv.conf imho.
When yes, it is about /etc/resolv.conf not existing. You could check if it is there and if it is rw by root.

Then I will be off for vacation , so I will not read your answer for a long time, sorry.

I am afraid I can only give some assistance in details (like above, it was only to give you a bypass).

You mention in the error messages: resolve.conf. Is that a typo? Should be resolv.conf imho.
When yes, it is about /etc/resolv.conf not existing. You could check if it is there and if it is rw by root.

Then I will be off for vacation , so I will not read your answer for a long time, sorry.
[/b]

Yes it was a Typo , But I found the issue :





I had two different Servers giving me a DHCP OFFER ... It turns out there was a rogue DHCP server turned on in another section of IT here. I checked the machine that was handing them out and shut it down ... Suddenly My connection was instantanious

That rogue machine hands out a 127.0.0.x addresses because it was never configured to give out addresses in our scheme. This might be why the -1 release value is there as well.


Thank you for your help and enjoy vacation

Yes it was a Typo , But I found the issue :
I had two different Servers giving me a DHCP OFFER ... It turns out there was a rogue DHCP server turned on in another section of IT here. I checked the machine that was handing them out and shut it down ... Suddenly My connection was instantanious

That rogue machine hands out a 127.0.0.x addresses because it was never configured to give out addresses in our scheme. This might be why the -1 release value is there as well.
Thank you for your help and enjoy vacation
[/b]

Good network mangement! We once had a Mac switched on again after 2 years, it happened to have the same IP address as the Mainframe we run. Took us half a day of mainframe outage

Glad you found it. I will drink one on your behalf