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