Bug 136123
Summary: | dhclient never gets lease though one is offered | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dan Williams <dcbw> | ||||
Component: | dhcp | Assignee: | Jason Vas Dias <jvdias> | ||||
Status: | CLOSED WONTFIX | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | ||||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2004-11-01 20:26:38 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 123268 | ||||||
Attachments: |
|
Description
Dan Williams
2004-10-18 02:52:52 UTC
dhclient does work OK without the corresponding /etc/sysconfig/network-scripts/ifcfg file - it should emit a message like : 'configuration for ${interface} not found. Continuing with defaults' The 'dhclient.c(2057): null pointer' is harmless (but will be removed from next release) - the code is attempting to free a pointer twice (but emits the error message instead), when it is forming the DECLINE. On inspecting the code, the only reason dhclient sends a decline is if the dhclient-script returns non-zero; and the only reason that the dhclient-script returns non-zero is if a ping to the lease address succeeds before the address is configured on a local interface; in other words, some machine is responding to a ping for the address that your server provides. Please verify this by getting a tcpdump: $ pkill dhclient $ ifconfig ${IF} 0.0.0.0 up $ tcpdump -nl -i ${IF} -vv -X -s 2048 port bootps or port bootpc or icmp 2>&1 > /tmp/tcpdump.log $ dhclient ${IF} 2>&1 | tee /tmp/dhclient.log ... (wait for DECLINE) $ pkill tcpdump And then append the resulting /tmp/tcpdump.log and /tmp/dhclient.log files to this bug. Thanks, Jason Vas Dias Created attachment 105697 [details]
log when dhclient can't get address
same dhclient log, but can't get dhcp address. See tcpdump log above. For example: Oct 17 21:55:39 localhost dhclient: dhclient.c(2057): null pointer Oct 17 21:55:39 localhost dhclient: DHCPDECLINE on eth1 to 255.255.255.255 port 67 Oct 17 21:55:39 localhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4 Oct 17 21:55:41 localhost udev[4159]: removing device node '/dev/0000:07:00.0' Oct 17 21:55:41 localhost dhclient: DHCPOFFER from 192.168.0.1 Oct 17 21:55:41 localhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67 Oct 17 21:55:43 localhost dhclient: DHCPACK from 192.168.0.1 Oct 17 21:55:43 localhost dhclient: dhclient.c(2057): null pointer Oct 17 21:55:43 localhost dhclient: DHCPDECLINE on eth1 to 255.255.255.255 port 67 Oct 17 21:55:43 localhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5 Oct 17 21:55:44 localhost dhclient: DHCPOFFER from 192.168.0.1 Oct 17 21:55:44 localhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67 Oct 17 21:55:46 localhost dhclient: DHCPACK from 192.168.0.1 Oct 17 21:55:46 localhost dhclient: dhclient.c(2057): null pointer Oct 17 21:55:46 localhost dhclient: DHCPDECLINE on eth1 to 255.255.255.255 port 67 Oct 17 21:55:46 localhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7 Oct 17 21:55:48 localhost dhclient: DHCPOFFER from 192.168.0.1 Oct 17 21:55:48 localhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67 Oct 17 21:55:49 localhost dhclient: DHCPACK from 192.168.0.1 Oct 17 21:55:50 localhost dhclient: dhclient.c(2057): null pointer Oct 17 21:55:50 localhost dhclient: DHCPDECLINE on eth1 to 255.255.255.255 port 67 Oct 17 21:55:50 localhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6 -------- Forwarded Message --------
From: Peter Jones <pjones>
To: Dan Williams <dcbw>
Subject: Re: [PATCH] NetworkManager: fix dhclient subscripts dying
with sigpipe
Date: Thu, 28 Oct 2004 14:15:35 -0400
On Thu, 2004-10-28 at 13:34 -0400, Dan Williams wrote:
> Hi,
>
> Patch looks great, but could you elaborate ont he problem a bit? I've
> seen it too and been trying to track it down...
>
If you use "NULL, NULL", g_spawn_sync doesn't ever read from the
stdout/stderr file descriptors it exec's the scripts with. This is fine
if you've already got an interface set up (i.e. you have ifcfg-eth0).
But if you don't, then when dhclient runs dhclient-script, the
subprogram will give an error like:
/sbin/dhclient-script: configuration for eth1 not found. Continuing with
defaults.
/etc/sysconfig/network-scripts/network-functions: line 47: eth1: No such
file or directory
And it'll get a SIGPIPE. So then when dhclient says "did the connect
script work", it'll see that it exited with an unhandled signal. So
then it sends a DHCPDECLINE and exits failure.
If you have a place to store the output, g_spawn_sync happily does the
appropriate select()/read() combinations, puts it at the pointer we give
it, and all is good.
Arguably, we probably aught to make dhclient-script function better in
the case of an unconfigured network, as well.
RE: Comment #6: Wouldn't the best idea be for the program that invokes dhclient to redirect its child's stdout & stderr to /dev/null (or to a real file) if it doesn't want to read the child's output ? I run dhclient for an interface without an /etc/sysconfig/ifcfg-* file, and it works fine - and the output helpfully tells me that the scripts are looking for an ifcfg- file and can't find one. If we changed the dhclient-script and the /etc/sysconfig/network/functions script (part of initscripts) to remain silent, then users would be none the wiser that essential network configuration files were missing - so I don't think the scripts should not emit these messages or direct them to /dev/null. Other programs that invoke these scripts might also expect some output if there was a problem. The invoking program could also create an empty /etc/sysconfig/network-scripts/ifcfg- file to avoid this problem occurring. On the other hand, we could change the scripts to ignore SIGPIPE, I suppose. Or we could direct all script output to initlog ... I'm in favor of fixing this problem in the invoking program; if this cannot be done, I'll change the scripts to trap and ignore SIGPIPE. Let me know your ideas on this. will fix in networkmanager |