[lug] dhcpcd lease issue
Chuck Wiechman
wiechdoctor at earthlink.net
Wed Aug 21 12:30:07 MDT 2002
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?
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
>
> 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
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
/sbin/fuser -v -u -n tcp "68" -n udp "68"
USER PID ACCESS COMMAND
68/udp root 3356 f.... dhcpcd
ps -ef | grep dhcp
root 3356 1 0 12:17 ? 00:00:00 /sbin/dhcpcd -n eth0
>
> 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?
>
> _______________________________________________
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
>
More information about the LUG
mailing list