[lug] dhcpcd lease issue

D. Stimits stimits at attbi.com
Wed Aug 21 13:03:06 MDT 2002


Chuck Wiechman wrote:
> Hmm very interesting. Running the fuser command now it is there, so
> it looks like your are on to something here. Here is the  output you asked
> for. I will have to work on the strace stuff later. 
> 
> Should I just set this up for pump and call it good, or do you think I 
> have something else really hosed here?

Personally, I could not get pump to work (KRUD 7.3), but that might be 
due to other network setup issues at the time. I installed dhcpcd, and 
it worked without even trying to configure it (but at the time, network 
setup was also further progressed, so it might not be that dhcpcd was 
any easier, could have just been illusion).

> 
> Thanks for your help!
> 
> 
>  
>  
>  /sbin/fuser -v -u -n tcp "68" -n udp "68"
> 
>                       USER        PID ACCESS COMMAND
> 					  68/udp               root        950 f....  dhcpcd
> 					  
> 
> 
>>on the no-longer-valid-no-longer-listening socket, this might happen as 
>>a side-effect.
>>
>>In other words, it might just be a symptom of earlier loss of listening 
>>to the socket. If
>>  /sbin/fuser -v -u -n tcp "68" -n udp "68"
>>...does not show dhcpcd listening, you *cannot* succeed, nor can you 
>>treat an old and no-longer-listening socket with the same ioctl, 
>>pretending it is still valid.
>>
>>What is in your
>>  /etc/sysconfig/network-scripts/eth0-cfg?
> 
> 
> more ifcfg-eth0 
> DEVICE=eth0
> BOOTPROTO=dhcp
> ONBOOT=yes

Then "/etc/rc.d/init.d/network restart" (or its wrapper cousin, 
"service") should be a useful way to restart if it does fail...should it 
detect a program is no longer up, like dhcpcd, it should restart.

> 
> 
> 
>>What is the output in /var/log/messages after running
>>  "/etc/rc.d/init.d/network restart"?
> 
> 
> Aug 21 12:17:00 merlin network: Shutting down interface eth0:  succeeded
> Aug 21 12:17:01 merlin network: Shutting down loopback interface:  succeeded
> Aug 21 12:17:01 merlin sysctl: net.ipv4.ip_forward = 0
> Aug 21 12:17:01 merlin sysctl: net.ipv4.conf.default.rp_filter = 1
> Aug 21 12:17:01 merlin sysctl: kernel.sysrq = 0
> Aug 21 12:17:01 merlin sysctl: kernel.core_uses_pid = 1
> Aug 21 12:17:01 merlin network: Setting network parameters:  succeeded
> Aug 21 12:17:01 merlin network: Bringing up loopback interface:  succeeded
> Aug 21 12:17:01 merlin ifup: Determining IP information for eth0...
> Aug 21 12:17:01 merlin kernel: xircom cardbus adaptor found, registering as eth0, using irq 11 
> Aug 21 12:17:01 merlin ifup:  done.
> Aug 21 12:17:02 merlin network: Bringing up interface eth0:  succeeded

Looks perfect.

> 
> 
> eth0      Link encap:Ethernet  HWaddr 00:10:A4:E0:43:DF  
>           inet addr:10.1.1.54  Bcast:10.1.1.255  Mask:255.255.255.0
>           UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:5348 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:631 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100 
>           RX bytes:1582787 (1.5 Mb)  TX bytes:130868 (127.8 Kb)
>           Interrupt:11 Base address:0x4000 

Looks normal.

> 
> 
> /sbin/fuser -v -u -n tcp "68" -n udp "68"
> 
>                      USER        PID ACCESS COMMAND
> 					 68/udp               root       3356 f....  dhcpcd

This is how it should always look.

> 
> ps -ef | grep dhcp
> root      3356     1  0 12:17 ?        00:00:00 /sbin/dhcpcd -n eth0

This is how it renews a lease on startup, passing the -n, this is just 
like my dhcpcd ps looks. Seems startup command is not related to the 
problem. Btw, you might cd to /etc/dhcpc/ and /etc/dhcpcd/, and poke 
around to see if anything looks worthy of investigating. Perhaps an old 
cache file is doing something weird. If you manually stop dhcpcd via 
/etc/rc.d/init.d/dhcpcd stop, then move those cache files to a temp 
location, and restart, there *might* be some improvement/failure/debug 
message that is useful (wouldn't bother unless the problem keeps showing 
up).

D. Stimits, stimits AT attbi.com

