Hi Martin,
Here is the network trace.
The handshake is simply:
monit -> service TCP D=9000 S=46272 Syn Seq=88868940 Len=0 Win=49640
Options=<mss 1460,nop,wscale 0,nop,nop,sackOK>
service -> monit TCP D=46272 S=9000 Syn Ack=88868941 Seq=3633922578
Len=0 Win=49640 Options=<mss 1460,nop,wscale 0,nop,nop,sackOK>
monit -> service TCP D=9000 S=46272 Ack=3633922579 Seq=88868941 Len=0
Win=49640
monit -> service TCP D=9000 S=46272 Fin Ack=3633922579 Seq=88868941
Len=0 Win=49640
service -> monit TCP D=46272 S=9000 Ack=88868942 Seq=3633922579 Len=0
Win=49640
service -> monit TCP D=46272 S=9000 Fin Ack=88868942 Seq=3633922579
Len=0 Win=49640
monit -> service TCP D=9000 S=46272 Ack=3633922580 Seq=88868942 Len=0
Win=49640
Here is teh hex dump. Not sure why Solaris snoop is reporting that last ARP
packet BTW:
192.168.5.125 -> 192.168.5.124 TCP D=9000 S=46703 Syn Seq=725966152
Len=0 Win=49640 Options=<mss 1460,nop,wscale 0,nop,nop,sackOK>
0: 001e 6849 e444 0021 2800 8e9e 0800 4500 ..hI.D.!(.....E.
16: 0034 6ce0 4000 4006 419a c0a8 057d c0a8 .4l.@[email protected]....}..
32: 057c b66f 2328 2b45 5d48 0000 0000 8002 .|.o#(+E]H......
48: c1e8 bec0 0000 0204 05b4 0103 0300 0101 .?..............
64: 0402 ..
192.168.5.124 -> 192.168.5.125 TCP D=46703 S=9000 Syn Ack=725966153
Seq=113806676 Len=0 Win=49640 Options=<mss 1460,nop,wscale 0,nop,nop,sackOK>
0: 0021 2800 8e9e 001e 6849 e444 0800 4500 .!(.....hI.D..E.
16: 0034 fee6 4000 4006 0000 c0a8 057c c0a8 .4..@.@......|..
32: 057d 2328 b66f 06c8 8d54 2b45 5d49 8012 .}#(.o...T+E]I..
48: c1e8 8c70 0000 0204 05b4 0103 0300 0101 .?.p............
64: 0402 ..
192.168.5.125 -> 192.168.5.124 TCP D=9000 S=46703 Ack=113806677
Seq=725966153 Len=0 Win=49640
0: 001e 6849 e444 0021 2800 8e9e 0800 4500 ..hI.D.!(.....E.
16: 0028 6ce1 4000 4006 41a5 c0a8 057d c0a8 .(l.@[email protected]....}..
32: 057c b66f 2328 2b45 5d49 06c8 8d55 5010 .|.o#(+E]I...UP.
48: c1e8 6b5e 0000 0000 0000 0000 .?k^........
192.168.5.125 -> 192.168.5.124 TCP D=9000 S=46703 Fin Ack=113806677
Seq=725966153 Len=0 Win=49640
0: 001e 6849 e444 0021 2800 8e9e 0800 4500 ..hI.D.!(.....E.
16: 0028 6ce2 4000 4006 41a4 c0a8 057d c0a8 .(l.@[email protected]....}..
32: 057c b66f 2328 2b45 5d49 06c8 8d55 5011 .|.o#(+E]I...UP.
48: c1e8 6b5d 0000 0000 0000 0000 .?k]........
192.168.5.124 -> 192.168.5.125 TCP D=46703 S=9000 Ack=725966154
Seq=113806677 Len=0 Win=49640
0: 0021 2800 8e9e 001e 6849 e444 0800 4500 .!(.....hI.D..E.
16: 0028 fee7 4000 4006 0000 c0a8 057c c0a8 .(.?@.@......|..
32: 057d 2328 b66f 06c8 8d55 2b45 5d4a 5010 .}#(.o...U+E]JP.
48: c1e8 8c64 0000 .?.d..
192.168.5.124 -> 192.168.5.125 TCP D=46703 S=9000 Fin Ack=725966154
Seq=113806677 Len=0 Win=49640
0: 0021 2800 8e9e 001e 6849 e444 0800 4500 .!(.....hI.D..E.
16: 0028 fee8 4000 4006 0000 c0a8 057c c0a8 .(.?@.@......|..
32: 057d 2328 b66f 06c8 8d55 2b45 5d4a 5011 .}#(.o...U+E]JP.
48: c1e8 8c64 0000 .?.d..
192.168.5.125 -> 192.168.5.124 TCP D=9000 S=46703 Ack=113806678
Seq=725966154 Len=0 Win=49640
0: 001e 6849 e444 0021 2800 8e9e 0800 4500 ..hI.D.!(.....E.
16: 0028 6ce3 4000 4006 41a3 c0a8 057d c0a8 .(l.@[email protected]....}..
32: 057c b66f 2328 2b45 5d4a 06c8 8d56 5010 .|.o#(+E]J...VP.
48: c1e8 6b5c 0000 0000 0000 0000 .?k\........
192.168.5.125 -> 192.168.5.252 ARP R 192.168.5.125, 192.168.5.125 is
0:21:28:0:8e:9e
0: ffff ffff ffff 0021 2800 8e9e 0806 0001 .......!(.......
16: 0800 0604 0002 0021 2800 8e9e c0a8 057d .......!(......}
32: 0090 7f81 57bb c0a8 05fc 0000 0000 0000 ....W...........
48: 0000 0000 0000 0000 0000 0000 ............
Best regards,
- Nestor
On Thu, Jul 11, 2013 at 4:38 PM, Martin Pala <[email protected]> wrote:
> Hi,
>
> the TCP connection test with no protocol specified doesn't send anything
> to the connected socket - it just connects, then calls check_default()
> protocol which is dummy function that returns "true" and closes the socket.
> The UDP socket with no protocol defined writes to the socket, as there is
> no way how to test whether the connection is established, so it writes one
> byte to the socket and checks whether error will occur - if not, then the
> UDP socket is most probably up (in case of UDP test it's thus important to
> use the specific protocol option to make sure the port works, as the
> generic test is limited by UDP design).
>
> Please can you get network trace to see whether the data really come from
> Monit?
>
> Regards,
> Martin
>
>
> On Jul 11, 2013, at 5:43 PM, Nestor Urquiza <[email protected]>
> wrote:
>
> Hi guys,
>
> We monitor a provider server using the below:
>
> <code>
>
> check host genevastby.krfs.com with address 192.168.5.125
>
> if failed port 9000 type tcp with timeout 15 seconds
>
> then alert
>
> </code>
>
>
> However the provider logs are constantly complaining about socket
> failures. Detailed inspection allowed me to determine that the provider
> service actually does that when at least three characters are written to
> the socket so basically the below will make the server complaint:
>
> <code>
>
> exec 3<>/dev/tcp/${HOST}/${PORT}; echo -e "\n\n\n" >&3; exec 3>&
>
> </code>
>
> Any three characters will do really. If nothing is written to the port or
> less than three characters are written there will be no error messages.
>
>
> The question would be then if there is a way to tell monit not to write
> anything to the socket?
>
>
> Thanks!
>
> - Nestor
> --
> To unsubscribe:
> https://lists.nongnu.org/mailman/listinfo/monit-general
>
>
>
> --
> To unsubscribe:
> https://lists.nongnu.org/mailman/listinfo/monit-general
>
--
To unsubscribe:
https://lists.nongnu.org/mailman/listinfo/monit-general
