Hello All, I have a LAN of 5 machines, all running SuSE8.2 Pro. Each has 2 NICs - eth0 faces an ADSL router which provides an IP by DHCP and dynamically assigns DNS, gateway etc. eth1 faces the internal network and has a static IP. Each machine has a static hostname. SuSEfirewall2 is configured to protect eth0 on each machine (all running services) and the DHCP client variable is set on all machines. In all cases, eth0 is only used for internet access, I use the second network for 'internal' services (NIS, nfs, ...). Now, two machines report during boot that DHCP for eth0 has failed, but by the time I can log in ifconfig reports a valid IP address. Also, if I manually rcnetwork restart, eth0 reports DHCP failure, but an immediate ifconfig shows an address. In both cases the IP address seems constant - i.e. machine 'frodo' always has 10.0.0.14 So, can anyone suggest what might be causing this behaviour? The router provides infinite leases (at least, theoretically) so I'd like to be able to manually force one of these abberant machines to relese its IP lease so that a different IP gets assigned - my reasoning being that if 'frodo' says DHCP fails, but still recieves an IP (but not 10.0.0.14) I know the DHCP is working and that the failure report is a ghost. I hope I've made sense... Cheers Dylan -- Sweet moderation Heart of this nation Desert us not We are between the wars - Billy Bragg
On 06/21/2003 08:24 AM, Dylan wrote:
I have a LAN of 5 machines, all running SuSE8.2 Pro. Each has 2 NICs - eth0 faces an ADSL router which provides an IP by DHCP and dynamically assigns DNS, gateway etc. eth1 faces the internal network and has a static IP. Each machine has a static hostname. SuSEfirewall2 is configured to protect eth0 on each machine (all running services) and the DHCP client variable is set on all machines.
So, can anyone suggest what might be causing this behaviour?
I have seen dhcpcd behaving like this. I always end up replacing dhcpcd with dhclient. It could be I am more used to dhclient (used it since 6.4), but it always worked when dhcpcd wouldn't consistently. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Web Address: http://www.mydestiny.net/~joe_morris Registered Linux user 231871 God said, I AM that I AM. I say, by the grace of God, I am what I am.
Hi, Am Samstag, 21. Juni 2003 02:24 schrieb Dylan: [...]
Now, two machines report during boot that DHCP for eth0 has failed, but by the time I can log in ifconfig reports a valid IP address. Also, if I manually rcnetwork restart, eth0 reports DHCP failure, but an immediate ifconfig shows an address.
Looks like a timing problem. The DHCP client startup script looses patience with the server and reports "failed". Nevertheless the client still keeps listening. And shortly after that the server response comes and everything is fine. It's a cosmetical problem. Greetings from Bremen hartmut
On Saturday 21 June 2003 09:49, Hartmut Meyer wrote:
Hi,
Am Samstag, 21. Juni 2003 02:24 schrieb Dylan:
[...]
Now, two machines report during boot that DHCP for eth0 has failed, but by the time I can log in ifconfig reports a valid IP address. Also, if I manually rcnetwork restart, eth0 reports DHCP failure, but an immediate ifconfig shows an address.
Looks like a timing problem. The DHCP client startup script looses patience with the server and reports "failed". Nevertheless the client still keeps listening. And shortly after that the server response comes and everything is fine.
No, the failed indication is immediate - not timeout dots, no "No IP address yet... Backgrounding message", just a fat red failed immediately. Dylan -- Sweet moderation Heart of this nation Desert us not We are between the wars - Billy Bragg
On Sat, Jun 21, 2003 at 01:24:28AM +0100, Dylan wrote:
for 'internal' services (NIS, nfs, ...). Now, two machines report during boot that DHCP for eth0 has failed, but by the time I can log in ifconfig reports a valid IP address. Also, if I manually rcnetwork restart, eth0 reports DHCP failure, but an immediate ifconfig shows an address. [...]
So, can anyone suggest what might be causing this behaviour? The router provides infinite leases (at least, theoretically) so I'd like to be able to
The infinity of the leases is causing this. The DHCP client immediately realizes that there is nothing to do (because the lease never ends) and quits, which is interpreted by the init script as failure. It is a cosmetical problem (at least, unless you rely on the output or return code of the rcnetwork script for other purposes). It is on my todo list for the next SuSE version, but to my understanding it should not be a common situation because infinite leases should be a fairly uncommon configuration. I suggest to change the lease duration to one week, or so, to work around the current limitation. Peter
On Monday 23 June 2003 15:39, poeml@cmdline.net wrote:
On Sat, Jun 21, 2003 at 01:24:28AM +0100, Dylan wrote:
for 'internal' services (NIS, nfs, ...). Now, two machines report during boot that DHCP for eth0 has failed, but by the time I can log in ifconfig reports a valid IP address. Also, if I manually rcnetwork restart, eth0 reports DHCP failure, but an immediate ifconfig shows an address. [...]
So, can anyone suggest what might be causing this behaviour? The router provides infinite leases (at least, theoretically) so I'd like to be able to
The infinity of the leases is causing this. The DHCP client immediately realizes that there is nothing to do (because the lease never ends) and quits, which is interpreted by the init script as failure.
OK, that makes sense.
It is a cosmetical problem (at least, unless you rely on the output or return code of the rcnetwork script for other purposes).
Would that be why the _net_dev option for nfs is causing problems on the offending machines?
It is on my todo list for the next SuSE version, but to my understanding it should not be a common situation because infinite leases should be a fairly uncommon configuration.
I suggest to change the lease duration to one week, or so, to work around the current limitation.
Unfortunately I don't have that control over the router (not a configurable option) so I'll put up with it. OTOH, is there a command I can add to the stop part of the rcnetwork script to explicitly release the lease? Cheers Dylan -- Sweet moderation Heart of this nation Desert us not We are between the wars - Billy Bragg
On Mon, Jun 23, 2003 at 04:04:34PM +0100, Dylan wrote:
On Monday 23 June 2003 15:39, poeml@cmdline.net wrote:
On Sat, Jun 21, 2003 at 01:24:28AM +0100, Dylan wrote:
So, can anyone suggest what might be causing this behaviour? The router provides infinite leases (at least, theoretically) so I'd like to be able to
The infinity of the leases is causing this. The DHCP client immediately realizes that there is nothing to do (because the lease never ends) and quits, which is interpreted by the init script as failure.
OK, that makes sense.
[...]
Would that be why the _net_dev option for nfs is causing problems on the offending machines?
Hhm, I'm not sure what you mean with _net_dev option here...
I suggest to change the lease duration to one week, or so, to work around the current limitation.
Unfortunately I don't have that control over the router (not a configurable
Okay.
option) so I'll put up with it. OTOH, is there a command I can add to the stop part of the rcnetwork script to explicitly release the lease?
Yes, you can set DHCLIENT_RELEASE_BEFORE_QUIT in /etc/sysconfig/network/dhcp, but do you think that would make a difference? Peter
On Tuesday 01 July 2003 10:01, poeml@cmdline.net wrote:
On Mon, Jun 23, 2003 at 04:04:34PM +0100, Dylan wrote:
On Monday 23 June 2003 15:39, poeml@cmdline.net wrote:
On Sat, Jun 21, 2003 at 01:24:28AM +0100, Dylan wrote:
So, can anyone suggest what might be causing this behaviour? The router provides infinite leases (at least, theoretically) so I'd like to be able to
The infinity of the leases is causing this. The DHCP client immediately realizes that there is nothing to do (because the lease never ends) and quits, which is interpreted by the init script as failure.
OK, that makes sense.
[...]
Would that be why the _net_dev option for nfs is causing problems on the offending machines?
Hhm, I'm not sure what you mean with _net_dev option here...
It's a mount option for nfs filesystems - makes nfs wait until network is available before making mount attempts. It changes the error reported when trying to access an unavailable nfs mount from something semi-random to a reliable "network not available"
I suggest to change the lease duration to one week, or so, to work around the current limitation.
Unfortunately I don't have that control over the router (not a configurable
Okay.
option) so I'll put up with it. OTOH, is there a command I can add to the stop part of the rcnetwork script to explicitly release the lease?
Yes, you can set DHCLIENT_RELEASE_BEFORE_QUIT in /etc/sysconfig/network/dhcp, but do you think that would make a difference?
Well, someone suggested it may be a lease length issue - so if the lease is explicitly relesed it may go away...
Peter
-- Sweet moderation Heart of this nation Desert us not We are between the wars - Billy Bragg
participants (4)
-
Dylan -
Hartmut Meyer -
Joe Morris (NTM) -
poeml＠cmdline.net