> 
> 
> 
>>You could temporarily do something that will give lots of output, but 
>>you only care about the last page or so of output. The system call 
>>tracer "strace" can be output to another terminal or console, and you 
>>can thus see the last page of output. Here is a demonstration of what I 
>>am getting at. Assume you have a console tty2, the 2nd console login for 
>>non-graphical logins. Regardless of whether anything is logged in there, 
>>do this as root from another window or console:
>>   echo "testing this" > /dev/tty2
>>
>>You will see this message on tty2, though it won't actually do anything. 
>>Sort of how wall works. If you use strace on your dhcp client, and 
>>redirect stderr to /dev/tty2, it will also do this, but with debugging 
>>information on system calls. You are only interested in the last page of 
>>data, and you could even filter through with a case-insensitive filter 
>>for "ioctl" (assumes bash shell syntax for redirecting stderr to stdout):
>>  strace TheProgram 2>&1 | \
>>     awk -v IGNORECASE=1 '/(SIO|ioctl|[=] [-])/,/[)]' > \
>>     /dev/tty2
>>
>>(the above is a case insensitive filter for "sio", "ioctl", or lines 
>>ending with "= -", because negative return values are failure...though 
>>not all failures are significant)
>>
>>To see how it works try this sample (set for console 2):
>>strace echo "SIO and ioctl" 2>&1 | \
>>awk -v IGNORECASE=1 '/(SIO|ioctl|[=] [-])/,/[)]/' \
>> > /dev/tty2
>>
>>If you go to console 2, you will see something similar to this:
>>execve("/bin/echo", ["echo", "SIO and ioctl"], [/* 38 vars */]) = 0
>>open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or 
>>directory)
>>write(1, "SIO and ioctl\n", 14SIO and ioctl
>>)         = 14
>>
>>
>>With the above strace filter, more information is possibly available to 
>>figure out why it dies. A convenient way to do all of the above might be 
>>to create a bash script called dhcpcd, that runs the real dhcpcd, 
>>passing along all arguments, and running it under strace. The real 
>>dhcpcd can be moved somewhere else, or renamed (e.g., dhcpc-original), 
>>with the script knowing what the new name/location is. Then it won't 
>>matter who/what calls /sbin/dhcpcd, it will go to the console named, in 
>>filtered form.
>>
>>D. Stimits, stimits AT attbi.com
>>
>>
>>
>>> 
>>>Aug 21 10:00:56 merlin dhcpcd[950]: dhcpStop: ioctl SIOCSIFFLAGS: 
>>>Inappropriate ioctl for device
>>>
>>>*** it has changed from 10.1.1.53 to .54
>>>
>>>eth0      Link encap:Ethernet  HWaddr 00:10:A4:E0:43:DF  
>>>          inet addr:10.1.1.54  Bcast:10.1.1.255  Mask:255.255.255.0
>>>          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
>>>          RX packets:4354 errors:0 dropped:0 overruns:0 frame:0
>>>          TX packets:62 errors:0 dropped:0 overruns:0 carrier:0
>>>          collisions:0 txqueuelen:100 
>>>          RX bytes:1490307 (1.4 Mb)  TX bytes:11616 (11.3 Kb)
>>>          Interrupt:11 Base address:0x4000 
>>>
>>>
>>>>From the dhcp server (notice that the .53 lease started this morning when 
>>>I booted the computer.
>>>
>>>Aug 21 10:06:03 firewall dhcpd: DHCPDISCOVER from 00:10:a4:e0:43:df via eth0
>>>Aug 21 10:06:03 firewall dhcpd: Abandoning IP address 10.1.1.53: pinged before offer
>>>Aug 21 10:06:03 firewall dhcpd: DHCPDISCOVER from 00:10:a4:e0:43:df via eth0
>>>Aug 21 10:06:04 firewall dhcpd: DHCPOFFER on 10.1.1.50 to 00:10:a4:e0:43:df via eth0
>>>Aug 21 10:06:04 firewall dhcpd: DHCPDISCOVER from 00:10:a4:e0:43:df via eth0
>>>Aug 21 10:06:05 firewall dhcpd: DHCPOFFER on 10.1.1.54 to 00:10:a4:e0:43:df via eth0
>>>Aug 21 10:06:05 firewall dhcpd: DHCPREQUEST for 10.1.1.54 from 00:10:a4:e0:43:df via eth0
>>>Aug 21 10:06:05 firewall dhcpd: DHCPACK on 10.1.1.54 to 00:10:a4:e0:43:df via eth0
>>>Aug 21 10:06:05 firewall dhcpd: DHCPREQUEST for 10.1.1.54 from 00:10:a4:e0:43:df via eth0
>>>Aug 21 10:06:05 firewall dhcpd: DHCPACK on 10.1.1.54 to 00:10:a4:e0:43:df via eth0
>>>Aug 21 10:06:06 firewall dhcpd: DHCPREQUEST for 10.1.1.54 from 00:10:a4:e0:43:df via eth0
>>>Aug 21 10:06:06 firewall dhcpd: DHCPACK on 10.1.1.54 to 00:10:a4:e0:43:df via eth0
>>>
>>>
>>>
>>>lease 10.1.1.53 {
>>>        starts 3 2002/08/21 16:06:03;
>>>        ends 3 2002/08/21 16:06:03;
>>>        abandoned;
>>>
>>>lease 10.1.1.54 {
>>>        starts 3 2002/08/21 16:06:06;
>>>        ends 3 2002/08/21 20:06:06;
>>>        hardware ethernet 00:10:a4:e0:43:df;
>>>        uid 01:00:01:02:79:2d:87;
>>>}
>>>
>>>
>>>
>>>
>>>
>>>
>>>On Tue, 20 Aug 2002, Chuck Wiechman wrote:
>>>
>>>
>>>
>>>>That could be an issue, but in this case I was pulling the ethernet cable 
>>>>out trying to reproduce the issue. That is why the packet count was so 
>>>>low. 
>>>>
>>>>I will keep watching to see if it flapps, that might be the problem...
>>>>
>>>>Thanks.
>>>>
>>>>
>>>>
>>>>On Tue, 20 Aug 2002, John Hernandez wrote:
>>>>
>>>>
>>>>
>>>>>The packet counters seem suspiciously low for an interface that's been
>>>>>up for the last few hours.  Are you sure it's not flapping?
>>>>







More information about the LUG mailing list