[lug] dhcpcd lease issue
D. Stimits
stimits at attbi.com
Wed Aug 21 12:07:38 MDT 2002
Chuck Wiechman wrote:
> My laptop just puked again. Here is the output from the laptop. I booted
> the laptop about 8am, and it obtained IP address 10.1.1.53 (the same IP
> that it had yesterday). Than at 10am it did the following. What is the
> ioctl error mean?
>
>
> Aug 21 10:00:56 merlin dhcpcd[950]: sendto: Socket operation on non-socket
> Aug 21 10:00:56 merlin dhcpcd[950]: sendto: Socket operation on non-socket
> Aug 21 10:00:56 merlin dhcpcd[950]: dhcpStop: ioctl SIOCSIFADDR:
> Inappropriate ioctl for device
This one is rather strange, it looks like an outright bug or perhaps
someone did something (not necessarily intentional) that confused it.
However, when the fuser command showed nothing was listening on port 68,
the above message seems to jive with that. If your dhcp client lost its
socket for any reason, and the client then tried to run a socket ioctl
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?
What is the output in /var/log/messages after running
"/etc/rc.d/init.d/network restart"?
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