[Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies
SourceForge.net
noreply at sourceforge.net
Sun May 20 23:53:10 CEST 2007
Bugs item #1090549, was opened at 2004-12-23 21:21
Message generated for change (Comment added) made by loic
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1090549&group_id=29880
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: CVS
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Laurentiu C. Badea (L.C.) (wotevah)
Assigned to: Ethan Galstad (egalstad)
Summary: check_dhcp ignores DHCP replies
Initial Comment:
check_dhcp ignores the DHCP replies apparently because
they are broadcast to 255.255.255.255.
<CLIENT>.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from <mac>, length: 548, flags: [Broadcast]
<SERVER>.bootps > 255.255.255.255.bootpc: BOOTP/DHCP,
Reply, length: 420, flags: [Broadcast] (0x8000)
I believe the problem may be that recvfrom is not
expecting a possible broadcast packet in response, so
it ignores it. Relevant part from strace below:
sendto(3, <packet>, 548, 0, {sa_family=AF_INET,
sin_port=htons(67),
sin_addr=inet_addr("255.255.255.255")}, 16) = 548
time([1103833074]) = 1103833074
time([1103833074]) = 1103833074
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3],
left {1, 999000})
recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274)
= -1 EINVAL (Invalid argument)
recvfrom(3, 0xfef67370, 548, 0, 0xfef67280, 0xfef67274)
= -1 EINVAL (Invalid argument)
Client is Fedora Core 2 with
nagios-plugins-1.3.1-10.1.fc2.dag.
Server is Red Hat 9 with dhcp-3.0pl1-23.
----------------------------------------------------------------------
Comment By: Loic Dachary (loic)
Date: 2007-05-20 23:53
Message:
Logged In: YES
user_id=1537
Originator: NO
I experienced the problem today. On debian etch. I'm running check_dhcp
and the dhcp server on the same interface. The dhcp server otherwise runs
fine.
strace /usr/lib/nagios/plugins/check_dhcp -s dhcp.dmz.tld -i eth2
...
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\26"..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=78500, ...}) = 0
mmap2(NULL, 81456, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7c17000
mmap2(0xb7c2a000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb7c2a000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7c16000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7c15000
mprotect(0xb7d57000, 20480, PROT_READ) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7c156c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
munmap(0xb7f04000, 8510) = 0
brk(0) = 0x804f000
brk(0x8070000) = 0x8070000
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE,
"eth2\0\0\0\0\0\0\0\0\0\0\0\0\17\0\0\0\4\0\0\0\5\0\0\0$"..., 32) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(68),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
ioctl(3, SIOCGIFHWADDR, {ifr_name="eth2", ifr_hwaddr=00:13:72:40:39:0a}) =
0
time(NULL) = 1179697853
sendto(3, "\1\1\6\0b\\:\347\377\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
548, 0, {sa_family=AF_INET, sin_port=htons(67),
sin_addr=inet_addr("255.255.255.255")}, 16) = 548
time([1179697853]) = 1179697853
time([1179697853]) = 1179697853
select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout)
time([1179697855]) = 1179697855
close(3) = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 11), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7f06000
write(1, "CRITICAL: No DHCPOFFERs were rec"..., 39CRITICAL: No DHCPOFFERs
were received.
) = 39
munmap(0xb7f06000, 4096) = 0
exit_group(2) = ?
Process 15586 detached
----------------------------------------------------------------------
Comment By: Matthias Eble (psychotrahe)
Date: 2007-05-20 16:35
Message:
Logged In: YES
user_id=1694341
Originator: NO
Hi all,
I'm setting this one back to Resolution: None, because reuben's problem is
reproducable using the cvs version for me.
First i didn't get dhcpd to send a reply at all. That was caused by
incorrect udp checksums which dhcpd didn't like. So I switched off checksum
offloading in the network driver and finally came into reuben's situation.
So I did some investigations and have following notes now:
- problem encounters if check_dhcp is run from the same system serving
dhcp
- the select times out according to strace
- offers are sent according to tcpdump/ethereal
- dhcpcd-test works flawlessly
- check_dhcp works on remote system
The fact that select times out makes me think that no data actually
arrives at the socket. If two servers are online, i get only the response
from the remote server.
One more thing I noticed is that dhcpcd-test sends discovers with source
ip 0.0.0.0 but the offers are sent to the offered destination ip. A dest-ip
the client doesn't even know - and cannot bind a socket on. I can't imagine
how this works at all.
Any hints?
Matthias
----------------------------------------------------------------------
Comment By: Reuben Farrelly (reuben)
Date: 2007-05-19 15:42
Message:
Logged In: YES
user_id=26209
Originator: NO
Yes seems that the issue still persists:
tornado libexec # ./check_dhcp -v -i vlan10 -s 192.168.10.12
Requested server address: 192.168.10.12
DHCP socket: 3
Hardware address: 001676ce4a2c
DHCPDISCOVER to 255.255.255.255 port 67
DHCPDISCOVER XID: 348330319 (0x14C3194F)
DHCDISCOVER ciaddr: 0.0.0.0
DHCDISCOVER yiaddr: 0.0.0.0
DHCDISCOVER siaddr: 0.0.0.0
DHCDISCOVER giaddr: 0.0.0.0
send_dhcp_packet result: 548
No (more) data received
Result=ERROR
Total responses seen on the wire: 0
Valid responses for this machine: 0
CRITICAL: No DHCPOFFERs were received.
tornado libexec #
Meanwhile, the server logged:
May 19 23:34:51 tornado dhcpd: DHCPDISCOVER from 00:16:76:ce:4a:2c via
vlan10
May 19 23:34:51 tornado dhcpd: DHCPOFFER on 192.168.10.24 to
00:16:76:ce:4a:2c via vlan10
Running just: ./check_dhcp results in a "CRITICAL: No DHCPOFFERs were
received" message.
I'm now running Gentoo not Fedora, but I gather that's probably not that
critical anyway. I have a second, FC6 system which I manage which exhibits
the same problem with this plugin (it doesn't use a vlan interface either,
it has only a single eth0 e100 NIC in it).
reuben
----------------------------------------------------------------------
Comment By: Matthias Eble (psychotrahe)
Date: 2007-05-18 13:14
Message:
Logged In: YES
user_id=1694341
Originator: NO
sent an email to reuben, to ask if the problem still persists
----------------------------------------------------------------------
Comment By: Reuben Farrelly (reuben)
Date: 2006-05-28 15:29
Message:
Logged In: YES
user_id=26209
In my case the problem seems to be caused by the plugin
being run on the *same system* as the DHCP server. I did
raise this earlier but I don't think it was investigated and
obviously not fixed.
Regardless, that is still the case and seems to be the cause
of the problem for me.
----------------------------------------------------------------------
Comment By: Reuben Farrelly (reuben)
Date: 2006-05-26 06:32
Message:
Logged In: YES
user_id=26209
Nope, still broken for me with current CVS. The DHCP server
offers the lease but it is not responded to..and the
check_dhcp test fails.
I'll do some more looking into this this weekend.
----------------------------------------------------------------------
Comment By: Ethan Galstad (egalstad)
Date: 2006-05-25 20:11
Message:
Logged In: YES
user_id=2225
Based on previous comments, it looks like this was already
fixed in CVS a while ago...
----------------------------------------------------------------------
Comment By: Ethan Galstad (egalstad)
Date: 2006-05-25 19:57
Message:
Logged In: YES
user_id=2225
Can the folks who were experiencing this problem please
check out the latest CVS version of check_dhcp? If I don't
hear any problem reports in the next few weeks, I'll be
closing this item. Thanks!
----------------------------------------------------------------------
Comment By: Laurentiu C. Badea (L.C.) (wotevah)
Date: 2005-02-08 09:33
Message:
Logged In: YES
user_id=724669
Right. I *should have* tried the CVS. I compiled it on my
dev box (FC3), copied it to my FC2 machine and it worked
fine there. So I suppose the bug isn't all that, now.
But that made me curious. I went and got each previous
revision of check_dhcp.c, recompiled and they all worked. So
I suspected a problem in Dag's rpm package.
I copied the "bad" binary to another FC2 machine and there
it works. The only difference is an SMP kernel where it
failed, and the UP kernel (same version) on the other. But
that's just useless trivia now I suppose since the version
compiled by hand works either way.
----------------------------------------------------------------------
Comment By: Stanley Hopcroft (stanleyhopcroft)
Date: 2005-02-08 00:17
Message:
Logged In: YES
user_id=395628
Dear Laurentiu,
I think you are correct there are _two_ problems.
I think that one has been dealt with (ie packet filtering
and or alias interface misbehaviour).
I agree with your analysis - why should recv() fail when
select says the read handle is ready for reading.
Are you familair with gdb ?
A gdb session with check_dhcp is the way to deal with this.
recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274)
socket, pointer to buffer, buffer len, flags,
pointer to from and pointer to from len.
I guess that 2 is MSG_PEEK (from the notes in the text). Is
2 the value of MSG_PEEK on your system.
Hey ! The plugin is 1.3. You must try the CVS.
Yours sincerely.
----------------------------------------------------------------------
Comment By: Laurentiu C. Badea (L.C.) (wotevah)
Date: 2005-02-07 19:45
Message:
Logged In: YES
user_id=724669
I have to apologize, I haven't been monitoring this report
(I was kind of hoping SF would send notification emails on
activity, but it didn't).
Anyway, I noticed a difference between my strace and the
others, that may be significant. Specifically, the select()
call returns with data on the socket in my version (but the
recvfrom still fails!), while it times out in the others. So
we may be dealing with two different problems here. Yes,
exactly what you wanted to hear, isn't it...
I'll try the CVS version later on tonight and let you know.
----------------------------------------------------------------------
Comment By: Reuben Farrelly (reuben)
Date: 2005-01-24 11:48
Message:
Logged In: YES
user_id=26209
Ok it's a flat topology:
* Single switch
* Single router, with 192.168.0.1 internally, 60.234.x.x
address externally doing NAT
* Single Linux server, 2.6.11-rc1-mm2 (at the moment), with
eth0 (192.168.0.3) eth0:0 (192.168.0.4) gre0 (172 address)
and a loopback. The machine has only one NIC. Clients are
also on the 192.168.0.0/24 network. Simple home network ;-)
dhcpd is not bound to any particular interface, but when I
shut down gre0 and eth0:0 and then restarted dhcpd to avoid
binding problems, same result when running check_dhcp :(
Jan 24 23:08:03 tornado dhcpd: Internet Systems Consortium
DHCP Server V3.0.2rc3
Jan 24 23:08:03 tornado dhcpd: Copyright 2004 Internet
Systems Consortium.
Jan 24 23:08:03 tornado dhcpd: All rights reserved.
Jan 24 23:08:03 tornado dhcpd: For info, please visit
http://www.isc.org/sw/dhcp/
Jan 24 23:08:03 tornado dhcpd: Internet Systems Consortium
DHCP Server V3.0.2rc3
Jan 24 23:08:03 tornado dhcpd: Copyright 2004 Internet
Systems Consortium.
Jan 24 23:08:03 tornado dhcpd: All rights reserved.
Jan 24 23:08:03 tornado dhcpd: For info, please visit
http://www.isc.org/sw/dhcp/
Jan 24 23:08:03 tornado dhcpd: Wrote 0 deleted host decls to
leases file.
Jan 24 23:08:03 tornado dhcpd: Wrote 0 new dynamic host
decls to leases file.
Jan 24 23:08:03 tornado dhcpd: Wrote 4 leases to leases file.
Jan 24 23:08:03 tornado dhcpd: Listening on
LPF/eth0/00:0d:61:5e:8b:b3/192.168.0.0/24
Jan 24 23:08:03 tornado dhcpd: Sending on
LPF/eth0/00:0d:61:5e:8b:b3/192.168.0.0/24
Jan 24 23:08:03 tornado dhcpd: Sending on
Socket/fallback/fallback-net
Jan 24 23:13:03 tornado dhcpd: DHCPDISCOVER from
00:0d:61:5e:8b:b3 via eth0
Jan 24 23:13:04 tornado dhcpd: DHCPOFFER on 192.168.0.11 to
00:0d:61:5e:8b:b3 via eth0
----------------------------------------------------------------------
Comment By: Stanley Hopcroft (stanleyhopcroft)
Date: 2005-01-24 11:31
Message:
Logged In: YES
user_id=395628
Thanks very much for your comment Reuben.
Please would you consider letting me know
1 whether eth0:0 is a 'virtual' interface ? Does the host
running check dhcp have two (2) NICs ?
2 try and sketch the topology for me
Is it
|
|--------- check_dhcp/dhcpd --------|
| etho eth1 |
| some other /x
|------------ router
192.168.0.0/24
?
Which interface is dhcpd bound to ?
You are welcome to write me direct (SHopcroft at
IPAustralia.Gov.AU) if that's more convenient.
Thank you.
----------------------------------------------------------------------
Comment By: Reuben Farrelly (reuben)
Date: 2005-01-24 11:09
Message:
Logged In: YES
user_id=26209
I've just down'ed eth0:0 and restarted dhcpd, still same
result....... :(
Router is connected to 192.168.0.0/24 and external
(routable) IP address only.
----------------------------------------------------------------------
Comment By: Stanley Hopcroft (stanleyhopcroft)
Date: 2005-01-24 11:04
Message:
Logged In: YES
user_id=395628
Firstly, a very heart felt thank you to
zytak and
reuben
for their willingness to test, listen to my silly remarks
and retest.
This release owes a lot to both gentlemen.
(your initiative also saved you hearing more silly remarks
such as did you regen configure ? ...)
All ones (ie 255.255.255.255) broadcasts has some 'minor
gotchas' that appear to be evident here.
(See Unix Network Programming vol 1 p 471-2)
I think what is happening is that
1 check_dhcp broadcasts are only being sent from the primary
(eth0) interface and are being transformed from 'all-ones'
to 'subnet-directed' broadcast (the broadcast ip address of
eth0).
2 your dhcp server is replying with a broadcast on _that_
prefix network which your secondary interface - check_dhcp -
is not connected to.
Presumably, your router is connected to both LANs and will
reply on _all_ interfaces - since some OS's replicate
broadcasts on _all_ their interfaces.
Thanks very much for your comments.
Will update the usage information ...
----------------------------------------------------------------------
Comment By: Reuben Farrelly (reuben)
Date: 2005-01-24 10:12
Message:
Logged In: YES
user_id=26209
Ok, some progress.
If I serve up DHCP from my cisco router with dhcpd off on my
server, check_dhcp works just fine:
[root at tornado ~]# /usr/lib/nagios/plugins/check_dhcp
DHCP ok: Received 1 DHCPOFFER(s), max lease time = 86400 sec.
If I then turn dhcp off on the router and re-enable dhcpd on
my server, it fails again. So it appears that running
check_dhcp from the same host as the dhcp server is a no-go,
at least in my case.........
----------------------------------------------------------------------
Comment By: Reuben Farrelly (reuben)
Date: 2005-01-24 10:02
Message:
Logged In: YES
user_id=26209
I still experience the problem even with my iptables rules off:
[root at tornado nagiosplug]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root at tornado nagiosplug]# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- network.reub.net/16 !network.reub.net/16
tcp dpt:http to:192.168.0.3:3128
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root at tornado nagiosplug]#
Other possible ideas:
* I have two IP addresses, a main and a secondary IP address
on eth0(:0)
* My server which does the monitoring also does DHCP
If I can come up with anything I'll post here.
----------------------------------------------------------------------
Comment By: Reuben Farrelly (reuben)
Date: 2005-01-24 09:59
Message:
Logged In: YES
user_id=26209
Firstly, can I confirm that sourceforge CVS has the most
current version? Latest CVS has: $Id: check_dhcp.c,v 1.6
2004/12/30 00:41:39 opensides Exp $
I don't think your latest changes have made it into the
publically visible repo :(
Here's an strace:
[root at tornado nagiosplug]# strace
/usr/lib/nagios/plugins/check_dhcp
execve("/usr/lib/nagios/plugins/check_dhcp",
["/usr/lib/nagios/plugins/check_dhcp"], [/* 22 vars */]) = 0
uname({sys="Linux", node="tornado", ...}) = 0
brk(0) = 0x804e000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such
file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=39607, ...}) = 0
old_mmap(NULL, 39607, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ff6000
close(3) = 0
open("/lib/libnsl.so.1", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320D\7"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=97608, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff5000
old_mmap(0x4b071000, 88064, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4b071000
old_mmap(0x4b083000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x4b083000
old_mmap(0x4b085000, 6144, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4b085000
close(3) = 0
open("/lib/libresolv.so.2", O_RDONLY) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\343"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=81252, ...}) = 0
old_mmap(0x4b02c000, 75944, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4b02c000
old_mmap(0x4b03b000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x4b03b000
old_mmap(0x4b03d000, 6312, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4b03d000
close(3) = 0
open("/lib/tls/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0
\277\353"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1521596, ...}) = 0
old_mmap(0x4aea7000, 1215644, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4aea7000
old_mmap(0x4afca000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x123000) = 0x4afca000
old_mmap(0x4afce000, 7324, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4afce000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff4000
mprotect(0x4afca000, 8192, PROT_READ) = 0
mprotect(0x4b03b000, 4096, PROT_READ) = 0
mprotect(0x4b083000, 4096, PROT_READ) = 0
mprotect(0x4aea3000, 4096, PROT_READ) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ff46c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7ff6000, 39607) = 0
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=39591472, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7df4000
mmap2(NULL, 204800, PROT_READ, MAP_PRIVATE, 3, 0x1029) =
0xb7dc2000
brk(0) = 0x804e000
brk(0x806f000) = 0x806f000
mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x1072) =
0xb7dc1000
close(3) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE,
"eth0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\264\356\377\277\370"...,
32) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(68),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
ioctl(3, SIOCGIFHWADDR, 0xbfffedd0) = 0
time(NULL) = 1106556165
sendto(3,
"\1\1\6\0\34|\211\212\377\0\200\0\0\0\0\0\0\0\0\0\0\0\0"...,
548, 0, {sa_family=AF_INET, sin_port=htons(67),
sin_addr=inet_addr("255.255.255.255")}, 16) = 548
time([1106556165]) = 1106556165
time([1106556165]) = 1106556165
select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout)
time([1106556167]) = 1106556167
close(3) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2),
...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dc0000
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0
mmap2(NULL, 131072, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7da0000
read(3, "# Locale name alias data base.\n#"..., 131072) = 2528
read(3, "", 131072) = 0
close(3) = 0
munmap(0xb7da0000, 131072) = 0
open("/usr/share/nagios/locale/en_US/LC_MESSAGES/nagios-plugins.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/nagios/locale/en/LC_MESSAGES/nagios-plugins.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
write(1, "DHCP problem: No DHCPOFFERs were"..., 43DHCP
problem: No DHCPOFFERs were received.
) = 43
munmap(0xb7dc0000, 4096) = 0
exit_group(2) = ?
[root at tornado nagiosplug]#
Also:
[root at tornado nagiosplug]# /usr/lib/nagios/plugins/check_dhcp -v
DHCP socket: 3
Hardware address: 000d615e8bb3
DHCPDISCOVER to 255.255.255.255 port 67
DHCPDISCOVER XID: 842612958 (0x323940DE)
DHCDISCOVER ciaddr: 0.0.0.0
DHCDISCOVER yiaddr: 0.0.0.0
DHCDISCOVER siaddr: 0.0.0.0
DHCDISCOVER giaddr: 0.0.0.0
send_dhcp_packet result: 548
No (more) data received
Result=ERROR
Total responses seen on the wire: 0
Valid responses for this machine: 0
DHCP problem: No DHCPOFFERs were received.
[root at tornado nagiosplug]#
----------------------------------------------------------------------
Comment By: zyta2k (zyta2k)
Date: 2005-01-24 09:48
Message:
Logged In: YES
user_id=544197
Wooooops :/
Shame on me =)
flushed all iptables rules and now it works...
The "strange thing" is:
dhcp is fully functional if I use the same rulebase !!
Here are the rules
---- schnippi ----
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere
icmp any
ACCEPT ipv6-crypt-- anywhere anywhere
ACCEPT ipv6-auth-- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251
udp dpt:5353
ACCEPT udp -- anywhere anywhere
udp dpt:ipp
ACCEPT all -- anywhere anywhere
state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere
state NEW tcp dpt:ftp
ACCEPT tcp -- anywhere anywhere
state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere
reject-with icmp-host-prohibited
---- schnappi ----
öm... no idea which rule stops the check_dhcp plug... :/
----------------------------------------------------------------------
Comment By: Stanley Hopcroft (stanleyhopcroft)
Date: 2005-01-24 03:57
Message:
Logged In: YES
user_id=395628
Dear Folks,
I am perplexed about this problem.
1 the open socket won't ignore a broadcast reply with the
dhcp client port unless the reply is filtered by some kernel
packet filter (iptable on Linux ?), or there is a firewall
or router between the client and server. Given the PRs this
doesn't seem likely.
2 the failure is however consistent with L.C's (Laurentiu C.
Badea) PR showing EINVAL from the recvfrom call.
Please would either L.C., Rueben Farrelly or zyta2k do an
strace or equivalent (truss/ktrace ?) to show if recvfrom is
still returning -1/EINVAL from a CVS copy (not many changes
from L.C's report of the prob with the 1.3 plugins but its
nice to be sure)
EINVAL seems to suggest an argument problem but I can't
imagine what this may be - the parms seem fine.
Thank you.
----------------------------------------------------------------------
Comment By: Stanley Hopcroft (stanleyhopcroft)
Date: 2005-01-21 10:35
Message:
Logged In: YES
user_id=395628
Thank you for a superb PR.
Unfortunately, this is unlikely to help you much but would
you please try the latest CVS (not tar ball) and post your
command invocation (changes have been made to get it to
build properly on Linux and FreeBSD - you seem to have done
this yourself).
On FreeBSD 4.10 and ISC dhcpd (V3.0.1rc14), it works Ok.
The reply to the discover should be a broadcast (methinks)
since the client has no ip.
Thanks for your help.
----------------------------------------------------------------------
Comment By: zyta2k (zyta2k)
Date: 2005-01-04 11:41
Message:
Logged In: YES
user_id=544197
I can confirm the problem...
=== Verbose Output From Plugin ===
DHCP socket: 3
Hardware address: 00110a32c75e
DHCPDISCOVER to 255.255.255.255 port 67
DHCPDISCOVER XID: 1269450911 (0x4BAA489F)
DHCDISCOVER ciaddr: 0.0.0.0
DHCDISCOVER yiaddr: 0.0.0.0
DHCDISCOVER siaddr: 0.0.0.0
DHCDISCOVER giaddr: 0.0.0.0
send_dhcp_packet result: 548
No (more) data received
Result=ERROR
Total responses seen on the wire: 0
Valid responses for this machine: 0
DHCP problem: No DHCPOFFERs were received.
============= TCPDUMP ============
# tcpdump -vv dst port 68
tcpdump: listening on eth0, link-type EN10MB (Ethernet),
capture size 96 bytes
11:25:54.418410 IP (tos 0x0, ttl 63, id 0, offset 0, flags
[DF], proto 17, length: 341) dhcp01.foobar.com >
255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313,
xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000)
Your IP: 10.29.20.121
Server IP: dhcp01.foobar.com
Gateway IP: 10.29.20.2
Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp]
11:25:54.418675 IP (tos 0x0, ttl 62, id 0, offset 0, flags
[DF], proto 17, length: 341) dhcp01.foobar.com.bootps >
255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313,
xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000)
Your IP: 10.29.20.121
Server IP: dhcp01.foobar.com
Gateway IP: 10.29.20.3
Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp]
11:25:54.418975 IP (tos 0x0, ttl 63, id 0, offset 0, flags
[DF], proto 17, length: 341) dhcp02.foobar.com.bootps >
255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313,
xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000)
Your IP: 10.29.20.143
Server IP: dhcp02.foobar.com
Gateway IP: 10.29.20.2
Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp]
11:25:54.421156 IP (tos 0x0, ttl 62, id 0, offset 0, flags
[DF], proto 17, length: 341) dhcp02.foobar.com.bootps >
255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313,
xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000)
Your IP: 10.29.20.143
Server IP: dhcp02.foobar.com
Gateway IP: 10.29.20.3
Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp]
4 packets captured
4 packets received by filter
0 packets dropped by kernel
========== MY SYSTEM =============
Distribution: Fedora Core 3
Kernel: 2.6.9
Glibc: 2.3.4
Plugin Version: CVS v 1.6 2004/12/30 00:41:39
hth
zyta2k
----------------------------------------------------------------------
Comment By: Reuben Farrelly (reuben)
Date: 2005-01-02 21:48
Message:
Logged In: YES
user_id=26209
Still no go here either using bleeding edge CVS (on FC3):
sendto(3,
"\1\1\6\0\6\372\275\241\377\0\200\0\0\0\0\0\0\0\0\0\0\0"...,
548, 0, {sa_family=AF_INET, sin_port=htons(67),
sin_addr=inet_addr("255.255.255.255")}, 16) = 548
time([1104698558]) = 1104698558
time([1104698558]) = 1104698558
select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout)
time([1104698560]) = 1104698560
close(3) = 0
Returns with "DHCP problem: No DHCPOFFERs were received."
Meanwhile the DHCP server has seen the DHCPDISCOVER come in
and DHCPOFFER'ed an address to 255.255.255.255.bootpc
----------------------------------------------------------------------
Comment By: Benoit Mortier (opensides)
Date: 2005-01-02 19:42
Message:
Logged In: YES
user_id=388184
Hi,
could you test with the lastest cvs, and report your findings
Thanks
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1090549&group_id=29880
More information about the Devel
mailing list