From noreply at sourceforge.net Fri May 3 15:08:59 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 May 2013 06:08:59 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3612567 ] check_udp plugin can't check port state Message-ID: Bugs item #3612567, was opened at 2013-05-03 06:08 Message generated for change (Tracker Item Submitted) made by dkorzhevin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3612567&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: dkorzhevin (dkorzhevin) Assigned to: Nobody/Anonymous (nobody) Summary: check_udp plugin can't check port state Initial Comment: Hi, I use icinga 1.8.4 with nagios-plugins 1.4.16 on Debian 6.0.7 x86_64. I try to use check_udp plugin to check remote server udp port 53 (DNS) state: ./check_udp -H 192.81.219.105 -p 53 -s "" -e "" -t 15 A always receive error: "CRITICAL - Socket timeout after 15 seconds" But, port is open, and i know that. Even netcat show this (i use openbsd-netcat 1.105): nc -vzu 192.81.219.105 53 Connection to 192.81.219.105 53 port [udp/domain] succeeded! Seems, this is problem of check_udp plugin? I will provide any info to investigate this issue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3612567&group_id=29880 From noreply at sourceforge.net Fri May 10 23:56:30 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 May 2013 14:56:30 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3503921 ] check_dhcp.c incorrectly setting source ip address as siaddr Message-ID: Bugs item #3503921, was opened at 2012-03-13 16:16 Message generated for change (Comment added) made by armandelli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3503921&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: release-1.4.15 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: infotek at gmail.com () Assigned to: Holger Weiss (hweiss) Summary: check_dhcp.c incorrectly setting source ip address as siaddr Initial Comment: nagios-plugins-1.4.15 plugins-root/check_dhcp.c Sets dhcp server source ip to the next server (siaddr) IP address, causing -s to fail to operate as expected. -s, --serverip=IPADDRESS IP address of DHCP server that we must hear from root at nagios:/usr/local/src/nagios-plugins-1.4.15# ./plugins-root/check_dhcp -v DHCP socket: 3 Hardware address: 00:22:19:56:99:48 DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 275057756 (0x10650C5C) 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 recv_result_1: 300 recv_result_2: 300 receive_dhcp_packet() result: 300 receive_dhcp_packet() source: 10.10.10.15 Result=OK DHCPOFFER from IP address 10.10.10.15 via 10.10.10.15 DHCPOFFER XID: 275057756 (0x10650C5C) DHCPOFFER chaddr: 002219569948 DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 10.10.10.166 DHCPOFFER siaddr: 10.10.10.24 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 1 (0x04) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 0 seconds Renewal Time: 14400 seconds Rebinding Time: 25200 seconds Added offer from server @ 10.10.10.15 of IP address 10.10.10.166 No (more) data received (nfound: 0) Result=ERROR Total responses seen on the wire: 1 Valid responses for this machine: 1 OK: Received 1 DHCPOFFER(s), max lease time = 0 sec. 17:58:55.805403 IP (tos 0x0, ttl 128, id 20477, offset 0, flags [none], proto UDP (17), length 328) 10.10.10.15.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x10650c5c, Flags [none] (0x0000) Your-IP 10.10.10.166 Server-IP 10.10.10.24 Client-Ethernet-Address 00:22:19:56:99:48 file "kbox2000.0" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Subnet-Mask Option 1, length 4: 255.255.255.0 RN Option 58, length 4: 14400 RB Option 59, length 4: 25200 Lease-Time Option 51, length 4: 28800 Server-ID Option 54, length 4: 10.10.10.15 0x0000: 4500 0148 4ffd 0000 8011 d58f 0a0a 0a0f 0x0010: ffff ffff 0043 0044 0134 2e43 0201 0600 0x0020: 1065 0c5c 0000 0000 0000 0000 0a0a 0aa6 0x0030: 0a0a 0a18 0000 0000 0022 1956 9948 0000 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 0x0080: 0000 0000 0000 0000 6b62 6f78 3230 3030 0x0090: 2e30 0000 0000 0000 0000 0000 0000 0000 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 0x0100: 0000 0000 0000 0000 6382 5363 3501 0201 0x0110: 04ff ffff 003a 0400 0038 403b 0400 0062 0x0120: 7033 0400 0070 8036 040a 0a0a 0fff 0000 0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 0x0140: 0000 0000 0000 0000 plugins-root/check_dhcp.c FIX /* If siaddr is non-zero, set "source" to siaddr */ /* don't set the source to next boot server (siaddr) 591 infotek at gmail.com if(offer_packet.siaddr.s_addr != 0L){ source.sin_addr.s_addr = offer_packet.siaddr.s_addr ; } */ ---------------------------------------------------------------------- Comment By: andre pinho (armandelli) Date: 2013-05-10 14:56 Message: Hi guys! First timer on the forum, got a quick noob question. I just started working with nagios and programming and would like to know how do I aplly tha fix posted below? I tried executing the file in the nagios plugin folder and it did not work. Thanks a lot! Andre. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2012-06-13 15:44 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-04-12 22:30 Message: the following is a more correct in dealing with the 0x00 PAD octets... if value = 0 skip one octet else it was just an unknown value and you can skip option_length. @@ -870,9 +865,9 @@ memcpy(&serv_ident.s_addr, &offer_packet->options[x],sizeof(serv_ident.s_addr)); break; } - - /* skip option data we're ignoring */ - if(option_type!=DHCP_OPTION_REBINDING_TIME) + if(option_type=0) + x+=1; + else x+=option_length; } ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-04-12 21:07 Message: That did solve the abort issue when parsing the options, which in turn allowed serv_ident to be set. It brought out a bug in the OPTION parsing in the switch while in verbose mode I also got rid of the source = siaddr. --- ./a/plugins-root/check_dhcp.c 2010-07-27 15:47:16.000000000 -0500 +++ ./b/plugins-root/check_dhcp.c 2012-04-12 22:58:56.000000000 -0500 @@ -141,7 +141,7 @@ u_int16_t flags; /* flags */ struct in_addr ciaddr; /* IP address of this machine (if we already have one) */ struct in_addr yiaddr; /* IP address of this machine (offered by the DHCP server) */ - struct in_addr siaddr; /* IP address of DHCP server */ + struct in_addr siaddr; /* IP address of next server */ struct in_addr giaddr; /* IP address of DHCP relay */ unsigned char chaddr [MAX_DHCP_CHADDR_LENGTH]; /* hardware address of this machine */ char sname [MAX_DHCP_SNAME_LENGTH]; /* name of DHCP server */ @@ -587,11 +587,6 @@ /* Save a copy of "source" into "via" even if it's via itself */ memcpy(&via,&source,sizeof(source)) ; - /* If siaddr is non-zero, set "source" to siaddr */ - if(offer_packet.siaddr.s_addr != 0L){ - source.sin_addr.s_addr = offer_packet.siaddr.s_addr ; - } - if(verbose){ printf(_("DHCPOFFER from IP address %s"),inet_ntoa(source.sin_addr)); printf(_(" via %s\n"),inet_ntoa(via.sin_addr)); @@ -840,7 +835,7 @@ for(x=4;xoptions[x]==-1 || (int)offer_packet->options[x]==0) + if((int)offer_packet->options[x]==-1) break; /* get option type */ @@ -870,10 +865,7 @@ memcpy(&serv_ident.s_addr, &offer_packet->options[x],sizeof(serv_ident.s_addr)); break; } - - /* skip option data we're ignoring */ - if(option_type!=DHCP_OPTION_REBINDING_TIME) - x+=option_length; + x+=option_length; } if(verbose){ @@ -903,9 +895,9 @@ * the next bootstrap service (e.g., delivery of an operating system * executable image). A DHCP server always returns its own address in * the 'server identifier' option." 'serv_ident' is the 'server - * identifier' option, 'source' is the 'siaddr' field or (if 'siaddr' - * wasn't available) the IP address we received the DHCPOFFER from. If - * 'serv_ident' isn't available for some reason, we use 'source'. + * identifier' option, 'source' is the IP address we received the + * DHCPOFFER from. If 'serv_ident' isn't available for some reason, we + * use 'source'. */ new_offer->server_address=serv_ident.s_addr?serv_ident:source; new_offer->offered_address=offer_packet->yiaddr; ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2012-04-11 11:04 Message: Thank you very much. I've attached a patch, could you check whether it solves the problem? ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-04-10 21:02 Message: gdb inspecting the local variables before it is source is clobbered by siaddr Breakpoint 1, get_dhcp_offer (sock=6) at check_dhcp.c:591 591 if(offer_packet.siaddr.s_addr != 0L){ after source is clobbered by siaddr Breakpoint 2, get_dhcp_offer (sock=6) at check_dhcp.c:595 595 if(verbose){ and before and after the conditional expression that sets source Breakpoint 3, add_dhcp_offer (source={s_addr = 403311114}, offer_packet=0xbf9d7460) at check_dhcp.c:910 910 new_offer->server_address=serv_ident.s_addr?serv_ident:source; Breakpoint 4, add_dhcp_offer (source={s_addr = 403311114}, offer_packet=0xbf9d7460) at check_dhcp.c:917 917 if(verbose){ # gdb ./plugins-root/check_dhcp GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-slackware-linux"... (gdb) set args -v (gdb) break 590 Breakpoint 1 at 0x804a808: file check_dhcp.c, line 590. (gdb) break 595 Breakpoint 2 at 0x804a815: file check_dhcp.c, line 595. (gdb) break 910 Breakpoint 3 at 0x8049e56: file check_dhcp.c, line 910. (gdb) break 917 Breakpoint 4 at 0x8049e83: file check_dhcp.c, line 917. (gdb) start Breakpoint 5 at 0x804aeb8: file check_dhcp.c, line 262. Starting program: /usr/local/src/nagios-plugins-1.4.15/plugins-root/check_dhcp -v [Thread debugging using libthread_db enabled] [New Thread 0xb7e466c0 (LWP 21323)] [Switching to Thread 0xb7e466c0 (LWP 21323)] main (argc=2, argv=0xbfd162c4) at check_dhcp.c:262 262 setlocale (LC_ALL, ""); (gdb) continue Continuing. DHCP socket: 6 Hardware address: 00:22:19:56:99:48 DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 8454682 (0x81021A) 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 recv_result_1: 300 recv_result_2: 300 receive_dhcp_packet() result: 300 receive_dhcp_packet() source: 10.10.10.15 Result=OK Breakpoint 1, get_dhcp_offer (sock=6) at check_dhcp.c:591 591 if(offer_packet.siaddr.s_addr != 0L){ (gdb) info locals offer_packet = {op = 2 '\002', htype = 1 '\001', hlen = 6 '\006', hops = 0 '\0', xid = 436371712, secs = 0, flags = 0, ciaddr = {s_addr = 0}, yiaddr = {s_addr = 1879706122}, siaddr = {s_addr = 403311114}, giaddr = {s_addr = 0}, chaddr = "\000\"\031V\231H\000\000\000\000\000\000\000\000\000", sname = '\0' , file = "kbox2000.0", '\0' , options = "c\202Sc5\001\002\001\004???\000:\004\000\0008@;\004\000\000bp3\004\000\000p\2006\004\n\n\n\017?", '\0' } source = {sin_family = 2, sin_port = 17152, sin_addr = {s_addr = 252316170}, sin_zero = "\000\000\000\000\000\000\000"} via = {sin_family = 2, sin_port = 17152, sin_addr = {s_addr = 252316170}, sin_zero = "\000\000\000\000\000\000\000"} result = 0 responses = 1 x = 6 start_time = 1334116496 current_time = (gdb) continue Continuing. Breakpoint 2, get_dhcp_offer (sock=6) at check_dhcp.c:595 595 if(verbose){ (gdb) info locals offer_packet = {op = 2 '\002', htype = 1 '\001', hlen = 6 '\006', hops = 0 '\0', xid = 436371712, secs = 0, flags = 0, ciaddr = {s_addr = 0}, yiaddr = {s_addr = 1879706122}, siaddr = {s_addr = 403311114}, giaddr = {s_addr = 0}, chaddr = "\000\"\031V\231H\000\000\000\000\000\000\000\000\000", sname = '\0' , file = "kbox2000.0", '\0' , options = "c\202Sc5\001\002\001\004???\000:\004\000\0008@;\004\000\000bp3\004\000\000p\2006\004\n\n\n\017?", '\0' } source = {sin_family = 2, sin_port = 17152, sin_addr = {s_addr = 403311114}, sin_zero = "\000\000\000\000\000\000\000"} via = {sin_family = 2, sin_port = 17152, sin_addr = {s_addr = 252316170}, sin_zero = "\000\000\000\000\000\000\000"} result = 0 responses = 1 x = 6 start_time = 1334116496 current_time = (gdb) continue Continuing. DHCPOFFER from IP address 10.10.10.24 via 10.10.10.15 DHCPOFFER XID: 8454682 (0x81021A) DHCPOFFER chaddr: 002219569948 DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 10.10.10.112 DHCPOFFER siaddr: 10.10.10.24 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 1 (0x04) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 0 seconds Renewal Time: 14400 seconds Rebinding Time: 25200 seconds Breakpoint 3, add_dhcp_offer (source={s_addr = 403311114}, offer_packet=0xbfd15fa0) at check_dhcp.c:910 910 new_offer->server_address=serv_ident.s_addr?serv_ident:source; (gdb) info locals x = option_type = 25200 option_length = 4 serv_ident = {s_addr = 0} (gdb) continue Continuing. Breakpoint 4, add_dhcp_offer (source={s_addr = 403311114}, offer_packet=0xbfd15fa0) at check_dhcp.c:917 917 if(verbose){ (gdb) info locals x = option_type = 25200 option_length = 4 serv_ident = {s_addr = 0} (gdb) continue Continuing. Added offer from server @ 10.10.10.24 of IP address 10.10.10.112 Total responses seen on the wire: 1 Valid responses for this machine: 1 OK: Received 1 DHCPOFFER(s), max lease time = 0 sec. Program exited normally. (gdb) quit tcpdump (saved the pcap also) root at nagios:/usr/local/src/nagios-plugins-1.4.15# tcpdump -nvvvxX -r check_dhcp.pcap reading from file check_dhcp.pcap, link-type EN10MB (Ethernet) 22:28:36.929010 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 576) 10.10.10.26.68 > 255.255.255.255.67: [bad udp cksum e6d!] BOOTP/DHCP, Request from 00:22:19:56:99:48, length 548, xid 0x6247da8b, secs 65280, Flags [Broadcast] (0x8000) Client-Ethernet-Address 00:22:19:56:99:48 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover END Option 255, length 0 PAD Option 0, length 0, occurs 304 0x0000: 4500 0240 0000 4000 4011 248a 0a0a 0a1a E.. at ..@. at .$..... 0x0010: ffff ffff 0044 0043 022c 1661 0101 0600 .....D.C.,.a.... 0x0020: 6247 da8b ff00 8000 0000 0000 0000 0000 bG.............. 0x0030: 0000 0000 0000 0000 0022 1956 9948 0000 .........".V.H.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 01ff ........c.Sc5... 0x0110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 22:28:36.929258 IP (tos 0x0, ttl 128, id 22737, offset 0, flags [none], proto UDP (17), length 328) 10.10.10.15.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x6247da8b, Flags [none] (0x0000) Your-IP 10.10.10.112 Server-IP 10.10.10.24 Client-Ethernet-Address 00:22:19:56:99:48 file "kbox2000.0" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Subnet-Mask Option 1, length 4: 255.255.255.0 RN Option 58, length 4: 14400 RB Option 59, length 4: 25200 Lease-Time Option 51, length 4: 28800 Server-ID Option 54, length 4: 10.10.10.15 END Option 255, length 0 PAD Option 0, length 0, occurs 26 0x0000: 4500 0148 58d1 0000 8011 ccbb 0a0a 0a0f E..HX........... 0x0010: ffff ffff 0043 0044 0134 0e67 0201 0600 .....C.D.4.g.... 0x0020: 6247 da8b 0000 0000 0000 0000 0a0a 0a70 bG.............p 0x0030: 0a0a 0a18 0000 0000 0022 1956 9948 0000 .........".V.H.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 6b62 6f78 3230 3030 ........kbox2000 0x0090: 2e30 0000 0000 0000 0000 0000 0000 0000 .0.............. 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 0201 ........c.Sc5... 0x0110: 04ff ffff 003a 0400 0038 403b 0400 0062 .....:...8@;...b 0x0120: 7033 0400 0070 8036 040a 0a0a 0fff 0000 p3...p.6........ 0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0140: 0000 0000 0000 0000 ........ ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2012-04-10 15:17 Message: Hmm. As I said, I agree that the plugin's interpretation of the "siaddr" field is wrong. However, from reading the code, I wouldn't have expected the behavior you're reporting unless the "server identifier" option isn't set. So, I'd like to understand what's going on. Could you attach the dump of a DHCP session initiated by check_dhcp? ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-04-10 14:59 Message: In the tcpdump you can see the Server-ID (option 54) was set to 10.10.10.15 Server-ID Option 54, length 4: 10.10.10.15 0x36 (54) lenght 04 0a(10) 0a(10) 0a(10) 0f(15) 0x0120: 7033 0400 0070 8036 040a 0a0a 0f It appears to me that there is confusion of "Server Identifier" and "Server IP" that only comes up when one is using an siaddr. http://www.ietf.org/rfc/rfc2131.txt DHCP clarifies the interpretation of the 'siaddr' field as the address of the server to use in the next step of the client's bootstrap process. A DHCP server may return its own address in the 'siaddr' field, if the server is prepared to supply the next bootstrap service (e.g., delivery of an operating system executable image). A DHCP server always returns its own address in the 'server identifier' option. siaddr 4 IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK by server. ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-04-10 13:47 Message: Server is a Windows 2003 DHCP server with next-server "siaddr" set for PXE boot. ---------------------------------------------------------------------- Comment By: Andy () Date: 2012-04-09 08:00 Message: I get the "wrong" response without the above change also. DHCP is Windows Server 2008 R1 (actually SBS). We have a PXE Boot server and the check_dhcp thinks the PXE Boot is the actual server, which fails. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2012-03-14 10:31 Message: What sort of DHCP server are you running? The plugin will only use "siaddr" in this way if the mandatory "server identifier" option is missing from the server's response. It seems the current code tried to fix some problem which showed up in certain environments with DHCP relays involved. However, in principle I agree that the plugin's interpretation of the "siaddr" field isn't correct. ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-03-13 17:27 Message: diff --git a/a/plugins-root/check_dhcp.c b/b/plugins-root/check_dhcp.c index 2a1875c..b7f695b 100644 --- a/a/plugins-root/check_dhcp.c +++ b/b/plugins-root/check_dhcp.c @@ -588,10 +588,11 @@ int get_dhcp_offer(int sock){ memcpy(&via,&source,sizeof(source)) ; /* If siaddr is non-zero, set "source" to siaddr */ +/* don't set the source to next boot server (siaddr) 591 infotek at gmail.com if(offer_packet.siaddr.s_addr != 0L){ source.sin_addr.s_addr = offer_packet.siaddr.s_addr ; } - +*/ if(verbose){ printf(_("DHCPOFFER from IP address %s"),inet_ntoa(source.sin_addr)); printf(_(" via %s\n"),inet_ntoa(via.sin_addr)); ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-03-13 17:03 Message: I verified that I can check remote DHCP servers correctly after applying the fix. Options used were "check_dhcp -u -s 10.10.10.15". ---------------------------------------------------------------------- Comment By: infotek at gmail.com () Date: 2012-03-13 16:47 Message: Example of -s being specified correctly in verbose mode. Fails because siaddr (10.10.10.24) is copied over source (10.10.10.15). root at nagios:/usr/local/src/nagios-plugins-1.4.15# ./plugins-root/check_dhcp -v -s 10.10.10.15 Requested server address: 10.10.10.15 DHCP socket: 3 Hardware address: 00:22:19:56:99:48 DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 513242689 (0x1E977641) 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 recv_result_1: 300 recv_result_2: 300 receive_dhcp_packet() result: 300 receive_dhcp_packet() source: 10.10.10.15 Result=OK DHCPOFFER from IP address 10.10.10.24 via 10.10.10.15 DHCPOFFER XID: 513242689 (0x1E977641) DHCPOFFER chaddr: 002219569948 DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 10.10.10.166 DHCPOFFER siaddr: 10.10.10.24 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 1 (0x04) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 0 seconds Renewal Time: 14400 seconds Rebinding Time: 25200 seconds Added offer from server @ 10.10.10.24 of IP address 10.10.10.166 No (more) data received (nfound: 0) Result=ERROR Total responses seen on the wire: 1 Valid responses for this machine: 1 CRITICAL: Received 1 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 0 sec. ---------------------------------------------------------------------- Comment By: infotek at gmail.com () Date: 2012-03-13 16:33 Message: The ticket contains the output of check_dhcp after I fixed it (oops). Sorry :( Jason Ellison Below is the output from an unmodified version of check_dhcp : root at nagios:/usr/local/src/nagios-plugins-1.4.15# ./plugins-root/check_dhcp -v DHCP socket: 3 Hardware address: 00:22:19:56:99:48 DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 1292513780 (0x4D0A31F4) 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 recv_result_1: 300 recv_result_2: 300 receive_dhcp_packet() result: 300 receive_dhcp_packet() source: 10.10.10.15 Result=OK DHCPOFFER from IP address 10.10.10.24 via 10.10.10.15 DHCPOFFER XID: 1292513780 (0x4D0A31F4) DHCPOFFER chaddr: 002219569948 DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 10.10.10.166 DHCPOFFER siaddr: 10.10.10.24 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 1 (0x04) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 0 seconds Renewal Time: 14400 seconds Rebinding Time: 25200 seconds Added offer from server @ 10.10.10.24 of IP address 10.10.10.166 No (more) data received (nfound: 0) Result=ERROR Total responses seen on the wire: 1 Valid responses for this machine: 1 OK: Received 1 DHCPOFFER(s), max lease time = 0 sec. ---------------------------------------------------------------------- Comment By: infotek at gmail.com () Date: 2012-03-13 16:22 Message: was trying to use google login... Jason Ellison infotek at gmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3503921&group_id=29880 From noreply at sourceforge.net Sat May 11 00:32:11 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 May 2013 15:32:11 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3503921 ] check_dhcp.c incorrectly setting source ip address as siaddr Message-ID: Bugs item #3503921, was opened at 2012-03-13 16:16 Message generated for change (Comment added) made by infotek411 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3503921&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: release-1.4.15 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: infotek at gmail.com () Assigned to: Holger Weiss (hweiss) Summary: check_dhcp.c incorrectly setting source ip address as siaddr Initial Comment: nagios-plugins-1.4.15 plugins-root/check_dhcp.c Sets dhcp server source ip to the next server (siaddr) IP address, causing -s to fail to operate as expected. -s, --serverip=IPADDRESS IP address of DHCP server that we must hear from root at nagios:/usr/local/src/nagios-plugins-1.4.15# ./plugins-root/check_dhcp -v DHCP socket: 3 Hardware address: 00:22:19:56:99:48 DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 275057756 (0x10650C5C) 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 recv_result_1: 300 recv_result_2: 300 receive_dhcp_packet() result: 300 receive_dhcp_packet() source: 10.10.10.15 Result=OK DHCPOFFER from IP address 10.10.10.15 via 10.10.10.15 DHCPOFFER XID: 275057756 (0x10650C5C) DHCPOFFER chaddr: 002219569948 DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 10.10.10.166 DHCPOFFER siaddr: 10.10.10.24 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 1 (0x04) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 0 seconds Renewal Time: 14400 seconds Rebinding Time: 25200 seconds Added offer from server @ 10.10.10.15 of IP address 10.10.10.166 No (more) data received (nfound: 0) Result=ERROR Total responses seen on the wire: 1 Valid responses for this machine: 1 OK: Received 1 DHCPOFFER(s), max lease time = 0 sec. 17:58:55.805403 IP (tos 0x0, ttl 128, id 20477, offset 0, flags [none], proto UDP (17), length 328) 10.10.10.15.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x10650c5c, Flags [none] (0x0000) Your-IP 10.10.10.166 Server-IP 10.10.10.24 Client-Ethernet-Address 00:22:19:56:99:48 file "kbox2000.0" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Subnet-Mask Option 1, length 4: 255.255.255.0 RN Option 58, length 4: 14400 RB Option 59, length 4: 25200 Lease-Time Option 51, length 4: 28800 Server-ID Option 54, length 4: 10.10.10.15 0x0000: 4500 0148 4ffd 0000 8011 d58f 0a0a 0a0f 0x0010: ffff ffff 0043 0044 0134 2e43 0201 0600 0x0020: 1065 0c5c 0000 0000 0000 0000 0a0a 0aa6 0x0030: 0a0a 0a18 0000 0000 0022 1956 9948 0000 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 0x0080: 0000 0000 0000 0000 6b62 6f78 3230 3030 0x0090: 2e30 0000 0000 0000 0000 0000 0000 0000 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 0x0100: 0000 0000 0000 0000 6382 5363 3501 0201 0x0110: 04ff ffff 003a 0400 0038 403b 0400 0062 0x0120: 7033 0400 0070 8036 040a 0a0a 0fff 0000 0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 0x0140: 0000 0000 0000 0000 plugins-root/check_dhcp.c FIX /* If siaddr is non-zero, set "source" to siaddr */ /* don't set the source to next boot server (siaddr) 591 infotek at gmail.com if(offer_packet.siaddr.s_addr != 0L){ source.sin_addr.s_addr = offer_packet.siaddr.s_addr ; } */ ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2013-05-10 15:32 Message: This patch is already in the release. If it was not you can use the program named patch. Try "man patch" for more information. ---------------------------------------------------------------------- Comment By: andre pinho (armandelli) Date: 2013-05-10 14:56 Message: Hi guys! First timer on the forum, got a quick noob question. I just started working with nagios and programming and would like to know how do I aplly tha fix posted below? I tried executing the file in the nagios plugin folder and it did not work. Thanks a lot! Andre. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2012-06-13 15:44 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-04-12 22:30 Message: the following is a more correct in dealing with the 0x00 PAD octets... if value = 0 skip one octet else it was just an unknown value and you can skip option_length. @@ -870,9 +865,9 @@ memcpy(&serv_ident.s_addr, &offer_packet->options[x],sizeof(serv_ident.s_addr)); break; } - - /* skip option data we're ignoring */ - if(option_type!=DHCP_OPTION_REBINDING_TIME) + if(option_type=0) + x+=1; + else x+=option_length; } ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-04-12 21:07 Message: That did solve the abort issue when parsing the options, which in turn allowed serv_ident to be set. It brought out a bug in the OPTION parsing in the switch while in verbose mode I also got rid of the source = siaddr. --- ./a/plugins-root/check_dhcp.c 2010-07-27 15:47:16.000000000 -0500 +++ ./b/plugins-root/check_dhcp.c 2012-04-12 22:58:56.000000000 -0500 @@ -141,7 +141,7 @@ u_int16_t flags; /* flags */ struct in_addr ciaddr; /* IP address of this machine (if we already have one) */ struct in_addr yiaddr; /* IP address of this machine (offered by the DHCP server) */ - struct in_addr siaddr; /* IP address of DHCP server */ + struct in_addr siaddr; /* IP address of next server */ struct in_addr giaddr; /* IP address of DHCP relay */ unsigned char chaddr [MAX_DHCP_CHADDR_LENGTH]; /* hardware address of this machine */ char sname [MAX_DHCP_SNAME_LENGTH]; /* name of DHCP server */ @@ -587,11 +587,6 @@ /* Save a copy of "source" into "via" even if it's via itself */ memcpy(&via,&source,sizeof(source)) ; - /* If siaddr is non-zero, set "source" to siaddr */ - if(offer_packet.siaddr.s_addr != 0L){ - source.sin_addr.s_addr = offer_packet.siaddr.s_addr ; - } - if(verbose){ printf(_("DHCPOFFER from IP address %s"),inet_ntoa(source.sin_addr)); printf(_(" via %s\n"),inet_ntoa(via.sin_addr)); @@ -840,7 +835,7 @@ for(x=4;xoptions[x]==-1 || (int)offer_packet->options[x]==0) + if((int)offer_packet->options[x]==-1) break; /* get option type */ @@ -870,10 +865,7 @@ memcpy(&serv_ident.s_addr, &offer_packet->options[x],sizeof(serv_ident.s_addr)); break; } - - /* skip option data we're ignoring */ - if(option_type!=DHCP_OPTION_REBINDING_TIME) - x+=option_length; + x+=option_length; } if(verbose){ @@ -903,9 +895,9 @@ * the next bootstrap service (e.g., delivery of an operating system * executable image). A DHCP server always returns its own address in * the 'server identifier' option." 'serv_ident' is the 'server - * identifier' option, 'source' is the 'siaddr' field or (if 'siaddr' - * wasn't available) the IP address we received the DHCPOFFER from. If - * 'serv_ident' isn't available for some reason, we use 'source'. + * identifier' option, 'source' is the IP address we received the + * DHCPOFFER from. If 'serv_ident' isn't available for some reason, we + * use 'source'. */ new_offer->server_address=serv_ident.s_addr?serv_ident:source; new_offer->offered_address=offer_packet->yiaddr; ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2012-04-11 11:04 Message: Thank you very much. I've attached a patch, could you check whether it solves the problem? ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-04-10 21:02 Message: gdb inspecting the local variables before it is source is clobbered by siaddr Breakpoint 1, get_dhcp_offer (sock=6) at check_dhcp.c:591 591 if(offer_packet.siaddr.s_addr != 0L){ after source is clobbered by siaddr Breakpoint 2, get_dhcp_offer (sock=6) at check_dhcp.c:595 595 if(verbose){ and before and after the conditional expression that sets source Breakpoint 3, add_dhcp_offer (source={s_addr = 403311114}, offer_packet=0xbf9d7460) at check_dhcp.c:910 910 new_offer->server_address=serv_ident.s_addr?serv_ident:source; Breakpoint 4, add_dhcp_offer (source={s_addr = 403311114}, offer_packet=0xbf9d7460) at check_dhcp.c:917 917 if(verbose){ # gdb ./plugins-root/check_dhcp GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-slackware-linux"... (gdb) set args -v (gdb) break 590 Breakpoint 1 at 0x804a808: file check_dhcp.c, line 590. (gdb) break 595 Breakpoint 2 at 0x804a815: file check_dhcp.c, line 595. (gdb) break 910 Breakpoint 3 at 0x8049e56: file check_dhcp.c, line 910. (gdb) break 917 Breakpoint 4 at 0x8049e83: file check_dhcp.c, line 917. (gdb) start Breakpoint 5 at 0x804aeb8: file check_dhcp.c, line 262. Starting program: /usr/local/src/nagios-plugins-1.4.15/plugins-root/check_dhcp -v [Thread debugging using libthread_db enabled] [New Thread 0xb7e466c0 (LWP 21323)] [Switching to Thread 0xb7e466c0 (LWP 21323)] main (argc=2, argv=0xbfd162c4) at check_dhcp.c:262 262 setlocale (LC_ALL, ""); (gdb) continue Continuing. DHCP socket: 6 Hardware address: 00:22:19:56:99:48 DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 8454682 (0x81021A) 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 recv_result_1: 300 recv_result_2: 300 receive_dhcp_packet() result: 300 receive_dhcp_packet() source: 10.10.10.15 Result=OK Breakpoint 1, get_dhcp_offer (sock=6) at check_dhcp.c:591 591 if(offer_packet.siaddr.s_addr != 0L){ (gdb) info locals offer_packet = {op = 2 '\002', htype = 1 '\001', hlen = 6 '\006', hops = 0 '\0', xid = 436371712, secs = 0, flags = 0, ciaddr = {s_addr = 0}, yiaddr = {s_addr = 1879706122}, siaddr = {s_addr = 403311114}, giaddr = {s_addr = 0}, chaddr = "\000\"\031V\231H\000\000\000\000\000\000\000\000\000", sname = '\0' , file = "kbox2000.0", '\0' , options = "c\202Sc5\001\002\001\004???\000:\004\000\0008@;\004\000\000bp3\004\000\000p\2006\004\n\n\n\017?", '\0' } source = {sin_family = 2, sin_port = 17152, sin_addr = {s_addr = 252316170}, sin_zero = "\000\000\000\000\000\000\000"} via = {sin_family = 2, sin_port = 17152, sin_addr = {s_addr = 252316170}, sin_zero = "\000\000\000\000\000\000\000"} result = 0 responses = 1 x = 6 start_time = 1334116496 current_time = (gdb) continue Continuing. Breakpoint 2, get_dhcp_offer (sock=6) at check_dhcp.c:595 595 if(verbose){ (gdb) info locals offer_packet = {op = 2 '\002', htype = 1 '\001', hlen = 6 '\006', hops = 0 '\0', xid = 436371712, secs = 0, flags = 0, ciaddr = {s_addr = 0}, yiaddr = {s_addr = 1879706122}, siaddr = {s_addr = 403311114}, giaddr = {s_addr = 0}, chaddr = "\000\"\031V\231H\000\000\000\000\000\000\000\000\000", sname = '\0' , file = "kbox2000.0", '\0' , options = "c\202Sc5\001\002\001\004???\000:\004\000\0008@;\004\000\000bp3\004\000\000p\2006\004\n\n\n\017?", '\0' } source = {sin_family = 2, sin_port = 17152, sin_addr = {s_addr = 403311114}, sin_zero = "\000\000\000\000\000\000\000"} via = {sin_family = 2, sin_port = 17152, sin_addr = {s_addr = 252316170}, sin_zero = "\000\000\000\000\000\000\000"} result = 0 responses = 1 x = 6 start_time = 1334116496 current_time = (gdb) continue Continuing. DHCPOFFER from IP address 10.10.10.24 via 10.10.10.15 DHCPOFFER XID: 8454682 (0x81021A) DHCPOFFER chaddr: 002219569948 DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 10.10.10.112 DHCPOFFER siaddr: 10.10.10.24 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 1 (0x04) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 0 seconds Renewal Time: 14400 seconds Rebinding Time: 25200 seconds Breakpoint 3, add_dhcp_offer (source={s_addr = 403311114}, offer_packet=0xbfd15fa0) at check_dhcp.c:910 910 new_offer->server_address=serv_ident.s_addr?serv_ident:source; (gdb) info locals x = option_type = 25200 option_length = 4 serv_ident = {s_addr = 0} (gdb) continue Continuing. Breakpoint 4, add_dhcp_offer (source={s_addr = 403311114}, offer_packet=0xbfd15fa0) at check_dhcp.c:917 917 if(verbose){ (gdb) info locals x = option_type = 25200 option_length = 4 serv_ident = {s_addr = 0} (gdb) continue Continuing. Added offer from server @ 10.10.10.24 of IP address 10.10.10.112 Total responses seen on the wire: 1 Valid responses for this machine: 1 OK: Received 1 DHCPOFFER(s), max lease time = 0 sec. Program exited normally. (gdb) quit tcpdump (saved the pcap also) root at nagios:/usr/local/src/nagios-plugins-1.4.15# tcpdump -nvvvxX -r check_dhcp.pcap reading from file check_dhcp.pcap, link-type EN10MB (Ethernet) 22:28:36.929010 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 576) 10.10.10.26.68 > 255.255.255.255.67: [bad udp cksum e6d!] BOOTP/DHCP, Request from 00:22:19:56:99:48, length 548, xid 0x6247da8b, secs 65280, Flags [Broadcast] (0x8000) Client-Ethernet-Address 00:22:19:56:99:48 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover END Option 255, length 0 PAD Option 0, length 0, occurs 304 0x0000: 4500 0240 0000 4000 4011 248a 0a0a 0a1a E.. at ..@. at .$..... 0x0010: ffff ffff 0044 0043 022c 1661 0101 0600 .....D.C.,.a.... 0x0020: 6247 da8b ff00 8000 0000 0000 0000 0000 bG.............. 0x0030: 0000 0000 0000 0000 0022 1956 9948 0000 .........".V.H.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 01ff ........c.Sc5... 0x0110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x01f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0200: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0210: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0220: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 22:28:36.929258 IP (tos 0x0, ttl 128, id 22737, offset 0, flags [none], proto UDP (17), length 328) 10.10.10.15.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x6247da8b, Flags [none] (0x0000) Your-IP 10.10.10.112 Server-IP 10.10.10.24 Client-Ethernet-Address 00:22:19:56:99:48 file "kbox2000.0" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Subnet-Mask Option 1, length 4: 255.255.255.0 RN Option 58, length 4: 14400 RB Option 59, length 4: 25200 Lease-Time Option 51, length 4: 28800 Server-ID Option 54, length 4: 10.10.10.15 END Option 255, length 0 PAD Option 0, length 0, occurs 26 0x0000: 4500 0148 58d1 0000 8011 ccbb 0a0a 0a0f E..HX........... 0x0010: ffff ffff 0043 0044 0134 0e67 0201 0600 .....C.D.4.g.... 0x0020: 6247 da8b 0000 0000 0000 0000 0a0a 0a70 bG.............p 0x0030: 0a0a 0a18 0000 0000 0022 1956 9948 0000 .........".V.H.. 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 6b62 6f78 3230 3030 ........kbox2000 0x0090: 2e30 0000 0000 0000 0000 0000 0000 0000 .0.............. 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 3501 0201 ........c.Sc5... 0x0110: 04ff ffff 003a 0400 0038 403b 0400 0062 .....:...8@;...b 0x0120: 7033 0400 0070 8036 040a 0a0a 0fff 0000 p3...p.6........ 0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0140: 0000 0000 0000 0000 ........ ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2012-04-10 15:17 Message: Hmm. As I said, I agree that the plugin's interpretation of the "siaddr" field is wrong. However, from reading the code, I wouldn't have expected the behavior you're reporting unless the "server identifier" option isn't set. So, I'd like to understand what's going on. Could you attach the dump of a DHCP session initiated by check_dhcp? ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-04-10 14:59 Message: In the tcpdump you can see the Server-ID (option 54) was set to 10.10.10.15 Server-ID Option 54, length 4: 10.10.10.15 0x36 (54) lenght 04 0a(10) 0a(10) 0a(10) 0f(15) 0x0120: 7033 0400 0070 8036 040a 0a0a 0f It appears to me that there is confusion of "Server Identifier" and "Server IP" that only comes up when one is using an siaddr. http://www.ietf.org/rfc/rfc2131.txt DHCP clarifies the interpretation of the 'siaddr' field as the address of the server to use in the next step of the client's bootstrap process. A DHCP server may return its own address in the 'siaddr' field, if the server is prepared to supply the next bootstrap service (e.g., delivery of an operating system executable image). A DHCP server always returns its own address in the 'server identifier' option. siaddr 4 IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK by server. ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-04-10 13:47 Message: Server is a Windows 2003 DHCP server with next-server "siaddr" set for PXE boot. ---------------------------------------------------------------------- Comment By: Andy () Date: 2012-04-09 08:00 Message: I get the "wrong" response without the above change also. DHCP is Windows Server 2008 R1 (actually SBS). We have a PXE Boot server and the check_dhcp thinks the PXE Boot is the actual server, which fails. ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2012-03-14 10:31 Message: What sort of DHCP server are you running? The plugin will only use "siaddr" in this way if the mandatory "server identifier" option is missing from the server's response. It seems the current code tried to fix some problem which showed up in certain environments with DHCP relays involved. However, in principle I agree that the plugin's interpretation of the "siaddr" field isn't correct. ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-03-13 17:27 Message: diff --git a/a/plugins-root/check_dhcp.c b/b/plugins-root/check_dhcp.c index 2a1875c..b7f695b 100644 --- a/a/plugins-root/check_dhcp.c +++ b/b/plugins-root/check_dhcp.c @@ -588,10 +588,11 @@ int get_dhcp_offer(int sock){ memcpy(&via,&source,sizeof(source)) ; /* If siaddr is non-zero, set "source" to siaddr */ +/* don't set the source to next boot server (siaddr) 591 infotek at gmail.com if(offer_packet.siaddr.s_addr != 0L){ source.sin_addr.s_addr = offer_packet.siaddr.s_addr ; } - +*/ if(verbose){ printf(_("DHCPOFFER from IP address %s"),inet_ntoa(source.sin_addr)); printf(_(" via %s\n"),inet_ntoa(via.sin_addr)); ---------------------------------------------------------------------- Comment By: Jason Ellison (infotek411) Date: 2012-03-13 17:03 Message: I verified that I can check remote DHCP servers correctly after applying the fix. Options used were "check_dhcp -u -s 10.10.10.15". ---------------------------------------------------------------------- Comment By: infotek at gmail.com () Date: 2012-03-13 16:47 Message: Example of -s being specified correctly in verbose mode. Fails because siaddr (10.10.10.24) is copied over source (10.10.10.15). root at nagios:/usr/local/src/nagios-plugins-1.4.15# ./plugins-root/check_dhcp -v -s 10.10.10.15 Requested server address: 10.10.10.15 DHCP socket: 3 Hardware address: 00:22:19:56:99:48 DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 513242689 (0x1E977641) 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 recv_result_1: 300 recv_result_2: 300 receive_dhcp_packet() result: 300 receive_dhcp_packet() source: 10.10.10.15 Result=OK DHCPOFFER from IP address 10.10.10.24 via 10.10.10.15 DHCPOFFER XID: 513242689 (0x1E977641) DHCPOFFER chaddr: 002219569948 DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 10.10.10.166 DHCPOFFER siaddr: 10.10.10.24 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 1 (0x04) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 0 seconds Renewal Time: 14400 seconds Rebinding Time: 25200 seconds Added offer from server @ 10.10.10.24 of IP address 10.10.10.166 No (more) data received (nfound: 0) Result=ERROR Total responses seen on the wire: 1 Valid responses for this machine: 1 CRITICAL: Received 1 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 0 sec. ---------------------------------------------------------------------- Comment By: infotek at gmail.com () Date: 2012-03-13 16:33 Message: The ticket contains the output of check_dhcp after I fixed it (oops). Sorry :( Jason Ellison Below is the output from an unmodified version of check_dhcp : root at nagios:/usr/local/src/nagios-plugins-1.4.15# ./plugins-root/check_dhcp -v DHCP socket: 3 Hardware address: 00:22:19:56:99:48 DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 1292513780 (0x4D0A31F4) 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 recv_result_1: 300 recv_result_2: 300 receive_dhcp_packet() result: 300 receive_dhcp_packet() source: 10.10.10.15 Result=OK DHCPOFFER from IP address 10.10.10.24 via 10.10.10.15 DHCPOFFER XID: 1292513780 (0x4D0A31F4) DHCPOFFER chaddr: 002219569948 DHCPOFFER ciaddr: 0.0.0.0 DHCPOFFER yiaddr: 10.10.10.166 DHCPOFFER siaddr: 10.10.10.24 DHCPOFFER giaddr: 0.0.0.0 Option: 53 (0x01) Option: 1 (0x04) Option: 58 (0x04) Option: 59 (0x04) Lease Time: 0 seconds Renewal Time: 14400 seconds Rebinding Time: 25200 seconds Added offer from server @ 10.10.10.24 of IP address 10.10.10.166 No (more) data received (nfound: 0) Result=ERROR Total responses seen on the wire: 1 Valid responses for this machine: 1 OK: Received 1 DHCPOFFER(s), max lease time = 0 sec. ---------------------------------------------------------------------- Comment By: infotek at gmail.com () Date: 2012-03-13 16:22 Message: was trying to use google login... Jason Ellison infotek at gmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3503921&group_id=29880 From noreply at sourceforge.net Mon May 13 15:34:51 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 May 2013 06:34:51 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3613197 ] Removal / replace request Message-ID: Bugs item #3613197, was opened at 2013-05-13 06:34 Message generated for change (Tracker Item Submitted) made by aseques You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3613197&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: Joan (aseques) Assigned to: Nobody/Anonymous (nobody) Summary: Removal / replace request Initial Comment: I've been trying to use the check_rrd_data.pl from the contrib dir. Since there's no upstream to report bugs/patches, this is the only place remaining. The plugin is in a bad state, require libs from cricket to work and hasn't been updated in 11 years. In my opinion it should be either removed or replaced for something more updated such as check_rrd (http://exchange.nagios.org/directory/Plugins/Databases/RRD/check_rrd-2Epl/details) I'll be glad to do the push request if you like so... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3613197&group_id=29880 From noreply at sourceforge.net Thu May 16 15:23:43 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 May 2013 06:23:43 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-3613438 ] NTLM auth support for check_http Message-ID: Feature Requests item #3613438, was opened at 2013-05-16 06:23 Message generated for change (Tracker Item Submitted) made by juergenvigna You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=3613438&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: 5 Private: No Submitted By: J?rgen Vigna (juergenvigna) Assigned to: Nobody/Anonymous (nobody) Summary: NTLM auth support for check_http Initial Comment: Hello, I've already seen various requests for this feature, but unfortunately it never was adopted. Now I'm using nagios-plugins-1.4.16 and wrote a patch for check_http/nagios-plugins which includes this (well I fixed an already existing patch I found somewhere, maybe here). The patch is quite clean and should not clash with check_http features also code is only added if NTLM Auth is activated on configure. I attach the patch if you're interested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=3613438&group_id=29880 From noreply at sourceforge.net Wed May 22 18:20:25 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 May 2013 09:20:25 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3613736 ] check_disk show 0% used on some part on AIX Message-ID: Bugs item #3613736, was opened at 2013-05-22 09:20 Message generated for change (Tracker Item Submitted) made by cameleon078 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3613736&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: Open Resolution: None Priority: 5 Private: No Submitted By: cameleon078 (cameleon078) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk show 0% used on some part on AIX Initial Comment: I have an issue on check_disk on some part on AIX system. -bash-3.00# /var/opt/nagios/plugins/check_disk -w 5% -p /dev/tsm02fORA0lv -vvvv calling stat on /dev/tsm02fORA0lv For /ptsm02/server/filesORA0, used_pct=100 free_pct=0 used_units=1831 free_units=0 total_units=1.1991e+07 used_inodes_pct=1 free_inodes_pct=99 fsp.fsu_blocksize=4096 mult=1048576 Freespace_units result=0 Freespace% result=1 Usedspace_units result=0 Usedspace_percent result=0 Usedinodes_percent result=0 Freeinodes_percent result=0 DISK WARNING - free space: /ptsm02/server/filesORA0 0 MB (0% inode=99%);| /ptsm02/server/filesORA0=1831MB;11391488;;0;11991040 -bash-3.00# df -k /dev/tsm02fORA0lv Filesystem 1024-blocks Free %Used Iused %Iused Mounted on /dev/tsm02fORA0lv 12278824960 12276949612 1% 5 1% /ptsm02/server/filesORA0 -bash-3.00# df -i /dev/tsm02fORA0lv Filesystem 512-blocks Free %Used Iused %Iused Mounted on /dev/tsm02fORA0lv 24557649920 24553899224 1% 5 1% /ptsm02/server/filesORA0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3613736&group_id=29880 From smutel at monitoring-fr.org Thu May 23 14:18:49 2013 From: smutel at monitoring-fr.org (Samuel Mutel) Date: Thu, 23 May 2013 14:18:49 +0200 (CEST) Subject: [Nagiosplug-devel] Error in check_disk / AIX system / large part In-Reply-To: <53bb6692-dc2c-4056-b501-19f2c7520baa@mail> Message-ID: <168d8b13-b0c5-49ef-91af-81c1dd759048@mail> Hello, I encounter an issue on check_disk plugin. The two bug report below is related to my issue. https://sourceforge.net/tracker/?func=detail&aid=3613736&group_id=29880&atid=397597 https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2918714&group_id=29880 I tried to see in the source code what is wrong, but I need some help. I think that the problem is in fsusage.c. On line 231 : fsp->fsu_bavail = PROPAGATE_TOP_BIT (fsd.f_bavail); I add this printf("bavail:%g\n",fsd.f_bavail); On little part, I have the result (712G) : bavail:2.94574e-300 On large part, I have the result (11,4T) : bavail:-4.72129e-44 I think that the issue is around this peace of code. Can you help me ? Regards, Samuel Mutel. From fra.nospam.nk at gmx.de Thu May 23 18:52:05 2013 From: fra.nospam.nk at gmx.de (Frank Fegert) Date: Thu, 23 May 2013 18:52:05 +0200 Subject: [Nagiosplug-devel] Error in check_disk / AIX system / large part In-Reply-To: <168d8b13-b0c5-49ef-91af-81c1dd759048@mail> References: <53bb6692-dc2c-4056-b501-19f2c7520baa@mail> <168d8b13-b0c5-49ef-91af-81c1dd759048@mail> Message-ID: <20130523165205.GA4142@dyndns.org> Hello, On Thu, May 23, 2013 at 02:18:49PM +0200, Samuel Mutel wrote: > I encounter an issue on check_disk plugin. > > The two bug report below is related to my issue. > > https://sourceforge.net/tracker/?func=detail&aid=3613736&group_id=29880&atid=397597 > https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2918714&group_id=29880 > > I tried to see in the source code what is wrong, but I need some help. > > I think that the problem is in fsusage.c. > On line 231 : fsp->fsu_bavail = PROPAGATE_TOP_BIT (fsd.f_bavail); > I add this printf("bavail:%g\n",fsd.f_bavail); > > On little part, I have the result (712G) : bavail:2.94574e-300 > On large part, I have the result (11,4T) : bavail:-4.72129e-44 > > I think that the issue is around this peace of code. > Can you help me ? had the same issue on our TSM servers (with very large GPFS filesystems). The easiest solution that worked for me was to build a 64bit version of the nagios-plugins and deploy them on servers with large filesystems. E.g. with xlC: OBJECT_MODE="64"; export OBJECT_MODE CC="cc -q64"; export CC AR="/usr/bin/ar -X64"; export AR ./configure ... You can check if this resolves your issue with my nagios-plugins RPM for AIX: http://www.bityard.org/blog/2013/05/01/aix_rpms_nagios-nrpe_nagios-plugins HTH & best regards, Frank From massimiliano.ziccardi at gmail.com Tue May 28 11:53:57 2013 From: massimiliano.ziccardi at gmail.com (Massimiliano Ziccardi) Date: Tue, 28 May 2013 11:53:57 +0200 Subject: [Nagiosplug-devel] Nagios and JAVA plugins Message-ID: Hi all. I write here to ask you all for a suggestion. Some year ago I started an open source project called JNRPE (http://jnrpe.sourceforge.net) that allows to easily write Nagios plugins using JAVA and is fully compatible with check_nrpe. JNRPE is bundled with some plugin : at the moment all the plugins use the old range format ([@]start:end). Since I'm in the process of releasing version 2.x, my question is: do you think it would be better to keep using the old range format or would be better to use the new threshold specification ( http://nagiosplugins.org/rfc/new_threshold_syntax)? I've already implemented all the classes needed to parse the new syntax, but I'm not sure that it would be a good idea (most Nagios plugin uses the old format and I didn't want to diverge too much!). Thank you, Massimiliano -------------- next part -------------- An HTML attachment was scrubbed... URL: From palli at ok.is Tue May 28 13:19:54 2013 From: palli at ok.is (=?utf-8?Q?P=C3=A1ll_Gu=C3=B0j=C3=B3n_Sigur=C3=B0sson?=) Date: Tue, 28 May 2013 11:19:54 -0000 (GMT) Subject: [Nagiosplug-devel] Nagios and JAVA plugins In-Reply-To: Message-ID: My two cents, The new_threshold_syntax is just a proposal. And to my knowledge no one is working on making it 'official'. We support the new syntax for the new syntax, but the legacy (and inferior) syntax is currently our main one. Note, however that they are not mutually exclusive. You can have your plugins understand both :) Cheers, Palli ----- Original Message ----- From: "Massimiliano Ziccardi" To: nagiosplug-devel at lists.sourceforge.net Sent: Tuesday, May 28, 2013 9:53:57 AM Subject: [Nagiosplug-devel] Nagios and JAVA plugins Hi all. I write here to ask you all for a suggestion. Some year ago I started an open source project called JNRPE ( http://jnrpe.sourceforge.net ) that allows to easily write Nagios plugins using JAVA and is fully compatible with check_nrpe. JNRPE is bundled with some plugin : at the moment all the plugins use the old range format ([@]start:end). Since I'm in the process of releasing version 2.x, my question is: do you think it would be better to keep using the old range format or would be better to use the new threshold specification ( http://nagiosplugins.org/rfc/new_threshold_syntax )? I've already implemented all the classes needed to parse the new syntax, but I'm not sure that it would be a good idea (most Nagios plugin uses the old format and I didn't want to diverge too much!). Thank you, Massimiliano ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________________ 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 noreply at sourceforge.net Wed May 29 14:32:09 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 May 2013 05:32:09 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3571331 ] check_http converts semicolon to newline in -k Message-ID: Bugs item #3571331, was opened at 2012-09-24 14:14 Message generated for change (Comment added) made by g0hl1n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&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: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: RudolfPotucekSmart (rpsmart) Assigned to: Nobody/Anonymous (nobody) Summary: check_http converts semicolon to newline in -k Initial Comment: When trying to pass Accept: headers, which are supposed to contain semicolons, using the -k option then the semicolon is converted to a newline (verified using snapshot version 1.4.16-38-g4cdd on RHEL 6.3 and recording request using tcpdump: call: ./nagios-plugins-1.4.16-38-g4cdd/plugins/check_http -I obfuscated -H obfuscated -k 'Accept: application/json;charset=UTF-8' -u obfuscated tcpdump / wireshark: GET ofuscated HTTP/1.1 User-Agent: check_http/v1.4.16-38-g4cdd (nagios-plugins 1.4.16) Connection: close Host: obfuscated Accept: application/json charset=UTF-8 ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 05:32 Message: Hi, as far as I see in the check_http source the semicolon is used as delimiter for multiple header fields. So as the semicolon is a valid character in header fields this should be changed. Due to the fact multiple -k arguments could be passed I think such a delimiter isn't needed at all. Is there an other reason for this delimiter? br, Richard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&group_id=29880 From noreply at sourceforge.net Wed May 29 15:06:55 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 May 2013 06:06:55 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3571331 ] check_http converts semicolon to newline in -k Message-ID: Bugs item #3571331, was opened at 2012-09-24 14:14 Message generated for change (Comment added) made by g0hl1n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&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: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: RudolfPotucekSmart (rpsmart) Assigned to: Nobody/Anonymous (nobody) Summary: check_http converts semicolon to newline in -k Initial Comment: When trying to pass Accept: headers, which are supposed to contain semicolons, using the -k option then the semicolon is converted to a newline (verified using snapshot version 1.4.16-38-g4cdd on RHEL 6.3 and recording request using tcpdump: call: ./nagios-plugins-1.4.16-38-g4cdd/plugins/check_http -I obfuscated -H obfuscated -k 'Accept: application/json;charset=UTF-8' -u obfuscated tcpdump / wireshark: GET ofuscated HTTP/1.1 User-Agent: check_http/v1.4.16-38-g4cdd (nagios-plugins 1.4.16) Connection: close Host: obfuscated Accept: application/json charset=UTF-8 ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 06:06 Message: Hi, btw: I've opened a pull request for the removal of the semicolon input delimiter from the -k argument. br, Richard ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 05:32 Message: Hi, as far as I see in the check_http source the semicolon is used as delimiter for multiple header fields. So as the semicolon is a valid character in header fields this should be changed. Due to the fact multiple -k arguments could be passed I think such a delimiter isn't needed at all. Is there an other reason for this delimiter? br, Richard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&group_id=29880 From noreply at sourceforge.net Wed May 29 17:26:34 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 May 2013 08:26:34 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552839 ] Option for check_procs to ignore kernel threads Message-ID: Bugs item #3552839, was opened at 2012-07-31 16:11 Message generated for change (Comment added) made by g0hl1n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552839&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: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: Option for check_procs to ignore kernel threads Initial Comment: Hi. This is from the old / soon to be disabled again Nagios Plugins bug tracker that used to be at Nagios itself. I've just copied this bug over. I'm not the original reporter and have no idea about the thoughts about this bug. This used to be: http://tracker.nagios.org/view.php?id=221 -------------------------------------------------------------------------------- fmalfoy: -------------------------------------------------------------------------------- Hi, Amount of cores in new processor series tends to get larger and larger. The Linux kernel runs one specific kernel thread on each physical or logical core, and for several services. These kernel threads are seen as processes by the check_procs plugin, and thus taken in count while comparing to the thresholds. It would be a great functionality to be able to tell check_procs to not select them. This would allow the checks to be less dependent on the hardware specifications. The only way, for now, to avoid any alarm is to increase the thresholds, which implies to create a specific check, or checking group, for each hardware model. ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 08:26 Message: Hi, I've just added a pull request (#53) to fix this issue on GNU/Linux Systems. https://github.com/nagios-plugins/nagios-plugins/pull/53 br, Richard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552839&group_id=29880 From noreply at sourceforge.net Wed May 29 18:36:57 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 May 2013 09:36:57 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3571331 ] check_http converts semicolon to newline in -k Message-ID: Bugs item #3571331, was opened at 2012-09-24 14:14 Message generated for change (Comment added) made by rpsmart You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&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: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: RudolfPotucekSmart (rpsmart) Assigned to: Nobody/Anonymous (nobody) Summary: check_http converts semicolon to newline in -k Initial Comment: When trying to pass Accept: headers, which are supposed to contain semicolons, using the -k option then the semicolon is converted to a newline (verified using snapshot version 1.4.16-38-g4cdd on RHEL 6.3 and recording request using tcpdump: call: ./nagios-plugins-1.4.16-38-g4cdd/plugins/check_http -I obfuscated -H obfuscated -k 'Accept: application/json;charset=UTF-8' -u obfuscated tcpdump / wireshark: GET ofuscated HTTP/1.1 User-Agent: check_http/v1.4.16-38-g4cdd (nagios-plugins 1.4.16) Connection: close Host: obfuscated Accept: application/json charset=UTF-8 ---------------------------------------------------------------------- Comment By: RudolfPotucekSmart (rpsmart) Date: 2013-05-29 09:36 Message: I think multiple -k options don't help because there is only ONE header called "Accept:" with a value of "application/json;charset=UTF-8" ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 06:06 Message: Hi, btw: I've opened a pull request for the removal of the semicolon input delimiter from the -k argument. br, Richard ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 05:32 Message: Hi, as far as I see in the check_http source the semicolon is used as delimiter for multiple header fields. So as the semicolon is a valid character in header fields this should be changed. Due to the fact multiple -k arguments could be passed I think such a delimiter isn't needed at all. Is there an other reason for this delimiter? br, Richard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&group_id=29880 From noreply at sourceforge.net Wed May 29 22:48:35 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 May 2013 13:48:35 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3552836 ] check_http does not handle ; in -k parameters Message-ID: Bugs item #3552836, was opened at 2012-07-31 16:03 Message generated for change (Settings changed) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552836&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: C?lestyo (calestyo) Assigned to: Nobody/Anonymous (nobody) Summary: check_http does not handle ; in -k parameters Initial Comment: Hi. This is from the old / soon to be disabled again Nagios Plugins bug tracker that used to be at Nagios itself. I've just copied this bug over. I'm not the original reporter and have no idea about the thoughts about this bug. This used to be: http://tracker.nagios.org/view.php?id=237 -------------------------------------------------------------------------------- agflem: -------------------------------------------------------------------------------- When I execute the following check the cookie value is broken up onto two lines, thus the check always returns a 400 error. ./check_http -H mysite.com -u http://mysite.com/home/index.aspx [^] -f follow -s Welcome -k 'Cookie: user=4reqrerqwr;userlogin=123adsfjlk324' -v The cookie in the request looks like: Cookie: user=4reqrerqwr userlogin=123adsfjlk324 But should look like Cookie: user=4reqrerqwr;userlogin=123adsfjlk324 ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-05-29 13:48 Message: This is the same issue as reported in #3571331. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552836&group_id=29880 From noreply at sourceforge.net Wed May 29 22:53:56 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 May 2013 13:53:56 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3571331 ] check_http converts semicolon to newline in -k Message-ID: Bugs item #3571331, was opened at 2012-09-24 14:14 Message generated for change (Comment added) made by g0hl1n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&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: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: RudolfPotucekSmart (rpsmart) Assigned to: Nobody/Anonymous (nobody) Summary: check_http converts semicolon to newline in -k Initial Comment: When trying to pass Accept: headers, which are supposed to contain semicolons, using the -k option then the semicolon is converted to a newline (verified using snapshot version 1.4.16-38-g4cdd on RHEL 6.3 and recording request using tcpdump: call: ./nagios-plugins-1.4.16-38-g4cdd/plugins/check_http -I obfuscated -H obfuscated -k 'Accept: application/json;charset=UTF-8' -u obfuscated tcpdump / wireshark: GET ofuscated HTTP/1.1 User-Agent: check_http/v1.4.16-38-g4cdd (nagios-plugins 1.4.16) Connection: close Host: obfuscated Accept: application/json charset=UTF-8 ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 13:53 Message: Hi, multiple -k options are already implemented in the current check_http. Using them you can define multiple HTTP header fields. Until now check_http wasn't able to handle semicolons (;) in an header field, due to the fact it split them up into multiple header fields. So after my patch the mentioned use of check_http (./nagios-plugins-1.4.16-38-g4cdd/plugins/check_http -I obfuscated -H obfuscated -k 'Accept: application/json;charset=UTF-8' -u obfuscated) will work (I've testes it, I swear^^), but you wouldn't be able to specify multiple Header fields in one -k option. Hope this describes it well. Otherwise just check the sources at https://github.com/nagios-plugins/nagios-plugins/pull/52/files or the help text of check_http. br, Richard ---------------------------------------------------------------------- Comment By: RudolfPotucekSmart (rpsmart) Date: 2013-05-29 09:36 Message: I think multiple -k options don't help because there is only ONE header called "Accept:" with a value of "application/json;charset=UTF-8" ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 06:06 Message: Hi, btw: I've opened a pull request for the removal of the semicolon input delimiter from the -k argument. br, Richard ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 05:32 Message: Hi, as far as I see in the check_http source the semicolon is used as delimiter for multiple header fields. So as the semicolon is a valid character in header fields this should be changed. Due to the fact multiple -k arguments could be passed I think such a delimiter isn't needed at all. Is there an other reason for this delimiter? br, Richard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&group_id=29880 From noreply at sourceforge.net Wed May 29 23:17:20 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 May 2013 14:17:20 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-3613438 ] NTLM auth support for check_http Message-ID: Feature Requests item #3613438, was opened at 2013-05-16 06:23 Message generated for change (Comment added) made by cyberpunkspike You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=3613438&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: 5 Private: No Submitted By: J?rgen Vigna (juergenvigna) Assigned to: Nobody/Anonymous (nobody) Summary: NTLM auth support for check_http Initial Comment: Hello, I've already seen various requests for this feature, but unfortunately it never was adopted. Now I'm using nagios-plugins-1.4.16 and wrote a patch for check_http/nagios-plugins which includes this (well I fixed an already existing patch I found somewhere, maybe here). The patch is quite clean and should not clash with check_http features also code is only added if NTLM Auth is activated on configure. I attach the patch if you're interested. ---------------------------------------------------------------------- Comment By: J.M. Becker - TechZilla (cyberpunkspike) Date: 2013-05-29 14:17 Message: check_http returned a socket timeout, when attempting an ntlm authentication. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=3613438&group_id=29880 From noreply at sourceforge.net Thu May 30 08:44:33 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 May 2013 23:44:33 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3571331 ] check_http converts semicolon to newline in -k Message-ID: Bugs item #3571331, was opened at 2012-09-24 14:14 Message generated for change (Settings changed) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&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: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: RudolfPotucekSmart (rpsmart) >Assigned to: Holger Weiss (hweiss) Summary: check_http converts semicolon to newline in -k Initial Comment: When trying to pass Accept: headers, which are supposed to contain semicolons, using the -k option then the semicolon is converted to a newline (verified using snapshot version 1.4.16-38-g4cdd on RHEL 6.3 and recording request using tcpdump: call: ./nagios-plugins-1.4.16-38-g4cdd/plugins/check_http -I obfuscated -H obfuscated -k 'Accept: application/json;charset=UTF-8' -u obfuscated tcpdump / wireshark: GET ofuscated HTTP/1.1 User-Agent: check_http/v1.4.16-38-g4cdd (nagios-plugins 1.4.16) Connection: close Host: obfuscated Accept: application/json charset=UTF-8 ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 13:53 Message: Hi, multiple -k options are already implemented in the current check_http. Using them you can define multiple HTTP header fields. Until now check_http wasn't able to handle semicolons (;) in an header field, due to the fact it split them up into multiple header fields. So after my patch the mentioned use of check_http (./nagios-plugins-1.4.16-38-g4cdd/plugins/check_http -I obfuscated -H obfuscated -k 'Accept: application/json;charset=UTF-8' -u obfuscated) will work (I've testes it, I swear^^), but you wouldn't be able to specify multiple Header fields in one -k option. Hope this describes it well. Otherwise just check the sources at https://github.com/nagios-plugins/nagios-plugins/pull/52/files or the help text of check_http. br, Richard ---------------------------------------------------------------------- Comment By: RudolfPotucekSmart (rpsmart) Date: 2013-05-29 09:36 Message: I think multiple -k options don't help because there is only ONE header called "Accept:" with a value of "application/json;charset=UTF-8" ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 06:06 Message: Hi, btw: I've opened a pull request for the removal of the semicolon input delimiter from the -k argument. br, Richard ---------------------------------------------------------------------- Comment By: Richard Leitner (g0hl1n) Date: 2013-05-29 05:32 Message: Hi, as far as I see in the check_http source the semicolon is used as delimiter for multiple header fields. So as the semicolon is a valid character in header fields this should be changed. Due to the fact multiple -k arguments could be passed I think such a delimiter isn't needed at all. Is there an other reason for this delimiter? br, Richard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3571331&group_id=29880