[Nagiosplug-devel] [ nagiosplug-Bugs-903461 ] check_nwstat generates ipv6 calls (error)
SourceForge.net
noreply at sourceforge.net
Tue Mar 21 19:48:02 CET 2006
Bugs item #903461, was opened at 2004-02-24 14:14
Message generated for change (Settings changed) made by faucon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=903461&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: Release (specify)
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Alex (faucon)
Assigned to: Nobody/Anonymous (nobody)
Summary: check_nwstat generates ipv6 calls (error)
Initial Comment:
Short story :
check_nwstat is doing 2 X AAAA request and 1 X A
request to my DNS server since version 1.3.99 (1.13).
Details and tests :
Linux server RedHat9. DNS server Netware
With check_nwstat v1.3.99 or more recent, my DNS server
is showing that my Nagios server is doing 2 X AAAA
request (ip6) and 1 X A request (ip4).
I tested with version 1.3.1 of the plugins, and there
is no problem there. (but features in latest release
are needed).
I tested with other plugins and with ping, and
everything is fine.
Here is a peace of the logs.
----------------------
***** QH_Proc: query received from 10.1.0.137
QH_ns_req: Query for (srv-ndps1.cslaval.qc.ca)
of type aaaa
Domain Name "srv-ndps1.cslaval.qc.ca" found in
authoritative cache zone "cslaval.qc.ca"
Send a UDP Reply to 10.1.0.137
***** QH_Proc: query received from 10.1.0.137
QH_ns_req: Query for (srv-educ1.cslaval.qc.ca)
of type aaaa
Domain Name "srv-educ1.cslaval.qc.ca" found in
authoritative cache zone "cslaval.qc.ca"
Send a UDP Reply to 10.1.0.137
***** QH_Proc: query received from 10.1.0.137
QH_ns_req: Query for (srv-sec1.cslaval.qc.ca) of
type aaaa
Domain Name "srv-sec1.cslaval.qc.ca" found in
authoritative cache zone "cslaval.qc.ca"
Send a UDP Reply to 10.1.0.137
***** QH_Proc: query received from 10.1.0.137
QH_ns_req: Query for (srv-ndps1.cslaval.qc.ca)
of type aaaa
Domain Name "srv-ndps1.cslaval.qc.ca" found in
authoritative cache zone "cslaval.qc.ca"
Send a UDP Reply to 10.1.0.137
***** QH_Proc: query received from 10.1.0.137
QH_ns_req: Query for (srv-educ1.cslaval.qc.ca)
of type a
Domain Name "srv-educ1.cslaval.qc.ca" found in
authoritative cache zone "cslaval.qc.ca"
Send a UDP Reply to 10.1.0.137
***** QH_Proc: query received from 10.1.0.137
QH_ns_req: Query for (srv-sec1.cslaval.qc.ca) of
type aaaa
Domain Name "srv-sec1.cslaval.qc.ca" found in
authoritative cache zone "cslaval.qc.ca"
Send a UDP Reply to 10.1.0.137
***** QH_Proc: query received from 10.1.0.137
QH_ns_req: Query for (srv-ndps1.cslaval.qc.ca)
of type a
Domain Name "srv-ndps1.cslaval.qc.ca" found in
authoritative cache zone "cslaval.qc.ca"
Send a UDP Reply to 10.1.0.137
***** QH_Proc: query received from 10.1.0.137
QH_ns_req: Query for (srv-sec1.cslaval.qc.ca) of
type a
Domain Name "srv-sec1.cslaval.qc.ca" found in
authoritative cache zone "cslaval.qc.ca"
Send a UDP Reply to 10.1.0.137
---------------------------------
----------------------------------------------------------------------
Comment By: Alex (faucon)
Date: 2006-03-22 03:46
Message:
Logged In: YES
user_id=706397
I got to repackage for an update to nagios v2, and one
work-around is to compile the plugins with the -no-ipv6
switch. Closing this request.
----------------------------------------------------------------------
Comment By: David Sullivan (sullivand)
Date: 2005-09-26 09:29
Message:
Logged In: YES
user_id=1348152
I've reproduced this with the latest CVS version of
check_nwstat.
A number of the plugins that connect to TCP services
directly without spawning another programme have this
"problem" though. I can demonstrate the same behaviour of
generating AAAA queries with check_smtp, check_imap and
check_ssh. check_ping probably wasn't the best plugin to
compare against since it executes another programme which
itself might not have IPV6 support.
The problem is an artifact of IPV6 support that it will try
and resolve both AAAA and A records for a hostname. The
possible fix is to modify check_nwstat to also have the -4
and -6 options as these other TCP plugins do. With the other
plugins listed above adding the -4 option when executing the
plugin eliminates these AAAA queries.
David.
----------------------------------------------------------------------
Comment By: M. Sean Finney (seanius)
Date: 2005-09-25 15:28
Message:
Logged In: YES
user_id=226838
hi faucon,
it's just been brought to my attention (in another bug
report) that there were some patches done recently (around
july or september)
to check_nwstat. as none of the developers have any access
to netware systems, could you take a try with the latest
version in cvs head?
----------------------------------------------------------------------
Comment By: Alex (faucon)
Date: 2005-05-02 14:54
Message:
Logged In: YES
user_id=706397
Hi seanius.
Nop, still does. With the latest 1.4 package of plugins.
Just tested 5 minutes ago :)
check_ping (nagios-plugins 1.3.99) 1.25
check_nwstat (nagios-plugins 1.3.99) 1.13
At the end of this message, you can see the logs of
ethereal. I made 3 pass for each tests. One with check_ping
and one with check_nwstat. Since all 3 pass are the same, I
just posted one of each. The thing is, with ping, everything
is fine, it sends A request to the DNS and then ping. But
with nwstat, it sends AAAA requests to the DNS before the A
request and then check_nwstat. In practice, this means more
stress for the DNS server. So the current workaround for
here, is that I use the "secondary" DNS server as the first
server, insted of the primary. If not, the primary is overload.
-ethereal capture (edited)-
(check_ping)
1.260597 10.200.60.160 -> 10.1.0.80 DNS Standard query
A server.domain.qc.ca
1.260921 10.1.0.80 -> 10.200.60.160 DNS Standard query
response A 10.200.1.20
1.264812 10.200.60.160 -> 10.1.0.80 DNS Standard query
A server.domain.qc.ca
1.266082 10.1.0.80 -> 10.200.60.160 DNS Standard query
response A 10.200.1.20
1.265547 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request
1.265723 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply
2.264552 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request
2.264726 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply
3.263560 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request
3.263707 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply
4.262556 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request
4.262723 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply
5.261575 10.200.60.160 -> 10.200.1.20 ICMP Echo (ping) request
5.261735 10.200.1.20 -> 10.200.60.160 ICMP Echo (ping) reply
(check nwstat)
23.476463 10.200.60.160 -> 10.1.0.80 DNS Standard query
AAAA server.domain.qc.ca
23.476734 10.1.0.80 -> 10.200.60.160 DNS Standard query
response
23.477294 10.200.60.160 -> 10.1.0.80 DNS Standard query
AAAA server.domain.qc.ca.domain.qc.ca
23.477576 10.1.0.80 -> 10.200.60.160 DNS Standard query
response, No such name
23.477911 10.200.60.160 -> 10.1.0.80 DNS Standard query
A srv-adm1.cslaval.qc.ca
23.478212 10.1.0.80 -> 10.200.60.160 DNS Standard query
response A 10.200.1.20
23.478799 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999
[SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=219178857
TSER=0 WS=0
23.478971 10.200.1.20 -> 10.200.60.160 TCP 9999 > 39763
[SYN, ACK] Seq=0 Ack=1 Win=6144 Len=0 MSS=1460 WS=0
23.479029 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999
[ACK] Seq=1 Ack=1 Win=5840 Len=0
23.540094 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999
[FIN, ACK] Seq=1 Ack=1 Win=5840 Len=0
23.540252 10.200.1.20 -> 10.200.60.160 TCP 9999 > 39763
[ACK] Seq=1 Ack=2 Win=6143 Len=0
23.540270 10.200.1.20 -> 10.200.60.160 TCP 9999 > 39763
[FIN, PSH, ACK] Seq=1 Ack=2 Win=6143 Len=0
23.540360 10.200.60.160 -> 10.200.1.20 TCP 39763 > 9999
[ACK] Seq=2 Ack=2 Win=5840 Len=0
----------------------------------------------------------------------
Comment By: M. Sean Finney (seanius)
Date: 2005-05-01 19:56
Message:
Logged In: YES
user_id=226838
any progress on this one? it's the oldest bug in the
tracker and i'm just trying to help keep a clean house :)
----------------------------------------------------------------------
Comment By: Alex (faucon)
Date: 2005-01-11 15:39
Message:
Logged In: YES
user_id=706397
Hi tonvoon,
Let me check it out. I'll download the latest cve and test it.
----------------------------------------------------------------------
Comment By: Ton Voon (tonvoon)
Date: 2005-01-01 16:35
Message:
Logged In: YES
user_id=664364
Unassigning from Karl, but not sure of current status of this bug. Is it
still an issue with the latest release?
----------------------------------------------------------------------
Comment By: Alex (faucon)
Date: 2004-03-01 16:42
Message:
Logged In: YES
user_id=706397
Hi kdebisschop,
I have tryed your check_nwstat of 2004-02-29.
I can compile it, I can run it, but there is no output.
And, on my dns, there is no dns request been made.
And here is the command call that I use. Any other variable
could be used. The output is working with 1.3.1 or 1.4.1alpha.
./check_nwstat -H srv-ndps1.cslaval.qc.ca -v ABENDS
The answer to this command is usually: "0 abended threads"
srv-ndps1 is an internal server. So you can't access it. But
I can make any tests you require. Thanks.
----------------------------------------------------------------------
Comment By: Karl DeBisschop (kdebisschop)
Date: 2004-02-29 04:18
Message:
Logged In: YES
user_id=1671
I may have found the cause - we were opening a new
connection for each attribute requested. I have rewritten
the code to open one connection and send repeatedly on tha
one connection. But I do not have any way to test it and I
do not know if the NW protocols allow it. Please test and
provide feedback.
----------------------------------------------------------------------
Comment By: Karl DeBisschop (kdebisschop)
Date: 2004-02-29 03:37
Message:
Logged In: YES
user_id=1671
Can you provide the service and command definitions that
create these multiple requests? I don't have access to a
test environment, but I'll be glad to look at the code and
see if I can find anything.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=903461&group_id=29880
More information about the Devel
mailing list