From ton.voon at altinity.com Tue Jul 8 12:13:51 2008 From: ton.voon at altinity.com (Ton Voon) Date: Tue, 8 Jul 2008 11:13:51 +0100 Subject: [Nagiosplug-devel] Libtap included in distribution In-Reply-To: <48681282.6080001@aei.ca> References: <9506EB0F-1ACA-4882-A5FE-F04BA10801F1@altinity.com> <48681282.6080001@aei.ca> Message-ID: <4B6B44AF-F83D-487B-A26D-89CB98991D58@altinity.com> On 29 Jun 2008, at 23:53, Thomas Guyot-Sionnest wrote: >> Based on a comment made by Thomas, I've added the libtap distribution >> into the nagios plugins project. This enables us to run C tests >> without a dependency on external code. >> >> It includes two changes to the libtap project from http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap >> including disabling LIBPTHREAD and asprintf from gnulib (http://jc.ngo.org.uk/trac-bin/trac.cgi/ticket/32 >> ). >> >> libtap will only get included if ./configure --enable-libtap is set. >> However, compiling will only take effect if a "make test" is run. >> >> I'll see how the tinderbox builds cope tomorrow, but if all goes >> well, >> I'll make this version of libtap available on our site. > > Cool, Ton! > > If I can find some free time I'll test it on my tinderbox and > workstation. > > We should also encourage tinderbox owners without libtap to use this > config option. I had set this as an included option for tinderbox builds (tools/ tinderbox_builds), but it caused breakages at the make stage. Partly due to not linking libraries correctly, but HP/UX was complaining about the libtap code. So I've removed the --enable-libtap from tinderbox build. Unfortunately, I haven't had time to get the old behaviour restored, so now no libtap testing is run. Want to see if this stabilises the builds first. Sigh. Ton From noreply at sourceforge.net Wed Jul 9 23:55:22 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2008 21:55:22 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1867716 ] check_snmp invalid performance data Message-ID: Bugs item #1867716, was opened at 2008-01-09 15:46 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&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: General plugin execution Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Joerg Linge (pitchfork) >Assigned to: Matthias Eble (psychotrahe) Summary: check_snmp invalid performance data Initial Comment: check_snmp produces invalid performance data. Version: check_snmp v1859 (nagios-plugins 1.4.11) Call: check_snmp -H localhost -C public -o sysUpTime.0 Output: SNMP OK - Timeticks: (49845368) 5 d | SNMPv2-MIB::sysUpTime.0=Timeticks: (49845368) 5 d OS: Linux SuSE 2.6.11.4-21.17-bigsmp Compiler: gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) Kind regards Jrg ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2008-07-09 23:55 Message: Logged In: YES user_id=1694341 Originator: NO this problem is now fixed in svn. thank you for your report. ---------------------------------------------------------------------- Comment By: Joerg Linge (pitchfork) Date: 2008-01-12 12:07 Message: Logged In: YES user_id=1353850 Originator: YES sysUpTime.0 was just an example! I think check_snmp should only provide performance data on interger values. Just to be sure the performance data ist valid. Jrg ---------------------------------------------------------------------- Comment By: Thomas Guyot (dermoth) Date: 2008-01-11 22:55 Message: Logged In: YES user_id=375623 Originator: NO This is the expected behavior; chhek_snmp doesn't know anything about TimeTicks Perhaps passing -Ot would help, but it would require different parsing and I don't know how it would affect any the the many special data formats in SNMP. This would be better suited as a feature request. However it would be much easier to just write a local check (run trough nrpe or check_by_ssh) that parse uptime. Also you should keep in mind that the SNMP uptime is the SNMP daemon uptime, not the server uptime (in other words you're ok as long as you don't restart the daemon). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1867716&group_id=29880 From noreply at sourceforge.net Thu Jul 10 09:02:31 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2008 07:02:31 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1986260 ] check_disk_smb and no-user or no-passwd or share with spaces Message-ID: Bugs item #1986260, was opened at 2008-06-06 12:39 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1986260&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk_smb and no-user or no-passwd or share with spaces Initial Comment: The following Bugreport we got against our debian package: [...] What that means is that if any of the ARGS contain any character special to the shell (space, tab, nl, "$^&*()[;'#~<>?...) or if they are empty, that will break. [...] Next, the check_disk_smb perl script itself has a similar problem when running the smbclient command. It runs: $res = qx/$smbclient "\/\/$host\/$share" $pass -W $workgroup -U $user $smbclientoptions -I $address -c ls/; qx/.../ (same as `...`) runs a shell in a same way. The documentation says that if the password is not passed, it defaults to "". That is not true above, as $pass expands to nothing which leaves no argument at all (instead of an empty argument) so is different from providing with an empty password or with the -N option. Also, if the password starts with "-", you're in trouble, that's why -U $user%$pass may be prefered. Also, the doc says that if $user is not provided, then it defaults to "guest" but the problem is that if it is provided but empty, it is changed to "guest" as well, which prevents us from querying hosts that don't do user authentication. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478942 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Jan Wagner (cyco_dd) Date: 2008-07-10 09:02 Message: Logged In: YES user_id=1345239 Originator: YES File Added: 34_fix_smbclient_check_disk_smb.dpatch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1986260&group_id=29880 From noreply at sourceforge.net Fri Jul 11 11:10:54 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2008 09:10:54 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2015822 ] check_dns should use c library functions, not nslookup binar Message-ID: Bugs item #2015822, was opened at 2008-07-11 09:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2015822&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns should use c library functions, not nslookup binar Initial Comment: check_dns uses nslookup binary to perform its checks rather than using C library functions. This means an unnecessary reliance on extra binaries being installed. This is in version 1.4.12 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2015822&group_id=29880 From noreply at sourceforge.net Fri Jul 11 12:55:51 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2008 10:55:51 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-2015822 ] check_dns should use c library functions, not nslookup binar Message-ID: Feature Requests item #2015822, was opened at 2008-07-11 11:10 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=2015822&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: None Status: Open >Priority: 2 Private: No Submitted By: Duncan Ferguson (duncan_ferguson) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns should use c library functions, not nslookup binar Initial Comment: check_dns uses nslookup binary to perform its checks rather than using C library functions. This means an unnecessary reliance on extra binaries being installed. This is in version 1.4.12 ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2008-07-11 12:55 Message: Logged In: YES user_id=759506 Originator: NO Yes, it would be nice if check_dns wouldn't rely on external binaries. However, there are no C library functions which provide the required functionality, we'd have to implement that ourselves. Patches welcome! :-) I wouldn't classify this as a bug, but rather as a (low priority, compared to other tasks on our TODO list) wish list item, so I'll move it over to the "Feature Requests" tracker. Thanks, Holger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=2015822&group_id=29880 From noreply at sourceforge.net Wed Jul 16 20:45:22 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2008 18:45:22 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2003302 ] check_disk doesn't handle large zfs filesystems Message-ID: Bugs item #2003302, was opened at 2008-06-26 13:28 Message generated for change (Comment added) made by maemigh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2003302&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: General plugin execution Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: maemigh (maemigh) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk doesn't handle large zfs filesystems Initial Comment: Check disk seems to work fine for zfs for up to at least 560G filesystems, but doesn't work when tested on 1.3TB filesystems: check_disk -w 5% -c 2% -p /zbackups DISK CRITICAL - free space: /zbackups 0 MB (0% inode=99%);| /zbackups=0MB;1252397;1291946;0;1318313 df -h /zbackups Filesystem size used avail capacity Mounted on zbackups 1.3T 49K 1.3T 1% /zbackups check_disk --version check_disk v1848 (nagios-plugins 1.4.11) This test was performed on Solaris 5.10 Generic_127128-11 i86pc i386 i86pc ---------------------------------------------------------------------- >Comment By: maemigh (maemigh) Date: 2008-07-16 14:45 Message: Logged In: YES user_id=1520524 Originator: YES Appears to be working fine in the latest trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2003302&group_id=29880 From PsychoTrahe at gmx.de Thu Jul 17 09:25:09 2008 From: PsychoTrahe at gmx.de (Matthias Eble) Date: Thu, 17 Jul 2008 09:25:09 +0200 Subject: [Nagiosplug-devel] Feature request: extend check_ping to specify source address In-Reply-To: <20080717094404.H61740@mippet.ci.com.au> References: <20080717094404.H61740@mippet.ci.com.au> Message-ID: <1216279509.6415.12.camel@pc.site> On Thu, 2008-07-17 at 09:48 +1000, Dave Horsfall wrote: > to specify the source address on the executed "ping" > command (*BSD: -S, Linux: -I) to be able to monitor a host on the > other > end of a VPN. I sent the outline of a patch to the FreeBSD ports > people, > and they referred me here instead (whilst commenting it was a good > idea). > > Is this planned to be introduced at all? Hi Dave, this feature is already provided by check_icmp. The only drawback of check_icmp is that it needs super user privileges (set uid root or sudo). As you already mentioned, there are differences between the ping syntaxes that need to be discovered (rather assumed). I'd thus suggest not to add more ping_command detection steps to configure.in since we already have many of them. Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cschneemann at suse.de Thu Jul 17 10:09:06 2008 From: cschneemann at suse.de (Christian Schneemann) Date: Thu, 17 Jul 2008 10:09:06 +0200 Subject: [Nagiosplug-devel] =?iso-8859-15?q?Feature_request=3A_extend_chec?= =?iso-8859-15?q?k=5Fping_to=09specify_source_address?= In-Reply-To: <1216279509.6415.12.camel@pc.site> References: <20080717094404.H61740@mippet.ci.com.au> <1216279509.6415.12.camel@pc.site> Message-ID: <200807171009.06552.cschneemann@suse.de> On Thursday July 17 2008 09:25:09 am Matthias Eble wrote: > On Thu, 2008-07-17 at 09:48 +1000, Dave Horsfall wrote: > > to specify the source address on the executed "ping" > > command (*BSD: -S, Linux: -I) to be able to monitor a host on the > > other > > end of a VPN. I sent the outline of a patch to the FreeBSD ports > > people, > > and they referred me here instead (whilst commenting it was a good > > idea). > > > > Is this planned to be introduced at all? > > Hi Dave, > this feature is already provided by check_icmp. > The only drawback of check_icmp is that it needs super user privileges > (set uid root or sudo). But why not enhancing the check_ping with this option? In my opinion it is a better way than giving some binaries a suid bit. > > As you already mentioned, there are differences between the ping > syntaxes that need to be discovered (rather assumed). I'd thus suggest > not to add more ping_command detection steps to configure.in since we > already have many of them. > > Matthias -- Christian Schneemann ------------------------------------- SUSE LINUX Products GmbH, Maxfeldstr. 5, D - 90409 N?rnberg Phone:??+49 (0)911 - 740 53 0 e-mail:?cschneemann at suse.de ------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex HRB 16746 (AG N?rnberg) From matthias.eble at mailing.kaufland-informationssysteme.com Thu Jul 17 10:27:48 2008 From: matthias.eble at mailing.kaufland-informationssysteme.com (matthias eble) Date: Thu, 17 Jul 2008 10:27:48 +0200 Subject: [Nagiosplug-devel] Feature request: extend check_ping to specify source address In-Reply-To: <200807171009.06552.cschneemann@suse.de> References: <20080717094404.H61740@mippet.ci.com.au> <1216279509.6415.12.camel@pc.site> <200807171009.06552.cschneemann@suse.de> Message-ID: <1216283268.15855.67.camel@de101315> > But why not enhancing the check_ping with this option? > In my opinion it is a better way than giving some binaries a suid bit. Read below. > > As you already mentioned, there are differences between the ping > > syntaxes that need to be discovered (rather assumed). I'd thus suggest > > not to add more ping_command detection steps to configure.in since we > > already have many of them. This is my personal opinion. I simply dislike the ping discovery logic because it relies on try'n'error. If some dev is keen enough to tweak it according to the request, even if this functionality is already provided by check_icmp, I'm fine with that. Matthias From ae at op5.se Thu Jul 17 15:03:38 2008 From: ae at op5.se (Andreas Ericsson) Date: Thu, 17 Jul 2008 15:03:38 +0200 Subject: [Nagiosplug-devel] Feature request: extend check_ping to specify source address In-Reply-To: <200807171009.06552.cschneemann@suse.de> References: <20080717094404.H61740@mippet.ci.com.au> <1216279509.6415.12.camel@pc.site> <200807171009.06552.cschneemann@suse.de> Message-ID: <487F432A.9060803@op5.se> Christian Schneemann wrote: > On Thursday July 17 2008 09:25:09 am Matthias Eble wrote: >> On Thu, 2008-07-17 at 09:48 +1000, Dave Horsfall wrote: >>> to specify the source address on the executed "ping" >>> command (*BSD: -S, Linux: -I) to be able to monitor a host on the >>> other >>> end of a VPN. I sent the outline of a patch to the FreeBSD ports >>> people, >>> and they referred me here instead (whilst commenting it was a good >>> idea). >>> >>> Is this planned to be introduced at all? >> Hi Dave, >> this feature is already provided by check_icmp. >> The only drawback of check_icmp is that it needs super user privileges >> (set uid root or sudo). > But why not enhancing the check_ping with this option? > In my opinion it is a better way than giving some binaries a suid bit. > /bin/ping already requires that suid bit, so it's not as if he'd have to give it to one more program. Instead, he could remove it (or tighten it) on /bin/ping and let check_icmp be mode 4710, with root:nagios ownership. Besides, check_icmp maintains its root privileges for all of 15 lines of code, handling 0 bits of userspace data before dropping it. The whole auto-discovery dance in ./configure for check_ping just makes it totally appalling and not very trustworthy, imo. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Fri Jul 18 09:23:03 2008 From: ae at op5.se (Andreas Ericsson) Date: Fri, 18 Jul 2008 09:23:03 +0200 Subject: [Nagiosplug-devel] Feature request: extend check_ping to specify source address In-Reply-To: <20080718092808.Y42904@mippet.ci.com.au> References: <20080717094404.H61740@mippet.ci.com.au> <1216279509.6415.12.camel@pc.site> <20080718092808.Y42904@mippet.ci.com.au> Message-ID: <488044D7.1070001@op5.se> Dave Horsfall wrote: > On Thu, 17 Jul 2008, Matthias Eble wrote: > >> this feature is already provided by check_icmp. > > Err, how? It isn't, and I fail to see how that could work at all. check_icmp and ping alike mark their packets with pid, sequence-number, host-id (decided internally) etc, etc. Modifying the ip->src_addr field would cause the targeted host to send its ICMP_ECHO_REPLY packets to a different host, so check_icmp (or ping) wouldn't be able to pick them up at a later time. Otoh, it's not hard to implement, so convince me it's needed and I'll add it :-) > I've got nagios-plugins-1.4.11: That's rather ancient, I think, although I don't exactly follow the nagiosplug upstream development that closely anymore. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From matthias.eble at mailing.kaufland-informationssysteme.com Fri Jul 18 09:47:52 2008 From: matthias.eble at mailing.kaufland-informationssysteme.com (matthias eble) Date: Fri, 18 Jul 2008 09:47:52 +0200 Subject: [Nagiosplug-devel] Feature request: extend check_ping to specify source address In-Reply-To: <488044D7.1070001@op5.se> References: <20080717094404.H61740@mippet.ci.com.au> <1216279509.6415.12.camel@pc.site> <20080718092808.Y42904@mippet.ci.com.au> <488044D7.1070001@op5.se> Message-ID: <1216367272.15855.74.camel@de101315> On Fri, 2008-07-18 at 09:23 +0200, Andreas Ericsson wrote: > Dave Horsfall wrote: > > On Thu, 17 Jul 2008, Matthias Eble wrote: > > > >> this feature is already provided by check_icmp. > > > > Err, how? > > It isn't, and I fail to see how that could work at all. ------------------------------------------------------------------------ r1882 | hweiss | 2007-12-21 14:25:28 +0100 (Fri, 21 Dec 2007) | 3 lines New "-s" option to specify the source IP address (thanks to Harald Jenny for providing the patch and to Patrick Cervicek for looking into it!) > check_icmp and ping alike mark their packets with pid, sequence-number, > host-id (decided internally) etc, etc. Modifying the ip->src_addr field > would cause the targeted host to send its ICMP_ECHO_REPLY packets to a > different host, so check_icmp (or ping) wouldn't be able to pick them > up at a later time. Don't know if this is handled properly in the applied patch.. Matthias From matthias.eble at mailing.kaufland-informationssysteme.com Fri Jul 18 09:49:39 2008 From: matthias.eble at mailing.kaufland-informationssysteme.com (matthias eble) Date: Fri, 18 Jul 2008 09:49:39 +0200 Subject: [Nagiosplug-devel] Feature request: extend check_ping to specify source address In-Reply-To: <20080718092808.Y42904@mippet.ci.com.au> References: <20080717094404.H61740@mippet.ci.com.au> <1216279509.6415.12.camel@pc.site> <20080718092808.Y42904@mippet.ci.com.au> Message-ID: <1216367379.15855.77.camel@de101315> On Fri, 2008-07-18 at 09:35 +1000, Dave Horsfall wrote: > On Thu, 17 Jul 2008, Matthias Eble wrote: > > > this feature is already provided by check_icmp. > > Err, how? I've got nagios-plugins-1.4.11: It came with 1.4.12. > With "-V" I get nothing, and "--version" is not recognised. right, this is currently ignored. Will fix it, if no one will be faster. Matthias From Sascha.Runschke at gfkl.com Fri Jul 18 12:24:17 2008 From: Sascha.Runschke at gfkl.com (Sascha.Runschke at gfkl.com) Date: Fri, 18 Jul 2008 12:24:17 +0200 Subject: [Nagiosplug-devel] Antwort: Re: Feature request: extend check_ping to specify source address In-Reply-To: <488044D7.1070001@op5.se> Message-ID: nagiosplug-devel-bounces at lists.sourceforge.net schrieb am 18.07.2008 09:23:03: > It isn't, and I fail to see how that could work at all. > > check_icmp and ping alike mark their packets with pid, sequence-number, > host-id (decided internally) etc, etc. Modifying the ip->src_addr field > would cause the targeted host to send its ICMP_ECHO_REPLY packets to a > different host, so check_icmp (or ping) wouldn't be able to pick them > up at a later time. It will work, if the local machine has 2 IP adresses and advanced source policy routing is active on the gateway (or the local machine already). The use of course is fairly small, since such setups are very rarely seen, but obviously we found someone who does it that way ;) S -- Sascha Runschke Netzwerk- und Systemmanagement Telefon : +49 (201) 102-1879 Mobil : +49 (173) 5419665 Fax : +49 (201) 102-1102105 GFKL Financial Services AG Vorstand: Dr. Peter J?nsch (Vors.), J?rgen Baltes, Dr. Till Ergenzinger, Dr. Tom Haverkamp Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ae at op5.se Fri Jul 18 13:58:00 2008 From: ae at op5.se (Andreas Ericsson) Date: Fri, 18 Jul 2008 13:58:00 +0200 Subject: [Nagiosplug-devel] Antwort: Re: Feature request: extend check_ping to specify source address In-Reply-To: References: Message-ID: <48808548.9050502@op5.se> Sascha.Runschke at gfkl.com wrote: > nagiosplug-devel-bounces at lists.sourceforge.net schrieb am 18.07.2008 > 09:23:03: > >> It isn't, and I fail to see how that could work at all. >> >> check_icmp and ping alike mark their packets with pid, sequence-number, >> host-id (decided internally) etc, etc. Modifying the ip->src_addr field >> would cause the targeted host to send its ICMP_ECHO_REPLY packets to a >> different host, so check_icmp (or ping) wouldn't be able to pick them >> up at a later time. > > It will work, if the local machine has 2 IP adresses and advanced source > policy routing is active on the gateway (or the local machine already). > The use of course is fairly small, since such setups are very rarely seen, > but obviously we found someone who does it that way ;) > Ah, ofcourse. I'm guessing the easy way is to simply bind(2) the socket to the address specified by -s and then send the packet in the normal fashion. As an added bonus, that would also provide typo-checking in the argument parsing, since it would then be impossible to specify a source-address that the local machine knows nothing about. In a handy way, this would also prevent script-kiddies from launching dos attacks using check_icmp (without modifying the source, ofcourse). I shall have to sync with upstream and see how it was done. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From holger at CIS.FU-Berlin.DE Fri Jul 18 15:21:24 2008 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Fri, 18 Jul 2008 15:21:24 +0200 Subject: [Nagiosplug-devel] Antwort: Re: Feature request: extend check_ping to specify source address In-Reply-To: <48808548.9050502@op5.se> References: <48808548.9050502@op5.se> Message-ID: <20080718132124.GG83719552@CIS.FU-Berlin.DE> * Andreas Ericsson [2008-07-18 13:58]: > Sascha.Runschke at gfkl.com wrote: > > nagiosplug-devel-bounces at lists.sourceforge.net schrieb am 18.07.2008 > > 09:23:03: > >> check_icmp and ping alike mark their packets with pid, sequence-number, > >> host-id (decided internally) etc, etc. Modifying the ip->src_addr field > >> would cause the targeted host to send its ICMP_ECHO_REPLY packets to a > >> different host, so check_icmp (or ping) wouldn't be able to pick them > >> up at a later time. > > > > It will work, if the local machine has 2 IP adresses and advanced source > > policy routing is active on the gateway (or the local machine already). > > The use of course is fairly small, since such setups are very rarely seen, > > but obviously we found someone who does it that way ;) > > Ah, ofcourse. I'm guessing the easy way is to simply bind(2) the socket > to the address specified by -s and then send the packet in the normal > fashion. That's how we implemented it (plus you can specify the interface instead of the IP address via "-s", and IMO we should also allow host names). > As an added bonus, that would also provide typo-checking in the > argument parsing, since it would then be impossible to specify a > source-address that the local machine knows nothing about. Indeed. Holger From rouilj at cs.umb.edu Fri Jul 18 15:34:57 2008 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Fri, 18 Jul 2008 09:34:57 -0400 Subject: [Nagiosplug-devel] Feature request: extend check_ping to specify source address In-Reply-To: Your message of "Fri, 18 Jul 2008 09:23:03 +0200." <488044D7.1070001@op5.se> Message-ID: <200807181334.m6IDYvdW000247@mx1.cs.umb.edu> In message <488044D7.1070001 at op5.se>, Andreas Ericsson writes: >Dave Horsfall wrote: >> On Thu, 17 Jul 2008, Matthias Eble wrote: >>> this feature is already provided by check_icmp. >> Err, how? >It isn't, and I fail to see how that could work at all. > >check_icmp and ping alike mark their packets with pid, sequence-number, >host-id (decided internally) etc, etc. Modifying the ip->src_addr field >would cause the targeted host to send its ICMP_ECHO_REPLY packets to a >different host, so check_icmp (or ping) wouldn't be able to pick them >up at a later time. Well you set the source address to one of the ip addresses on the box. >Otoh, it's not hard to implement, so convince me it's needed and I'll >add it :-) I don't have any systems like this now, but imagine a multihomed host on a routed network. One interface at ip 1.1.1.2 allows direct access to the host 1.1.1.4, while interface B on 2.2.2.2 allows access to 1.1.1.4 via some set of routers starting with 2.2.2.1. Unless you can set the source address, (which I assume also selects the network interface the ping goes out), you have no way to test the connectivity to the 1.1.1.1 network from the 2.2.2.2 box via the routers starting at 2.2.2.1. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From andurin at process-zero.de Fri Jul 18 20:46:27 2008 From: andurin at process-zero.de (=?ISO-8859-15?Q?Hendrik_B=E4cker?=) Date: Fri, 18 Jul 2008 20:46:27 +0200 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins Message-ID: <4880E503.3000703@process-zero.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi List, just a few moments ago I've read a question by a user if it would be a problem to run the nagios plugins with root right via check_by_ssh. Yes - I laughed too as I read that. But in the following discussion it clears up - they already have a spreaded root ssh key on most of their systems and are to lazy to establish an unprivileged 'nagios' user on their systems - so they would run them as root. I know, security awareness should be part of the persons who are using the tools, scripts and programs - but 80% of security holes came from people who didn't know what they are doing. Without starting a flame on this topic I would like to ask what do you think of some security benefits like: * don't run the code if UID is 0: Hard but effective - check uid and abort with a warning. * try to drop the privileges to the givven user by the configure run as a hard coded option I am not stupid enough to run my plugins with root privileges - but there are thousand of users out their who won't know what they're doing. Regards, Hendrik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFIgOUDlI0PwfxLQjkRAse1AJ9BXDL40w3UgztEgOjBGWkkiC2DowCfYdlZ /ycNK7edoC7q1ehWNo//LvM= =dBD2 -----END PGP SIGNATURE----- From rouilj at cs.umb.edu Fri Jul 18 21:12:55 2008 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Fri, 18 Jul 2008 15:12:55 -0400 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: Your message of "Fri, 18 Jul 2008 20:46:27 +0200." <4880E503.3000703@process-zero.de> Message-ID: <200807181913.m6IJDGKl016252@mx1.cs.umb.edu> Hendrik said: >just a few moments ago I've read a question by a user if it would be a >problem to run the nagios plugins with root right via check_by_ssh. > >Yes - I laughed too as I read that. But in the following discussion it >clears up - they already have a spreaded root ssh key on most of their >systems and are to lazy There are a number of reasons to want to do this. It's too complicated by policy. I know a couple of sites where the operations/monitoring folks are not the admins of the systems, so trying to push such a change through would take weeks if not months. It could be a technological issue, adding a nagios user to 1000 /etc/password files manually for example. I agree it's not an approach I would want to use.. > to establish an unprivileged 'nagios' user on >their systems - so they would run them as root. Yeah running all plugins as root gives me the heebie jeebies too. >I know, security awareness should be part of the persons who are using >the tools, scripts and programs - but 80% of security holes came from >people who didn't know what they are doing. Yup that's true but it's what sysadmins are hired to do. Make the risk assessment based on the business needs of the company. If nagios was an end user tool, that would be a different story. >Without starting a flame on this topic I would like to ask what do you >think of some security benefits like: > >* don't run the code if UID is 0: Hard but effective - check uid and > abort with a warning. Well in some cases I have to run plugins as root as root is the only person allowed access to the device/file. I use a nagios account for intermachine access, and the nagios user has a forced command that validates the command line before it's executed and restricts what can be run. So I use sudo to log the command that is run with elevated privs. The alternative is to change the permissions on files, modify vendor supplied log rotation configurations/scripts ... throughout the enterprise. Then keep maintaining those changes throughout system upgrades etc. Also I need to retrain every system scanner out there that /var/log/messages should be root.nagios mode 640 etc. Finally make sure new admins understand all the changes that may impact them so they don't go and reverse them because rpm -V said it was wrong. A major pain in the ... well, you get the idea. >* try to drop the privileges to the given user by the configure run > as a hard coded option Again in my senario it would introduce more complexity that leads to people doing other stupid stuff (/dev/mem mode 644 anybody, hey at least it wasn't 666). >I am not stupid enough to run my plugins with root privileges - but >there are thousand of users out there who won't know what they're >doing. I am very selective in what plugins run as root, but I do have a handful where overall security is improved by running them as root rather then trying to open access to the monitored item. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From dermoth at aei.ca Sat Jul 19 05:14:12 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 18 Jul 2008 23:14:12 -0400 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <4880E503.3000703@process-zero.de> References: <4880E503.3000703@process-zero.de> Message-ID: <48815C04.1090506@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/07/08 02:46 PM, Hendrik B?cker wrote: > Hi List, > > just a few moments ago I've read a question by a user if it would be a > problem to run the nagios plugins with root right via check_by_ssh. > > Yes - I laughed too as I read that. But in the following discussion it > clears up - they already have a spreaded root ssh key on most of their > systems and are to lazy to establish an unprivileged 'nagios' user on > their systems - so they would run them as root. > > I know, security awareness should be part of the persons who are using > the tools, scripts and programs - but 80% of security holes came from > people who didn't know what they are doing. > > Without starting a flame on this topic I would like to ask what do you > think of some security benefits like: > > * don't run the code if UID is 0: Hard but effective - check uid and > abort with a warning. > * try to drop the privileges to the givven user by the configure run as > a hard coded option This is indeed a good idea... I think all plugins could drop privileges if they are run as root. We should probably make it an option for both Perl (Nagios::Plugins) and C plugins, and turn it to default behaviour in a major release. At the same time we would need a standard option to specify a user to run as, so that anyone requiring root (or any other user) privileges for some reason would still be able to. This could also help catching the typical permission problems where users succeed running plugins as root, but fails running them from Nagios. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIgVwE6dZ+Kt5BchYRAmGnAKCBEDlsXJ6xQtAn3UQ/k+2AzltB3QCfRYP4 ESd3wdtR9x7x6NqgoBmmalY= =7xLx -----END PGP SIGNATURE----- From rich at richhorner.com Sat Jul 19 05:17:58 2008 From: rich at richhorner.com (Richard Edward Horner) Date: Fri, 18 Jul 2008 23:17:58 -0400 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <48815C04.1090506@aei.ca> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> Message-ID: <7a65a83a0807182017o74f86d1m3fc07e44fe332855@mail.gmail.com> Am I mistaken or doesn't check_mailq require root privileges? I have not used every plugin that ships but I would imagine there would be at least one more. Thanks, Rich(ard) > This is indeed a good idea... I think all plugins could drop privileges > if they are run as root. We should probably make it an option for both > Perl (Nagios::Plugins) and C plugins, and turn it to default behaviour > in a major release. -- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso rich at richhorner.com http://richhorner.com From ae at op5.se Sat Jul 19 09:35:07 2008 From: ae at op5.se (Andreas Ericsson) Date: Sat, 19 Jul 2008 09:35:07 +0200 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <48815C04.1090506@aei.ca> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> Message-ID: <4881992B.9030706@op5.se> Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 18/07/08 02:46 PM, Hendrik B?cker wrote: >> Hi List, >> >> just a few moments ago I've read a question by a user if it would be a >> problem to run the nagios plugins with root right via check_by_ssh. >> >> Yes - I laughed too as I read that. But in the following discussion it >> clears up - they already have a spreaded root ssh key on most of their >> systems and are to lazy to establish an unprivileged 'nagios' user on >> their systems - so they would run them as root. >> >> I know, security awareness should be part of the persons who are using >> the tools, scripts and programs - but 80% of security holes came from >> people who didn't know what they are doing. >> >> Without starting a flame on this topic I would like to ask what do you >> think of some security benefits like: >> >> * don't run the code if UID is 0: Hard but effective - check uid and >> abort with a warning. >> * try to drop the privileges to the givven user by the configure run as >> a hard coded option > > This is indeed a good idea... I think all plugins could drop privileges > if they are run as root. We should probably make it an option for both > Perl (Nagios::Plugins) and C plugins, and turn it to default behaviour > in a major release. > Sensible. Just do setuid(geteuid()); in C, and whatever's equivalent in perl. > At the same time we would need a standard option to specify a user to > run as, so that anyone requiring root (or any other user) privileges for > some reason would still be able to. > I'd hate that idea, since all plugins would need to be suid root for this to actually work if the user running them is anyone else than root or is already the user supposed to run the plugin. It's stupid. Don't do it. > This could also help catching the typical permission problems where > users succeed running plugins as root, but fails running them from Nagios. > That can already be caught using mechanisms such as sudo. There's no way of making bug-reports more accurate by trying to make plugin error reporting fool-proof, so don't even try it. Let's make sure they fail in a predictable way with an accurate error message if they don't have permissions instead. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From waja at cyconet.org Sat Jul 19 11:04:08 2008 From: waja at cyconet.org (Jan Wagner) Date: Sat, 19 Jul 2008 11:04:08 +0200 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <200807181913.m6IJDGKl016252@mx1.cs.umb.edu> References: <200807181913.m6IJDGKl016252@mx1.cs.umb.edu> Message-ID: <200807191104.11784.waja@cyconet.org> On Friday 18 July 2008 21:12, John P. Rouillard wrote: > It could be a technological issue, adding a nagios user to 1000 > /etc/password files manually for example. Maybe you want to have a look at clusterssh.sf.net. Just my 2 cents, Jan. -- Never write mail to , you have been warned! -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++ ------END GEEK CODE BLOCK------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andurin at process-zero.de Sat Jul 19 20:16:13 2008 From: andurin at process-zero.de (=?UTF-8?B?SGVuZHJpayBCworDpGNrZXI=?=) Date: Sat, 19 Jul 2008 20:16:13 +0200 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <4881992B.9030706@op5.se> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> Message-ID: <48822F6D.2070009@process-zero.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Ericsson schrieb: | Thomas Guyot-Sionnest wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> On 18/07/08 02:46 PM, Hendrik B?cker wrote: |>> Hi List, |>> |>> just a few moments ago I've read a question by a user if it would be a |>> problem to run the nagios plugins with root right via check_by_ssh. |>> |>> Yes - I laughed too as I read that. But in the following discussion it |>> clears up - they already have a spreaded root ssh key on most of their |>> systems and are to lazy to establish an unprivileged 'nagios' user on |>> their systems - so they would run them as root. |>> |>> I know, security awareness should be part of the persons who are using |>> the tools, scripts and programs - but 80% of security holes came from |>> people who didn't know what they are doing. |>> |>> Without starting a flame on this topic I would like to ask what do you |>> think of some security benefits like: |>> |>> * don't run the code if UID is 0: Hard but effective - check uid and |>> abort with a warning. |>> * try to drop the privileges to the givven user by the configure run as |>> a hard coded option |> This is indeed a good idea... I think all plugins could drop privileges |> if they are run as root. We should probably make it an option for both |> Perl (Nagios::Plugins) and C plugins, and turn it to default behaviour |> in a major release. |> | | Sensible. Just do setuid(geteuid()); in C, and whatever's equivalent in | perl. | I think there are only a few lines for this in C, some fewer lines in perl if someone decide to "use Posix" in any perlplugins - that would be another dependency for plugins that might not be wanted. |> At the same time we would need a standard option to specify a user to |> run as, so that anyone requiring root (or any other user) privileges for |> some reason would still be able to. |> | | I'd hate that idea, since all plugins would need to be suid root for this | to actually work if the user running them is anyone else than root or | is already the user supposed to run the plugin. It's stupid. Don't do it. | I'm with Andreas. If the Mainstream decide to do s.th. against the lazy unsecure people to make it harder to compromise security - you won't have a config line easily set to "run_as = root". Users have to do s.th. special to let them run as root. If they had to think about and decide anyway against security it's ok. You can be sure that they do it with knowledge of the risk. |> This could also help catching the typical permission problems where |> users succeed running plugins as root, but fails running them from Nagios. |> | | That can already be caught using mechanisms such as sudo. There's no way | of making bug-reports more accurate by trying to make plugin error reporting | fool-proof, so don't even try it. Let's make sure they fail in a predictable | way with an accurate error message if they don't have permissions instead. | Full acknowledge. How many errors do we read all the day as this: "Hey guys, I've tested the following: some-system # ./check_logfiles -f /var/log/auth ... and it ran fine, but if I say nagios to this it doesn't find anything. Oh wait, something has changed: nagios at some-system ? ./check_logfiles -f /var/log/auth ... Permission denied. We all know that there are root needed plugins, and it's ok that there are some which need such a high privilege level. I guess these are the typical 80/20 things - 80% of the plugins out there don't need root, so nearly no one will do a code analysis against them but on the other side there are 20% of higher skilled users that will look into the code if it depends on root privileges. These guys might feeding lists like this if they found a bug that might open a door to an attacker. For myself: As I heard that check_icmp needs a setuid(0) I looked into the code to see that it only needs it for direct network access and so on - but until today I never looked into check_disk.c if it might tag some inodes to unaccessible on every run. The plugin devel team already has done a step. You have to explicit enter a 'make install-root' for the few plugins. A next possible step could be to drop privileges or deny a plugin run if uid is zero - except that the user on the other side has to do it explicit. I could imagine of a getopt optione like "--yes-run-as-root" without a shortcut like "-r" for it. If the user has to type this into his command definition he should know that he is doing. I guess this is more a political decision as a technical. Regards, Hendrik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkiCL20ACgkQlI0PwfxLQjldngCeN3qRVi1PXFfxZq0CQfyYF/kG 6bMAoIYBljhb0O/4ZBVJAKINqmmsiRSn =USAo -----END PGP SIGNATURE----- From dermoth at aei.ca Sat Jul 19 21:36:12 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sat, 19 Jul 2008 15:36:12 -0400 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <48822F6D.2070009@process-zero.de> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> <48822F6D.2070009@process-zero.de> Message-ID: <4882422C.4020406@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/07/08 02:16 PM, Hendrik B??cker wrote: > > > Andreas Ericsson schrieb: > | Thomas Guyot-Sionnest wrote: > |> At the same time we would need a standard option to specify a user to > |> run as, so that anyone requiring root (or any other user) privileges for > |> some reason would still be able to. > |> > | > | I'd hate that idea, since all plugins would need to be suid root for this > | to actually work if the user running them is anyone else than root or > | is already the user supposed to run the plugin. It's stupid. Don't do it. > | > I'm with Andreas. If the Mainstream decide to do s.th. against the lazy > unsecure people to make it harder to compromise security - you won't > have a config line easily set to "run_as = root". > > Users have to do s.th. special to let them run as root. If they had to > think about and decide anyway against security it's ok. You can be sure > that they do it with knowledge of the risk. I think I may have been a bit unclear. I really don't want any more plugins running as root/suid (I think there's only check_icmp and check_dhcp for now). What I'm suggesting is making it the default behaviour to drop root privileges if run as root. Plugins would still be installed as they are (no suid unless absolutely required) and we would still recommend to run plugins as an unprivileged user. However if under any circumstance (check_by_ssh, nrpe running as root, cronjob, etc.) a plugin starts as root it would drop privileges before doing anything else. So I'm viewing this as an additional security mechanism. The "standard" switch to specify a user/uid I'm talking about would primarily be a "disable" switch. If someones wants - for any reason - to run a plugin as root that's _his_ problem and I can't do anything against it. At the same time it could be used to specify a user for anyone too lazy to set it up in a better way (still better IMHO that just running as root!). > A next possible step could be to drop privileges or deny a plugin run if > uid is zero - except that the user on the other side has to do it explicit. > I could imagine of a getopt optione like "--yes-run-as-root" without a > shortcut like "-r" for it. If the user has to type this into his command > definition he should know that he is doing. That's where I don't agree. Why denying when you can just drop privileges by default? And anyone that still want to sun as root would: 1. setuid/run the plugin as root 2. Use the switch I mentioned above to force UID 0 No non-root plugin would run as root without the user knowing about it. One more though about it... I talked about a switch so far, but I think it could be a better idea to make it an environment variable, so we could drop root even before parsing arguments. Bugs in argument processing could become a security issue if untrusted users has the possibility to specify/alter arguments. While I'm aware there are many other security implication regarding this, it's not a reason not to do our best on the part we control. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIgkIr6dZ+Kt5BchYRAiKsAJ9czU7+tIxGAnWvjrScXYjYce0eJACgoPSh ysyzV3EMubGA6WPz5gOeiGA= =g63d -----END PGP SIGNATURE----- From nagios at babar.us Sun Jul 20 00:00:47 2008 From: nagios at babar.us (Olivier 'Babar' Raginel) Date: Sun, 20 Jul 2008 00:00:47 +0200 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <48822F6D.2070009@process-zero.de> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> <48822F6D.2070009@process-zero.de> Message-ID: <20080719220047.GA1898@mail.babar.us> On Sat, Jul 19, 2008 at 08:16:13PM +0200, Hendrik B??cker wrote: > I think there are only a few lines for this in C, some fewer lines in > perl if someone decide to "use Posix" in any perlplugins - that would > be another dependency for plugins that might not be wanted. You don't have to use Posix to do setuid, but you do have to use suidperl. Something like $< = $>; should do the trick, but it is highly discouraged, as emphasied by Larry Wall: "suidperl was a baaad idea" -- Larry Wall at YAPC::Europe 2005 As for the rest of the discution, I think everybody agrees we should keep the number of suid plugins to the minimal (so raw socket or some other feature), and for the rest, encourage to use some other ways (sudo might be a way, tuning group access or ACLs might be another one). -- Babar. From ae at op5.se Sun Jul 20 11:44:06 2008 From: ae at op5.se (Andreas Ericsson) Date: Sun, 20 Jul 2008 11:44:06 +0200 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <48822F6D.2070009@process-zero.de> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> <48822F6D.2070009@process-zero.de> Message-ID: <488308E6.2020400@op5.se> Hendrik B??cker wrote: > I could imagine of a getopt optione like "--yes-run-as-root" without a > shortcut like "-r" for it. If the user has to type this into his command > definition he should know that he is doing. > Except that that means possibly-suid plugins will have to parse userland data before deciding it should drop privileges, and using library calls at that, so all the code isn't easily audited. I advice against it in the strongest possible terms. If anything, improve the error messages to read something like: Failed to read /proc/foo/var12: Permission denied This plugin requires access to the frotz interface, which it currently doesn't have. To grant such access, do " That would also serve as a small education to those who aren't aware of security issues, so it's a win-win-win situation imo. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From dermoth at aei.ca Sun Jul 20 14:22:19 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Sun, 20 Jul 2008 08:22:19 -0400 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <488308E6.2020400@op5.se> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> <48822F6D.2070009@process-zero.de> <488308E6.2020400@op5.se> Message-ID: <48832DFB.9080906@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/07/08 05:44 AM, Andreas Ericsson wrote: > Hendrik B??cker wrote: >> I could imagine of a getopt optione like "--yes-run-as-root" without a >> shortcut like "-r" for it. If the user has to type this into his command >> definition he should know that he is doing. >> > > Except that that means possibly-suid plugins will have to parse userland > data before deciding it should drop privileges, and using library calls > at that, so all the code isn't easily audited. What about my suggestion of using an environment variable? See my other reply... Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIgy376dZ+Kt5BchYRAmGmAKCd5Y4Yuv2gQ38fnaQj0RaccgHlZgCfdEg9 txycHSFd2di1M81lnoPi0zg= =Dyul -----END PGP SIGNATURE----- From ae at op5.se Mon Jul 21 09:46:40 2008 From: ae at op5.se (Andreas Ericsson) Date: Mon, 21 Jul 2008 09:46:40 +0200 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <4882422C.4020406@aei.ca> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> <48822F6D.2070009@process-zero.de> <4882422C.4020406@aei.ca> Message-ID: <48843EE0.5090903@op5.se> Thomas Guyot-Sionnest wrote: > > One more though about it... I talked about a switch so far, but I think > it could be a better idea to make it an environment variable, so we > could drop root even before parsing arguments. Bugs in argument > processing could become a security issue if untrusted users has the > possibility to specify/alter arguments. While I'm aware there are many > other security implication regarding this, it's not a reason not to do > our best on the part we control. > The user controls the environment as well, so the net gain is zero. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From Sascha.Runschke at gfkl.com Mon Jul 21 10:27:53 2008 From: Sascha.Runschke at gfkl.com (Sascha.Runschke at gfkl.com) Date: Mon, 21 Jul 2008 10:27:53 +0200 Subject: [Nagiosplug-devel] Antwort: Re: Security discussion - don't run as root plugins In-Reply-To: <48822F6D.2070009@process-zero.de> Message-ID: nagiosplug-devel-bounces at lists.sourceforge.net schrieb am 19.07.2008 20:16:13: > | I'd hate that idea, since all plugins would need to be suid root for this > | to actually work if the user running them is anyone else than root or > | is already the user supposed to run the plugin. It's stupid. Don't do it. > | > I'm with Andreas. If the Mainstream decide to do s.th. against the lazy > unsecure people to make it harder to compromise security - you won't > have a config line easily set to "run_as = root". [...snip...] > I guess this is more a political decision as a technical. You know, that brings up something to my mind... I'm pretty sure you know why most admins of unix-derivates have a deep hate against Windows and Microsoft - because they try to be smarter then us. They try to predict every possible failure we could make and try to implement mechanics to prevent those failures. Which in turn results in totally restricted systems, where the admin cannot do what the admin wants to do - since the vendor thinks he was so smart to prevent me from doing that thing. Not. Don't do the same mistake and enforce your ideas on users. If someone wants to run as root - whatever her reason may be - then let her do so. If it was done by mistake - she learned something from it now (hopefully). The way to go is the un-intrusive way of privilege dropping. If a program does not need root privileges, it should drop them and in my opinion that's the responsibility of the author. Regards Sascha -- Sascha Runschke Netzwerk- und Systemmanagement Telefon : +49 (201) 102-1879 Mobil : +49 (173) 5419665 Fax : +49 (201) 102-1102105 GFKL Financial Services AG Vorstand: Dr. Peter J?nsch (Vors.), J?rgen Baltes, Dr. Till Ergenzinger, Dr. Tom Haverkamp Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagios at babar.us Mon Jul 21 10:49:12 2008 From: nagios at babar.us (Olivier 'Babar' Raginel) Date: Mon, 21 Jul 2008 10:49:12 +0200 Subject: [Nagiosplug-devel] Antwort: Security discussion - don't run as root plugins In-Reply-To: References: <48822F6D.2070009@process-zero.de> Message-ID: <20080721084912.GA32416@mail.babar.us> On Mon, Jul 21, 2008 at 10:27:53AM +0200, Sascha.Runschke at gfkl.com wrote: > Don't do the same mistake and enforce your ideas on users. > If someone wants to run as root - whatever her reason may be - then > let her do so. If it was done by mistake - she learned something from > it now (hopefully). > The way to go is the un-intrusive way of privilege dropping. > If a program does not need root privileges, it should drop them and > in my opinion that's the responsibility of the author. I'd rather go the "munin" way: # /usr/bin/munin-cron You are running this program as root, which is neither smart nor necessary. If you really want to run it as root, use the --force-root option. Else, run it as the user "munin". Aborting. Clear, self-explanatory, concise, but still flexible. Just my 2 cts. -- Babar. From ae at op5.se Mon Jul 21 11:05:24 2008 From: ae at op5.se (Andreas Ericsson) Date: Mon, 21 Jul 2008 11:05:24 +0200 Subject: [Nagiosplug-devel] Antwort: Security discussion - don't run as root plugins In-Reply-To: <20080721084912.GA32416@mail.babar.us> References: <48822F6D.2070009@process-zero.de> <20080721084912.GA32416@mail.babar.us> Message-ID: <48845154.8020504@op5.se> Olivier 'Babar' Raginel wrote: > On Mon, Jul 21, 2008 at 10:27:53AM +0200, Sascha.Runschke at gfkl.com wrote: >> Don't do the same mistake and enforce your ideas on users. >> If someone wants to run as root - whatever her reason may be - then >> let her do so. If it was done by mistake - she learned something from >> it now (hopefully). >> The way to go is the un-intrusive way of privilege dropping. >> If a program does not need root privileges, it should drop them and >> in my opinion that's the responsibility of the author. > > I'd rather go the "munin" way: > # /usr/bin/munin-cron > You are running this program as root, which is neither smart nor necessary. > If you really want to run it as root, use the --force-root option. Else, run > it as the user "munin". Aborting. > > Clear, self-explanatory, concise, but still flexible. > And over-clever. Nagios fails to run as root unless one explicitly ask for it, so they'll never be run as root under Nagios anyway (unless explcitly asked for, in which case we have no reason what so ever complaining about it). To prevent user-errors while debugging, I could imagine doing something like this (obviously with a more informative message): end_of_real_output: if (!geteuid() && isatty(fileno(stdout)) printf(stderr, "Don't debug plugins as root.\n"); -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From Sascha.Runschke at gfkl.com Mon Jul 21 11:16:39 2008 From: Sascha.Runschke at gfkl.com (Sascha.Runschke at gfkl.com) Date: Mon, 21 Jul 2008 11:16:39 +0200 Subject: [Nagiosplug-devel] Antwort: Re: Antwort: Security discussion - don't run as root plugins In-Reply-To: <20080721084912.GA32416@mail.babar.us> Message-ID: nagiosplug-devel-bounces at lists.sourceforge.net schrieb am 21.07.2008 10:49:12: > > Don't do the same mistake and enforce your ideas on users. > > If someone wants to run as root - whatever her reason may be - then > > let her do so. If it was done by mistake - she learned something from > > it now (hopefully). > > The way to go is the un-intrusive way of privilege dropping. > > If a program does not need root privileges, it should drop them and > > in my opinion that's the responsibility of the author. > > I'd rather go the "munin" way: > # /usr/bin/munin-cron > You are running this program as root, which is neither smart nor necessary. > If you really want to run it as root, use the --force-root option. Else, run > it as the user "munin". Aborting. > > Clear, self-explanatory, concise, but still flexible. I do not agree on that. It will break quite a few setups. That would require defining different checks for different machines, if you have some where you connect as root and some where you connect as nagios or even different user. That quite normal if you monitor machines of other companies... S -- Sascha Runschke Netzwerk- und Systemmanagement Telefon : +49 (201) 102-1879 Mobil : +49 (173) 5419665 Fax : +49 (201) 102-1102105 GFKL Financial Services AG Vorstand: Dr. Peter J?nsch (Vors.), J?rgen Baltes, Dr. Till Ergenzinger, Dr. Tom Haverkamp Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.urbanovski at ac-nancy-metz.fr Mon Jul 21 12:15:47 2008 From: stephane.urbanovski at ac-nancy-metz.fr (=?ISO-8859-1?Q?St=E9phane_Urbanovski?=) Date: Mon, 21 Jul 2008 12:15:47 +0200 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <48843EE0.5090903@op5.se> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> <48822F6D.2070009@process-zero.de> <4882422C.4020406@aei.ca> <48843EE0.5090903@op5.se> Message-ID: <488461D3.6020900@ac-nancy-metz.fr> Andreas Ericsson a ?crit : > Thomas Guyot-Sionnest wrote: >> One more though about it... I talked about a switch so far, but I think >> it could be a better idea to make it an environment variable, so we >> could drop root even before parsing arguments. Bugs in argument >> processing could become a security issue if untrusted users has the >> possibility to specify/alter arguments. While I'm aware there are many >> other security implication regarding this, it's not a reason not to do >> our best on the part we control. >> > > The user controls the environment as well, so the net gain is zero. I think that this protection is a good idea, but we must have a way to disable it or to turn it into a simple warning message. I like the environnement variable solution. -- St?phane Urbanovski From dermoth at aei.ca Mon Jul 21 14:18:04 2008 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 21 Jul 2008 08:18:04 -0400 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <48843EE0.5090903@op5.se> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> <48822F6D.2070009@process-zero.de> <4882422C.4020406@aei.ca> <48843EE0.5090903@op5.se> Message-ID: <48847E7C.9030701@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/07/08 03:46 AM, Andreas Ericsson wrote: > Thomas Guyot-Sionnest wrote: >> One more though about it... I talked about a switch so far, but I think >> it could be a better idea to make it an environment variable, so we >> could drop root even before parsing arguments. Bugs in argument >> processing could become a security issue if untrusted users has the >> possibility to specify/alter arguments. While I'm aware there are many >> other security implication regarding this, it's not a reason not to do >> our best on the part we control. >> > > The user controls the environment as well, so the net gain is zero. > When you parse arguments you usually parse them all, so you can have bugs there... By using environment I can simply fetch the pointer to the string in the environment before going any argument parsing. And you won't have much to do before dropping privileges. Overall the security is still enhanced as for this extra code to run the plugin must be root already (and this will avoid much more code running as root). Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIhH576dZ+Kt5BchYRAvUdAKDx164S+is6etlz6jayxbv0cNdiUwCg+6hd fewByofDWLHk9XrRxuzi2zg= =n7yD -----END PGP SIGNATURE----- From ae at op5.se Mon Jul 21 15:19:19 2008 From: ae at op5.se (Andreas Ericsson) Date: Mon, 21 Jul 2008 15:19:19 +0200 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <48847E7C.9030701@aei.ca> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> <48822F6D.2070009@process-zero.de> <4882422C.4020406@aei.ca> <48843EE0.5090903@op5.se> <48847E7C.9030701@aei.ca> Message-ID: <48848CD7.5080508@op5.se> Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 21/07/08 03:46 AM, Andreas Ericsson wrote: >> Thomas Guyot-Sionnest wrote: >>> One more though about it... I talked about a switch so far, but I think >>> it could be a better idea to make it an environment variable, so we >>> could drop root even before parsing arguments. Bugs in argument >>> processing could become a security issue if untrusted users has the >>> possibility to specify/alter arguments. While I'm aware there are many >>> other security implication regarding this, it's not a reason not to do >>> our best on the part we control. >>> >> The user controls the environment as well, so the net gain is zero. >> > > When you parse arguments you usually parse them all, so you can have > bugs there... By using environment I can simply fetch the pointer to the > string in the environment before going any argument parsing. And you > won't have much to do before dropping privileges. > You're working on the assumption that someone by mistake will cause something bad to happen because he or she is running a plugin as root but without malicious intent. The attack vector is rather that someone might set out to do something malicious from the start, in which case we shouldn't even touch input from userland before we drop privileges, because the environment data may not be nicely formatted in the manner which we expect, and we can't guarantee library calls to be bugfree. The two scenarios where a plugin run as root is bad are as follows: An attacker has gained access to the system, sufficient enough to run various programs on it but without elevated (root) privileges. In order to gain further access, the attacker locates binaries with the setuid bit set and tries to exploit possible security holes in them in order to elevate his or her own privileges. A program parsing ANY KIND of user input is, at this stage, potentially vulnerable. In other words, the only safe thing that remains to do is setuid(getuid()); *before* we have even considered any user input at all. The other scenario is one where someone logged in as root runs a plugin with no malicious intent what so ever. However, someone has managed to feed the plugin some evil data from somewhere else, triggering a bug in said plugin and thereby gaining some sort of access through it. Now, in order to protect against scenario 1, it's impossible to protect against scenario 2, because we mustn't parse any userspace data at all before dropping privileges. To protect against scenario 2, we cannot drop privileges before we have parsed some data from userspace. The conclusion is that we'd need two solutions to get this to work properly. For scenario 1, we do the setuid(getuid()); thing, meaning it's perfectly safe to install all plugins suid root (except we don't know why the user did so in the first place, so we might actually break something for them, as it has to have been a conscious choice and not the default). For scenario 1, we must only do the extra parsing if (!(setuid() | seteuid()). Imo, this snippet could work well: const char *run_as_uid; if (!(setuid() | seteuid()) { /* yes, we're actually root, not just setsuid */ int i; for (i = 1; i < argc; i++) char *arg = argv[i]; if (!strncmp("--run-as=", arg, 9)) { run_as_uid = arg + 9; break; } } } if (run_as_uid && setuid(strtol(run_as_uid)) < 0) error("Failed to setuid(%s): %s\n", run_as_uid, strerror(errno)); Relying on the environment is not very stable imo, as it's one area where memory exhaustion is so easily accomplished. > Overall the security is still enhanced as for this extra code to run the > plugin must be root already (and this will avoid much more code running > as root). > That depends. If the plugin and its libraries has (exploitable) bugs, the extra code adds protection. If not, then this extra layer adds nothing and if the extra code is buggy in an exploitable way it even reduces security. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Mon Jul 21 15:43:56 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2008 13:43:56 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2023584 ] check_ldap should work with all LDAP protocol Message-ID: Bugs item #2023584, was opened at 2008-07-21 15:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2023584&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: Argument proccessing Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michel Grentzinger (migrec) Assigned to: Nobody/Anonymous (nobody) Summary: check_ldap should work with all LDAP protocol Initial Comment: I've submitted a Debian Bug Report in order to avoid problems with the LDAP protocol. You can see it at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491233 So the maintainer tells me that if the default protocol is changed in the check_ldap script, existing installations will be break. My idea is to made the check_ldap able to work both v2 and v3 protocol of LDAP. We should have the version protocol used (v2, v3 or v2/v3) printed in result of check_ldap. I don't know how to do it. Is it possible for the team to implement this ? I think there is a lot of advantages to made the script as I explain here (see Debian bug report please). Thanks, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2023584&group_id=29880 From thomas at zango.com Mon Jul 21 23:06:13 2008 From: thomas at zango.com (Thomas Guyot-Sionnest) Date: Mon, 21 Jul 2008 17:06:13 -0400 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <48848CD7.5080508@op5.se> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> <48822F6D.2070009@process-zero.de> <4882422C.4020406@aei.ca> <48843EE0.5090903@op5.se> <48847E7C.9030701@aei.ca> <48848CD7.5080508@op5.se> Message-ID: <4884FA45.6070903@zango.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Ericsson wrote: | Thomas Guyot-Sionnest wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> On 21/07/08 03:46 AM, Andreas Ericsson wrote: |>> Thomas Guyot-Sionnest wrote: |>>> One more though about it... I talked about a switch so far, but I think |>>> it could be a better idea to make it an environment variable, so we |>>> could drop root even before parsing arguments. Bugs in argument |>>> processing could become a security issue if untrusted users has the |>>> possibility to specify/alter arguments. While I'm aware there are many |>>> other security implication regarding this, it's not a reason not to do |>>> our best on the part we control. |>>> |>> The user controls the environment as well, so the net gain is zero. |>> |> When you parse arguments you usually parse them all, so you can have |> bugs there... By using environment I can simply fetch the pointer to the |> string in the environment before going any argument parsing. And you |> won't have much to do before dropping privileges. |> | | You're working on the assumption that someone by mistake will cause | something bad to happen because he or she is running a plugin as root | but without malicious intent. The attack vector is rather that someone | might set out to do something malicious from the start, in which case | we shouldn't even touch input from userland before we drop privileges, | because the environment data may not be nicely formatted in the manner | which we expect, and we can't guarantee library calls to be bugfree. | | The two scenarios where a plugin run as root is bad are as follows: | | An attacker has gained access to the system, sufficient enough to run | various programs on it but without elevated (root) privileges. In | order to gain further access, the attacker locates binaries with the | setuid bit set and tries to exploit possible security holes in them | in order to elevate his or her own privileges. | A program parsing ANY KIND of user input is, at this stage, potentially | vulnerable. In other words, the only safe thing that remains to do is | setuid(getuid()); *before* we have even considered any user input at | all. | | The other scenario is one where someone logged in as root runs a plugin | with no malicious intent what so ever. However, someone has managed to | feed the plugin some evil data from somewhere else, triggering a bug in | said plugin and thereby gaining some sort of access through it. | | Now, in order to protect against scenario 1, it's impossible to protect | against scenario 2, because we mustn't parse any userspace data at all | before dropping privileges. | | To protect against scenario 2, we cannot drop privileges before we have | parsed some data from userspace. | | The conclusion is that we'd need two solutions to get this to work | properly. | | For scenario 1, we do the setuid(getuid()); thing, meaning it's perfectly | safe to install all plugins suid root (except we don't know why the user | did so in the first place, so we might actually break something for them, | as it has to have been a conscious choice and not the default). | | For scenario 1, we must only do the extra parsing if (!(setuid() | seteuid()). The idea is far from suggesting users running plugins as setuid, and if that's a problem we could make is an on/off switch only (so they're would be absolutely no reason one would want to setuid his binaries). I really can't be of any help if sysadmins start seuitd random binaries for shit and giggles... For now it works and don't even drop privileges, and refusing to run as root would piss-off most admins so it's not a solution imo. Again keep in mind that is can only increase security. Also, both scenarios assume the system is already vulnerable trough libraries, so there might be plenty of other attacks possible. | Imo, this snippet could work well: | | const char *run_as_uid; | if (!(setuid() | seteuid()) { /* yes, we're actually root, not just setsuid */ | int i; | for (i = 1; i < argc; i++) | char *arg = argv[i]; | if (!strncmp("--run-as=", arg, 9)) { | run_as_uid = arg + 9; | break; | } | } | } | | if (run_as_uid && setuid(strtol(run_as_uid)) < 0) | error("Failed to setuid(%s): %s\n", run_as_uid, strerror(errno)); Sure, but now you're going to update every plugin to no-op on that argument... Unless you re-write argv and update argc. | Relying on the environment is not very stable imo, as it's one area where | memory exhaustion is so easily accomplished. We only read there... It's not as we were adding new environment values. |> Overall the security is still enhanced as for this extra code to run the |> plugin must be root already (and this will avoid much more code running |> as root). |> | | That depends. If the plugin and its libraries has (exploitable) bugs, the | extra code adds protection. | If not, then this extra layer adds nothing and if the extra code is | buggy in an exploitable way it even reduces security. I'm sure we can handle such a small thing if we're careful enough. Anyways I won't do anything before having more feedback, especially from the team; I'm more concerned about the user impact... Thanks for your input and suggestions. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIhPpF6dZ+Kt5BchYRAuWXAJ0WVsOlJHuXyBrJT3Q79g+fKrYcwwCgx1Y0 1tFCQ/KN5V0OM6m26HFR3WA= =Uiak -----END PGP SIGNATURE----- From ae at op5.se Tue Jul 22 07:42:41 2008 From: ae at op5.se (Andreas Ericsson) Date: Tue, 22 Jul 2008 07:42:41 +0200 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <4884FA45.6070903@zango.com> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> <48822F6D.2070009@process-zero.de> <4882422C.4020406@aei.ca> <48843EE0.5090903@op5.se> <48847E7C.9030701@aei.ca> <48848CD7.5080508@op5.se> <4884FA45.6070903@zango.com> Message-ID: <48857351.9040801@op5.se> Thomas Guyot-Sionnest wrote: > > | Imo, this snippet could work well: > | > | const char *run_as_uid; > | if (!(setuid() | seteuid()) { /* yes, we're actually root, not just > setsuid */ > | int i; > | for (i = 1; i < argc; i++) > | char *arg = argv[i]; > | if (!strncmp("--run-as=", arg, 9)) { > | run_as_uid = arg + 9; > | break; > | } > | } > | } > | > | if (run_as_uid && setuid(strtol(run_as_uid)) < 0) > | error("Failed to setuid(%s): %s\n", run_as_uid, strerror(errno)); > > Sure, but now you're going to update every plugin to no-op on that > argument... Unless you re-write argv and update argc. > Yes. > | Relying on the environment is not very stable imo, as it's one area where > | memory exhaustion is so easily accomplished. > > We only read there... It's not as we were adding new environment values. > Reading is actually the dangerous part, as "reading" can just as well be spelled "writing to memory allocated by the program". > |> Overall the security is still enhanced as for this extra code to run the > |> plugin must be root already (and this will avoid much more code running > |> as root). > |> > | > | That depends. If the plugin and its libraries has (exploitable) bugs, the > | extra code adds protection. > | If not, then this extra layer adds nothing and if the extra code is > | buggy in an exploitable way it even reduces security. > > I'm sure we can handle such a small thing if we're careful enough. > > Anyways I won't do anything before having more feedback, especially from > the team; I'm more concerned about the user impact... > I doubt anyone will use this option in the foreseeable future, so I think the user impact is minimal. Otoh, I see very little reason for doing it in the first place, so perhaps I'm just weird. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Tue Jul 22 14:44:39 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2008 12:44:39 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2024628 ] check_dhcp should work on localhost Message-ID: Bugs item #2024628, was opened at 2008-07-22 14:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2024628&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michel Grentzinger (migrec) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp should work on localhost Initial Comment: As described partially in http://sourceforge.net/tracker/index.php?func=detail&aid=1090549&group_id=29880&atid=397597, the check_dhcp plugin fails when it's executed in the same server who runs DHCP monitored. Is it possible to make the script able to monitor a DHCP server even if it is running on the same host that Nagios process ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2024628&group_id=29880 From noreply at sourceforge.net Tue Jul 22 15:19:24 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2008 13:19:24 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 15:21 Message generated for change (Comment added) made by sghosh 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. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .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, , 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: Subhendu Ghosh (sghosh) Date: 2008-07-22 09:19 Message: Logged In: YES user_id=46572 Originator: NO The current code base using the DHCP protocol cannot monitor a server on the same host as the plugin. One alternative, at least for the ISC DHCP server, would be write a new plugin using dhctl/omapi to query the server directly. side benefit would be ability to probe for the dhcp failover state ---------------------------------------------------------------------- Comment By: tigalch (tigalch) Date: 2008-06-05 07:34 Message: Logged In: YES user_id=2108467 Originator: NO Hello, I would like to know if a solution to this problem is allready available or will be available soon? With the most recent plugins (1.4.12)the problem still remains. thanks and regards ---------------------------------------------------------------------- Comment By: liosme (lisme) Date: 2007-07-26 16:49 Message: Logged In: YES user_id=1854343 Originator: NO hello, i want to know if you resolv the problem with check_dhcp. I have tha same problem it is: ============================================ [root at desarrollo libexec]# ./check_dhcp -v DHCP socket: 3 Hardware address: 00e07dd6dd58 DHCPDISCOVER to 255.255.255.255 port 68 DHCPDISCOVER XID: 116527212 (0x6F2106C) 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. ========================================= i use fedora 4 nagios 3.0a4 and plugin 1.4.7 if you resolv this problem with check_dhcp, woud you tell me how you resolv this. or explained more please. ---------------------------------------------------------------------- Comment By: Loic Dachary (loic) Date: 2007-05-20 17: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 10: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 09: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 07: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 09: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 00: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 14: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 13: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 03: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-07 18: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 13: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 05: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 05: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 05: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 05: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 04: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 04: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 03: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 03: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-23 21: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 04: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 05: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 15: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 13: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 From noreply at sourceforge.net Tue Jul 22 15:34:00 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2008 13:34:00 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 21:21 Message generated for change (Comment added) made by hweiss 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: Holger Weiss (hweiss) Summary: check_dhcp ignores DHCP replies Initial Comment: check_dhcp ignores the DHCP replies apparently because they are broadcast to 255.255.255.255. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .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, , 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: Holger Weiss (hweiss) Date: 2008-07-22 15:33 Message: Logged In: YES user_id=759506 Originator: NO Checking a DHCP server which runs on the *local* host currently is not possible with check_dhcp (though it might work if the DHCP server was compiled to use normal sockets, as opposed to the LPF/BPF/whatever interfaces it usually uses). Making this possible requires some non-trivial code changes to check_dhcp, so we cannot make any promises as to when this will be done. As a workaround, check_dhcp can be executed on a remote host via NRPE or NSCA (IMO, checking DHCP remotely makes sense anyway). ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2008-07-22 15:19 Message: Logged In: YES user_id=46572 Originator: NO The current code base using the DHCP protocol cannot monitor a server on the same host as the plugin. One alternative, at least for the ISC DHCP server, would be write a new plugin using dhctl/omapi to query the server directly. side benefit would be ability to probe for the dhcp failover state ---------------------------------------------------------------------- Comment By: tigalch (tigalch) Date: 2008-06-05 13:34 Message: Logged In: YES user_id=2108467 Originator: NO Hello, I would like to know if a solution to this problem is allready available or will be available soon? With the most recent plugins (1.4.12)the problem still remains. thanks and regards ---------------------------------------------------------------------- Comment By: liosme (lisme) Date: 2007-07-26 22:49 Message: Logged In: YES user_id=1854343 Originator: NO hello, i want to know if you resolv the problem with check_dhcp. I have tha same problem it is: ============================================ [root at desarrollo libexec]# ./check_dhcp -v DHCP socket: 3 Hardware address: 00e07dd6dd58 DHCPDISCOVER to 255.255.255.255 port 68 DHCPDISCOVER XID: 116527212 (0x6F2106C) 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. ========================================= i use fedora 4 nagios 3.0a4 and plugin 1.4.7 if you resolv this problem with check_dhcp, woud you tell me how you resolv this. or explained more please. ---------------------------------------------------------------------- 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 From noreply at sourceforge.net Tue Jul 22 15:39:44 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2008 13:39:44 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2024628 ] check_dhcp should work on localhost Message-ID: Bugs item #2024628, was opened at 2008-07-22 14:44 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2024628&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: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Michel Grentzinger (migrec) Assigned to: Nobody/Anonymous (nobody) Summary: check_dhcp should work on localhost Initial Comment: As described partially in http://sourceforge.net/tracker/index.php?func=detail&aid=1090549&group_id=29880&atid=397597, the check_dhcp plugin fails when it's executed in the same server who runs DHCP monitored. Is it possible to make the script able to monitor a DHCP server even if it is running on the same host that Nagios process ? ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2008-07-22 15:39 Message: Logged In: YES user_id=759506 Originator: NO Yes, it's possible, but it requires some not quite trivial code changes. I for one cannot promise I'll get round to it anytime soon. Patches welcome :-) For the moment, the only option is to check the DHCP server remotely (which IMO makes sense anyway). I'll close this item as it effectively duplicates #1090549. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2024628&group_id=29880 From noreply at sourceforge.net Tue Jul 22 15:46:30 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2008 13:46:30 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 15:21 Message generated for change (Comment added) made by sghosh 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. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .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, , 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: Subhendu Ghosh (sghosh) Date: 2008-07-22 09:46 Message: Logged In: YES user_id=46572 Originator: NO The current code base using the DHCP protocol cannot monitor a server on the same host as the plugin. One alternative, at least for the ISC DHCP server, would be write a new plugin using dhctl/omapi to query the server directly. side benefit would be ability to probe for the dhcp failover state ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-07-22 09:33 Message: Logged In: YES user_id=759506 Originator: NO Checking a DHCP server which runs on the *local* host currently is not possible with check_dhcp (though it might work if the DHCP server was compiled to use normal sockets, as opposed to the LPF/BPF/whatever interfaces it usually uses). Making this possible requires some non-trivial code changes to check_dhcp, so we cannot make any promises as to when this will be done. As a workaround, check_dhcp can be executed on a remote host via NRPE or NSCA (IMO, checking DHCP remotely makes sense anyway). ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2008-07-22 09:19 Message: Logged In: YES user_id=46572 Originator: NO The current code base using the DHCP protocol cannot monitor a server on the same host as the plugin. One alternative, at least for the ISC DHCP server, would be write a new plugin using dhctl/omapi to query the server directly. side benefit would be ability to probe for the dhcp failover state ---------------------------------------------------------------------- Comment By: tigalch (tigalch) Date: 2008-06-05 07:34 Message: Logged In: YES user_id=2108467 Originator: NO Hello, I would like to know if a solution to this problem is allready available or will be available soon? With the most recent plugins (1.4.12)the problem still remains. thanks and regards ---------------------------------------------------------------------- Comment By: liosme (lisme) Date: 2007-07-26 16:49 Message: Logged In: YES user_id=1854343 Originator: NO hello, i want to know if you resolv the problem with check_dhcp. I have tha same problem it is: ============================================ [root at desarrollo libexec]# ./check_dhcp -v DHCP socket: 3 Hardware address: 00e07dd6dd58 DHCPDISCOVER to 255.255.255.255 port 68 DHCPDISCOVER XID: 116527212 (0x6F2106C) 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. ========================================= i use fedora 4 nagios 3.0a4 and plugin 1.4.7 if you resolv this problem with check_dhcp, woud you tell me how you resolv this. or explained more please. ---------------------------------------------------------------------- Comment By: Loic Dachary (loic) Date: 2007-05-20 17: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 10: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 09: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 07: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 09: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 00: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 14: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 13: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 03: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-07 18: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 13: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 05: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 05: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 05: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 05: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 04: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 04: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 03: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 03: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-23 21: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 04: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 05: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 15: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 13: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 From noreply at sourceforge.net Tue Jul 22 15:48:48 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2008 13:48:48 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 15:21 Message generated for change (Comment added) made by sghosh 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. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .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, , 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: Subhendu Ghosh (sghosh) Date: 2008-07-22 09:48 Message: Logged In: YES user_id=46572 Originator: NO sorry about the repost - browser reload issue ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2008-07-22 09:46 Message: Logged In: YES user_id=46572 Originator: NO The current code base using the DHCP protocol cannot monitor a server on the same host as the plugin. One alternative, at least for the ISC DHCP server, would be write a new plugin using dhctl/omapi to query the server directly. side benefit would be ability to probe for the dhcp failover state ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-07-22 09:33 Message: Logged In: YES user_id=759506 Originator: NO Checking a DHCP server which runs on the *local* host currently is not possible with check_dhcp (though it might work if the DHCP server was compiled to use normal sockets, as opposed to the LPF/BPF/whatever interfaces it usually uses). Making this possible requires some non-trivial code changes to check_dhcp, so we cannot make any promises as to when this will be done. As a workaround, check_dhcp can be executed on a remote host via NRPE or NSCA (IMO, checking DHCP remotely makes sense anyway). ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2008-07-22 09:19 Message: Logged In: YES user_id=46572 Originator: NO The current code base using the DHCP protocol cannot monitor a server on the same host as the plugin. One alternative, at least for the ISC DHCP server, would be write a new plugin using dhctl/omapi to query the server directly. side benefit would be ability to probe for the dhcp failover state ---------------------------------------------------------------------- Comment By: tigalch (tigalch) Date: 2008-06-05 07:34 Message: Logged In: YES user_id=2108467 Originator: NO Hello, I would like to know if a solution to this problem is allready available or will be available soon? With the most recent plugins (1.4.12)the problem still remains. thanks and regards ---------------------------------------------------------------------- Comment By: liosme (lisme) Date: 2007-07-26 16:49 Message: Logged In: YES user_id=1854343 Originator: NO hello, i want to know if you resolv the problem with check_dhcp. I have tha same problem it is: ============================================ [root at desarrollo libexec]# ./check_dhcp -v DHCP socket: 3 Hardware address: 00e07dd6dd58 DHCPDISCOVER to 255.255.255.255 port 68 DHCPDISCOVER XID: 116527212 (0x6F2106C) 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. ========================================= i use fedora 4 nagios 3.0a4 and plugin 1.4.7 if you resolv this problem with check_dhcp, woud you tell me how you resolv this. or explained more please. ---------------------------------------------------------------------- Comment By: Loic Dachary (loic) Date: 2007-05-20 17: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 10: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 09: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 07: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 09: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 00: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 14: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 13: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 03: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-07 18: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 13: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 05: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 05: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 05: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 05: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 04: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 04: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 03: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 03: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-23 21: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 04: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 05: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 15: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 13: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 From noreply at sourceforge.net Tue Jul 22 15:59:43 2008 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2008 13:59:43 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 21:21 Message generated for change (Comment added) made by hweiss 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. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .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, , 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: Holger Weiss (hweiss) Date: 2008-07-22 15:59 Message: Logged In: YES user_id=759506 Originator: NO And sorry for overlooking your comment (it wasn't there yet as I wrote mine and then I got distracted before I submitted it) ;-) ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2008-07-22 15:48 Message: Logged In: YES user_id=46572 Originator: NO sorry about the repost - browser reload issue ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2008-07-22 15:46 Message: Logged In: YES user_id=46572 Originator: NO The current code base using the DHCP protocol cannot monitor a server on the same host as the plugin. One alternative, at least for the ISC DHCP server, would be write a new plugin using dhctl/omapi to query the server directly. side benefit would be ability to probe for the dhcp failover state ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-07-22 15:33 Message: Logged In: YES user_id=759506 Originator: NO Checking a DHCP server which runs on the *local* host currently is not possible with check_dhcp (though it might work if the DHCP server was compiled to use normal sockets, as opposed to the LPF/BPF/whatever interfaces it usually uses). Making this possible requires some non-trivial code changes to check_dhcp, so we cannot make any promises as to when this will be done. As a workaround, check_dhcp can be executed on a remote host via NRPE or NSCA (IMO, checking DHCP remotely makes sense anyway). ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2008-07-22 15:19 Message: Logged In: YES user_id=46572 Originator: NO The current code base using the DHCP protocol cannot monitor a server on the same host as the plugin. One alternative, at least for the ISC DHCP server, would be write a new plugin using dhctl/omapi to query the server directly. side benefit would be ability to probe for the dhcp failover state ---------------------------------------------------------------------- Comment By: tigalch (tigalch) Date: 2008-06-05 13:34 Message: Logged In: YES user_id=2108467 Originator: NO Hello, I would like to know if a solution to this problem is allready available or will be available soon? With the most recent plugins (1.4.12)the problem still remains. thanks and regards ---------------------------------------------------------------------- Comment By: liosme (lisme) Date: 2007-07-26 22:49 Message: Logged In: YES user_id=1854343 Originator: NO hello, i want to know if you resolv the problem with check_dhcp. I have tha same problem it is: ============================================ [root at desarrollo libexec]# ./check_dhcp -v DHCP socket: 3 Hardware address: 00e07dd6dd58 DHCPDISCOVER to 255.255.255.255 port 68 DHCPDISCOVER XID: 116527212 (0x6F2106C) 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. ========================================= i use fedora 4 nagios 3.0a4 and plugin 1.4.7 if you resolv this problem with check_dhcp, woud you tell me how you resolv this. or explained more please. ---------------------------------------------------------------------- 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 From frimik at gmail.com Tue Jul 22 20:27:31 2008 From: frimik at gmail.com (Mikael Fridh) Date: Tue, 22 Jul 2008 20:27:31 +0200 Subject: [Nagiosplug-devel] Security discussion - don't run as root plugins In-Reply-To: <488308E6.2020400@op5.se> References: <4880E503.3000703@process-zero.de> <48815C04.1090506@aei.ca> <4881992B.9030706@op5.se> <48822F6D.2070009@process-zero.de> <488308E6.2020400@op5.se> Message-ID: <323f67830807221127j5cf93385yfd4bcb8303efb819@mail.gmail.com> On 7/20/08, Andreas Ericsson wrote: > Hendrik B??cker wrote: > > I could imagine of a getopt optione like "--yes-run-as-root" without a > > shortcut like "-r" for it. If the user has to type this into his command > > definition he should know that he is doing. What's next for a future plugin that's even more volatile then the current ones? --yes-really-run-as-root --im-not-kidding-really-really-run-as-root > Failed to read /proc/foo/var12: Permission denied > This plugin requires access to the frotz interface, which it currently > doesn't have. To grant such access, do secure-way-here>" > > That would also serve as a small education to those who aren't aware of > security issues, so it's a win-win-win situation imo. Sure, that's up to each author or according to the guidelines for plugin-writing. I don't think nagios-plugins' job is to educate the users about the fact that running everything as root might be a bad idea. As long as the INSTALL and/or README contains or refers to _sane_ installation/setup instructions I think the nagios-plugins' authors have done their jobs. And if some distributions/packagers do not keep it as sane as upstream did, they are the ones to blame. If I am logged in as root and run a command as root, I sure as hell do not want it to change to another uid unless I tell it to! (via either /etc/nagios/check_XXX.conf or a --user=XXX flag). Let's privilege separate everything and have all plugins chroot themselves too while trying to keep them easily audited, no? :) -- Mike From ilugopal at googlemail.com Wed Jul 23 14:34:08 2008 From: ilugopal at googlemail.com (gopalan venkatramani) Date: Wed, 23 Jul 2008 18:04:08 +0530 Subject: [Nagiosplug-devel] Monitoring OpenVMS servers Message-ID: <96a075e20807230534t1a1e212fw37ecfa0a9df677e6@mail.gmail.com> Hi I wish to monitor OpenVMS servers. The reqr is as follows, 1. Monitoring OpenVMS on Alpha servers 2. Montiroing ORacle RDB on VMS env Plz let me know if there is any NRPE plugin for monitoring Oracle RDB on OpenVMS env. Its a great req. Does anybody developed. Is there any one can share any documentation on OpenVMS monitoring using Nagios. Thanks gV -------------- next part -------------- An HTML attachment was scrubbed... URL: From PsychoTrahe at gmx.de Wed Jul 23 21:46:05 2008 From: PsychoTrahe at gmx.de (Matthias Eble) Date: Wed, 23 Jul 2008 21:46:05 +0200 Subject: [Nagiosplug-devel] Antwort: Security discussion - don't run as root plugins In-Reply-To: <48845154.8020504@op5.se> References: <48822F6D.2070009@process-zero.de> <20080721084912.GA32416@mail.babar.us> <48845154.8020504@op5.se> Message-ID: <1216842365.6961.22.camel@pc.site> Hi all, On Mon, 2008-07-21 at 11:05 +0200, Andreas Ericsson wrote: > To prevent user-errors while debugging, I could imagine doing something > like this (obviously with a more informative message): > > end_of_real_output: > if (!geteuid() && isatty(fileno(stdout)) > printf(stderr, "Don't debug plugins as root.\n"); this is exactly what I wanted to propose while reading this thread. Dropping privileges to which id ever determined by an argument, env-var or whatever isn't worth the effort if you ask me. Under normal circumstances the plugins (except the plugins-root/ ones) are run with an unprivileged uid. If not, one has to assume the user knows what he/she is doing. Thus no one should be hindered to do so, as this might be necessary or sensible in some cases. I definitely hate the problem reports made by uid-0-testers. So attaching a note to stderr is a good way to inform interactive users that they might do something wrong. I could also image adding such a text to the last line of plugin stdout. With that, the warning is also shown in the UI (v3) or silently ignored (v2). A configure option could also be added to prevent writing the warning to stdout. Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ilugopal at googlemail.com Thu Jul 24 14:17:13 2008 From: ilugopal at googlemail.com (gopalan venkatramani) Date: Thu, 24 Jul 2008 17:47:13 +0530 Subject: [Nagiosplug-devel] monitoring Oracle RDB on OpenVMS Message-ID: <96a075e20807240517k6515b315w36b6bf0bb38516d@mail.gmail.com> Hi all, I wish to monitor Oracle RDB on OpenVMS server. Let me know if any one done this. Thanks gV -------------- next part -------------- An HTML attachment was scrubbed... URL: From D.Bierstedt at crh-group.com Tue Jul 29 13:34:24 2008 From: D.Bierstedt at crh-group.com (Bierstedt, Daniel) Date: Tue, 29 Jul 2008 13:34:24 +0200 Subject: [Nagiosplug-devel] compiling nrpe 2.12 on aix? Message-ID: <92F5392DABB4094F9B99B7484C35FE56565426@DE01SX02.corp.crh-group.com> Hello all, I have some trouble compiling nrpe 2.12 on AIX 5.3. After I changed the configure script in line 6673 to: --- if test -f "$dir/libssl.so" || test -f "$dir/libssl.a"; then --- an run configure with: --- ./configure --with-ssl-inc=/opt/freeware/include/openssl --with-ssl-lib=/opt/freeware/lib/ --- the script runs fine and tells me to "make". But make complains like follows: --- checking for SSL headers... SSL headers found in /opt/freeware/include/.. checking for SSL libraries... SSL libraries found in /opt/freeware/lib *** Generating DH Parameters for SSL/TLS *** Generating DH parameters, 512 bit long safe prime, generator 2 This is going to take a long time .............................+.........................................+ ...+..+.+.............+.....+..........+.+..+........................... ...........................+.................+..+....................... ..................................................+..................... ..+...........+......+....................................+....+........ ...........+..+..............+...........................+....+......... ...+.........+..+....................................................... .................+....................................+..........+...+.. +..+............................................+..+.........+.......+.. ......+.............+..+.............+.................................. .....+......+................+.......................................... ........+.....+.+........+.....+.........+............+................. ....+.....................................+.......+....+................ ++*++*++*++*++*++* checking for Kerberos include files... could not find include files checking for perl... /usr/bin/perl configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating subst config.status: creating include/config.h config.status: include/config.h is unchanged *** Configuration summary for nrpe 2.12 03-10-2008 ***: General Options: ------------------------- NRPE port: 5666 NRPE user: nagios NRPE group: nagios Nagios user: nagios Nagios group: nagios Review the options above for accuracy. If they look okay, type 'make all' to compile the NRPE daemon and client. root at host:/tmp/nrpe-2.12 # make all cd ./src/; make ; cd .. gcc -g -O2 -I/opt/freeware/include/openssl -DHAVE_CONFIG_H -o nrpe nrpe.c utils.c -L/opt/freeware/lib -lssl -lcrypto -lnsl ./snprintf.o nrpe.c: In function 'get_log_facility': nrpe.c:619: error: 'LOG_FTP' undeclared (first use in this function) nrpe.c:619: error: (Each undeclared identifier is reported only once nrpe.c:619: error: for each function it appears in.) make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. --- So I cannot update from nrpe 2.10, which drives me crazy... ___ Mit freundlichen Gruessen / With best regards Daniel Bierstedt IT / Systeme C. Rob. Hammerstein GmbH & Co KG Merscheider Str. 167 D-42699 Solingen phone +49 212 3393 562 fax +49 212 3393 445 mailto:d.bierstedt at crh-group.com http://www.crh-group.com __________________________________________ This transmission is confidential and intended solely for the person or organization to whom it is addressed. It may contain privileged and confidential information. If you are not the intended recipient, you should not copy, distribute or take any action in reliance on it. If you have received this transmission in error, please notify the sender at the e-mail address above. From D.Bierstedt at crh-group.com Tue Jul 29 14:16:35 2008 From: D.Bierstedt at crh-group.com (Bierstedt, Daniel) Date: Tue, 29 Jul 2008 14:16:35 +0200 Subject: [Nagiosplug-devel] compiling nrpe 2.12 on aix? Message-ID: <92F5392DABB4094F9B99B7484C35FE56565427@DE01SX02.corp.crh-group.com> OK, sorry for writing this early! I just commented the "else if" in line 618, and the make makes it. Mit freundlichen Gruessen / With best regards Daniel Bierstedt IT / Systeme C. Rob. Hammerstein GmbH & Co KG Merscheider Str. 167 D-42699 Solingen phone +49 212 3393 562 fax +49 212 3393 445 mailto:d.bierstedt at crh-group.com http://www.crh-group.com __________________________________________ This transmission is confidential and intended solely for the person or organization to whom it is addressed. It may contain privileged and confidential information. If you are not the intended recipient, you should not copy, distribute or take any action in reliance on it. If you have received this transmission in error, please notify the sender at the e-mail address above. -----Urspr?ngliche Nachricht----- Von: nagiosplug-devel-bounces at lists.sourceforge.net [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] Im Auftrag von Bierstedt, Daniel Gesendet: Dienstag, 29. Juli 2008 13:34 An: Nagiosplug-devel at lists.sourceforge.net Betreff: [Nagiosplug-devel] compiling nrpe 2.12 on aix? Hello all, I have some trouble compiling nrpe 2.12 on AIX 5.3. After I changed the configure script in line 6673 to: --- if test -f "$dir/libssl.so" || test -f "$dir/libssl.a"; then --- an run configure with: --- ./configure --with-ssl-inc=/opt/freeware/include/openssl --with-ssl-lib=/opt/freeware/lib/ --- the script runs fine and tells me to "make". But make complains like follows: --- checking for SSL headers... SSL headers found in /opt/freeware/include/.. checking for SSL libraries... SSL libraries found in /opt/freeware/lib *** Generating DH Parameters for SSL/TLS *** Generating DH parameters, 512 bit long safe prime, generator 2 This is going to take a long time .............................+.........................................+ ...+..+.+.............+.....+..........+.+..+........................... ...........................+.................+..+....................... ..................................................+..................... ..+...........+......+....................................+....+........ ...........+..+..............+...........................+....+......... ...+.........+..+....................................................... .................+....................................+..........+...+.. +..+............................................+..+.........+.......+.. ......+.............+..+.............+.................................. .....+......+................+.......................................... ........+.....+.+........+.....+.........+............+................. ....+.....................................+.......+....+................ ++*++*++*++*++*++* checking for Kerberos include files... could not find include files checking for perl... /usr/bin/perl configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating subst config.status: creating include/config.h config.status: include/config.h is unchanged *** Configuration summary for nrpe 2.12 03-10-2008 ***: General Options: ------------------------- NRPE port: 5666 NRPE user: nagios NRPE group: nagios Nagios user: nagios Nagios group: nagios Review the options above for accuracy. If they look okay, type 'make all' to compile the NRPE daemon and client. root at host:/tmp/nrpe-2.12 # make all cd ./src/; make ; cd .. gcc -g -O2 -I/opt/freeware/include/openssl -DHAVE_CONFIG_H -o nrpe nrpe.c utils.c -L/opt/freeware/lib -lssl -lcrypto -lnsl ./snprintf.o nrpe.c: In function 'get_log_facility': nrpe.c:619: error: 'LOG_FTP' undeclared (first use in this function) nrpe.c:619: error: (Each undeclared identifier is reported only once nrpe.c:619: error: for each function it appears in.) make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. --- So I cannot update from nrpe 2.10, which drives me crazy... ___ Mit freundlichen Gruessen / With best regards Daniel Bierstedt IT / Systeme C. Rob. Hammerstein GmbH & Co KG Merscheider Str. 167 D-42699 Solingen phone +49 212 3393 562 fax +49 212 3393 445 mailto:d.bierstedt at crh-group.com http://www.crh-group.com __________________________________________ This transmission is confidential and intended solely for the person or organization to whom it is addressed. It may contain privileged and confidential information. If you are not the intended recipient, you should not copy, distribute or take any action in reliance on it. If you have received this transmission in error, please notify the sender at the e-mail address above. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________________ Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null From ilugopal at googlemail.com Wed Jul 30 09:19:25 2008 From: ilugopal at googlemail.com (gopalan venkatramani) Date: Wed, 30 Jul 2008 12:49:25 +0530 Subject: [Nagiosplug-devel] Log file monitoring Message-ID: <96a075e20807300019v6dac3307mcaa3ebd76212cdff@mail.gmail.com> Hi, I wish to process the log files. I want to match some messages in log files and display it in my nagios events. Let me know if this can be done in Nagios. Plz give me a link on this. Thanks gops -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmr at financial.com Wed Jul 30 09:34:22 2008 From: cmr at financial.com (Christoph Maser) Date: Wed, 30 Jul 2008 09:34:22 +0200 Subject: [Nagiosplug-devel] [Nagios-devel] Log file monitoring In-Reply-To: <96a075e20807300019v6dac3307mcaa3ebd76212cdff@mail.gmail.com> References: <96a075e20807300019v6dac3307mcaa3ebd76212cdff@mail.gmail.com> Message-ID: <1217403264.3500.8.camel@HUB8071NC4.lan.muc.financial.com> Hi Gopalan Please don't crosspost. Also this question has nothing to do with nagiosplug (especially not with the development of it). These kind of questions schould go to the nagios-user mailinglist. Anyway what you want is check_log from the nagiosplugin project or check_logfiles from consol (http://www.consol.com/opensource/nagios/check-logfiles) For additional information please check http://www.nagioswiki.com/, http://nagiosexchange.com/, http://www.nagioscommunity.org/ and others. And please do at least consider searching for such easy to find information before asking. HTH Chris Am Mittwoch, den 30.07.2008, 09:19 +0200 schrieb gopalan venkatramani: > Hi, > I wish to process the log files. I want to match some messages in > log files and display it in my nagios events. Let me know if this can > be done in Nagios. Plz give me a link on this. > > Thanks > gops financial.com AG Munich head office/Hauptsitz M?nchen: Maria-Probst-Str. 19 | 80939 M?nchen | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich ? HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553