What does "In IP15 (invalid)" mean in tcpdump output? - networking

While trying to debug a networking issue about a non-reachable machine with tcpdump, I am seeing some "In IP?? (invalid)" in the output. Like this:
17:51:59.267768 vlan In IP15 (invalid)
17:51:59.267768 vlan.777 In IP (tos 0x0, ttl 63, id 435, offset 0, flags [DF], proto ICMP (1), length 84)
10.78.0.133 > 10.77.3.1: ICMP echo request, id 18428, seq 1, length 64
17:51:59.267811 vlan.777 Out IP (tos 0x0, ttl 64, id 36583, offset 0, flags [none], proto ICMP (1), length 84)
10.77.3.1 > 10.78.0.133: ICMP echo reply, id 18428, seq 1, length 64
17:51:59.267815 vlan Out IP bad-len 0
I've also seen IP11, IP14, in those invalid output lines. My search about them has resulted in zero results. Any idea what they are about?

Related

why some tcp packets doesn't have sequence number in tcpdump?

I have a redis server on my host(macOS), it's port is 6378, first I execute this command:
sudo tcpdump -vvvn -i lo0 port 6378
Then execute this in another tab
redis-cli -h 127.0.0.1 -p 6378
And here is the results from tcpdump after redis-cli connected to redis-server
21:29:05.866610 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64, bad cksum 0 (->3cb6)!)
127.0.0.1.64020 > 127.0.0.1.6378: Flags [S], cksum 0xfe34 (incorrect -> 0xf8d2), seq 1870296365, win 65535, options [mss 16344,nop,wscale 6,nop,nop,TS val 3029686726 ecr 0,sackOK,eol], length 0
21:29:05.866682 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64, bad cksum 0 (->3cb6)!)
127.0.0.1.6378 > 127.0.0.1.64020: Flags [S.], cksum 0xfe34 (incorrect -> 0x4dad), seq 3099403233, ack 1870296366, win 65535, options [mss 16344,nop,wscale 6,nop,nop,TS val 962237723 ecr 3029686726,sackOK,eol], length 0
21:29:05.866693 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
127.0.0.1.64020 > 127.0.0.1.6378: Flags [.], cksum 0xfe28 (incorrect -> 0xaeb6), seq 1, ack 1, win 6379, options [nop,nop,TS val 3029686726 ecr 962237723], length 0
21:29:05.866701 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
127.0.0.1.6378 > 127.0.0.1.64020: Flags [.], cksum 0xfe28 (incorrect -> 0xaeb6), seq 1, ack 1, win 6379, options [nop,nop,TS val 962237723 ecr 3029686726], length 0
21:29:05.866949 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 69, bad cksum 0 (->3cb1)!)
127.0.0.1.64020 > 127.0.0.1.6378: Flags [P.], cksum 0xfe39 (incorrect -> 0x2629), seq 1:18, ack 1, win 6379, options [nop,nop,TS val 3029686726 ecr 962237723], length 17
21:29:05.866967 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
127.0.0.1.6378 > 127.0.0.1.64020: Flags [.], cksum 0xfe28 (incorrect -> 0xaea5), seq 1, ack 18, win 6379, options [nop,nop,TS val 962237723 ecr 3029686726], length 0
21:29:05.907727 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 86, bad cksum 0 (->3ca0)!)
127.0.0.1.6378 > 127.0.0.1.64020: Flags [P.], cksum 0xfe4a (incorrect -> 0xde76), seq 1:35, ack 18, win 6379, options [nop,nop,TS val 962237762 ecr 3029686726], length 34
21:29:05.907757 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
127.0.0.1.64020 > 127.0.0.1.6378: Flags [.], cksum 0xfe28 (incorrect -> 0xae35), seq 18, ack 35, win 6379, options [nop,nop,TS val 3029686765 ecr 962237762], length 0
But in wireshark, it has a sequence number
And from here we can know that every packet of TCP must have a 32bit "Sequence Number", so, should I add some args to tcpdump so it can show the seq number of lines that has Flags [.]?

According to the Transmission_Control_Protocol on Wikipedia:
Sequence number (32 bits)
Has a dual role:
If the SYN flag is set (1), then this is the initial sequence number. The sequence number of the actual first data byte and the acknowledged number in the corresponding ACK are then this sequence number plus 1.
If the SYN flag is clear (0), then this is the accumulated sequence number of the first data byte of this segment for the current session.
And according to the Stevens's TCP IP Illustrated, Volume 1:
Every TCP segment (except those exchanged during connection establishment)
includes a valid Sequence Number field, an ACK Number or Acknowledgment field, and a Window Size field (containing the window advertisement).
Now let's construct a scenario and use tcpdump to trace the tcp segments:
Initialize a HTTP (i.e. TCP) request with curl:
$ curl -iIL https://blog.codefarm.me/
HTTP/2 200
server: GitHub.com
.....
Meanwhile, executing tcpdump and write the dump date to a file as below:
tcpdump -n port 443 -r /tmp/https.pcap
Reading the dump data with the following command:
$ tcpdump --number -ntS port 443 -r /tmp/https.pcap
reading from file /tmp/https.pcap, link-type EN10MB (Ethernet), snapshot length 262144
1 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [S], seq 2427498844, win 64240, options [mss 1460,sackOK,TS val 2733586448 ecr 0,nop,wscale 7], length 0
2 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [S.], seq 1574645920, ack 2427498845, win 64240, options [mss 1460], length 0
3 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [.], ack 1574645921, win 64240, length 0
4 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427498845:2427499362, ack 1574645921, win 64240, length 517
5 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499362, win 64240, length 0
6 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [P.], seq 1574645921:1574650508, ack 2427499362, win 64240, length 4587
7 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [.], ack 1574650508, win 61320, length 0
8 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499362:2427499442, ack 1574650508, win 62780, length 80
9 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499442:2427499488, ack 1574650508, win 62780, length 46
10 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499488:2427499537, ack 1574650508, win 62780, length 49
11 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499442, win 64240, length 0
12 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499488, win 64240, length 0
13 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499537, win 64240, length 0
14 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499537:2427499640, ack 1574650508, win 62780, length 103
15 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499640, win 64240, length 0
16 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [P.], seq 1574650508:1574651050, ack 2427499640, win 64240, length 542
17 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [P.], seq 1574651050:1574651109, ack 2427499640, win 64240, length 59
18 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [.], ack 1574651109, win 62780, length 0
19 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499640:2427499671, ack 1574651109, win 62780, length 31
20 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499671, win 64240, length 0
21 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [P.], seq 1574651109:1574651502, ack 2427499671, win 64240, length 393
22 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [P.], seq 2427499671:2427499695, ack 1574651502, win 62780, length 24
23 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499695, win 64240, length 0
24 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [F.], seq 2427499695, ack 1574651502, win 62780, length 0
25 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499696, win 64239, length 0
26 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [FP.], seq 1574651502:1574651526, ack 2427499696, win 64239, length 24
27 IP 192.168.91.128.32868 > 185.199.108.153.443: Flags [R], seq 2427499696, win 0, length 0
The packets at the line 11-13 are all ACK segments without palyload. And tcpdump also doesn't show the seq field which is should be 1574650508 as the last sending segment with payload from server (i.e. packet 6 at line number 6).
Why?
Now let's run tcpdump with the following options:
$ tcpdump --number -ntSxx port 443 -r /tmp/https.pcap
.....
6 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [P.], seq 1574645921:1574650508, ack 2427499362, win 64240, length 4587
.....
11 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499442, win 64240, length 0
0x0000: 000c 298c df3f 0050 56e9 f627 0800 4500
0x0010: 0028 5a0e 0000 8006 9e38 b9c7 6c99 c0a8
0x0020: 5b80 01bb 8064 5ddb 428c 90b0 b3b2 5010
0x0030: faf0 0b70 0000 0000 0000 0000
12 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499488, win 64240, length 0
0x0000: 000c 298c df3f 0050 56e9 f627 0800 4500
0x0010: 0028 5a0f 0000 8006 9e37 b9c7 6c99 c0a8
0x0020: 5b80 01bb 8064 5ddb 428c 90b0 b3e0 5010
0x0030: faf0 0b42 0000 0000 0000 0000
13 IP 185.199.108.153.443 > 192.168.91.128.32868: Flags [.], ack 2427499537, win 64240, length 0
0x0000: 000c 298c df3f 0050 56e9 f627 0800 4500
0x0010: 0028 5a10 0000 8006 9e36 b9c7 6c99 c0a8
0x0020: 5b80 01bb 8064 5ddb 428c 90b0 b411 5010
0x0030: faf0 0b11 0000 0000 0000 0000
.....
Actually, with the xx option, we can analyze the 32bit sequence number (i.e. 5ddb 428c) of the above TCP segments (11-13) and convert it to decimal number as below:
$ echo $((16#5ddb428c))
1574650508
Here, we can see the sequence number that repeated in ACK segment three times is 1574650508 which is same as the WireShark (with absolute sequence number option).

Asterisk 13.10.0 does not detect user input. DTMF not working

I am trying to get user input from a phone dialpad but it is not working. Seems DTMF is not working
[general]
;context=unauthenticated
context=callingout
type=peer
;host=dynamic
allowguest=yes
alwaysauthreject=yes
srvlookup=yes
udpbindaddr=0.0.0.0
tcpenable=no
;port=5038
match_auth_username=yes
;alwaysauthreject=no
allowoverlap=no
allowtransfer=no
canreinvite=no
disallow=all
allow=g729
allow=ulaw
allow=alaw
;allow=gsm
; allow=all
directmedia=no
;nat=force_rport,comedia
nat=yes
externip=xx.xx.xx.xx
;localnet=192.168.0.3/255.255.0.0
;allow=speex
dtmfmode=rfc2833
qualify=yes
[callingout]
srvlookup=no
udpbindaddr=0.0.0.0
type=friend
host=xx.xx.xx.xx
;host=dynamic
context=callingout
canreinvite=no
disallow=all
allow=g729
allow=ulaw
allow=alaw
dtmfmode=rfc2833
extenip=xx.xx.xx.xx
nat=yes
qualify=yes
[plan]
srvlookup=no
udpbindaddr=0.0.0.0
type=friend
host=xx.xx.xx.xx
;host=dynamic
context=callingout
canreinvite=no
disallow=all
allow=g729
allow=ulaw
allow=alaw
dtmfmode=rfc2833
extenip=xx.xx.xx.xx
nat=yes
qualify=yes
[gateway-default] ; call is routed to this server IP
type=peer
insecure=invite,port
nat=no
directmedia=no
host=xx.xx.xx.xx
;context=callingout
disallow=all
allow=g729
allow=ulaw
allow=alaw
dtmfmode=rfc2833
I tried getting user input using Read statement in the dialplan
same => n,Read(pin_entered,/var/lib/asterisk/sounds/es/enter_PIN,4,i,1,5)
But I get the following output when I set sip and rtp debug on
-- Accepting a maximum of 4 digits.
Audio is at 17380
Adding codec g729 to SDP
Adding codec ulaw to SDP
Adding codec alaw to SDP
<--- Reliably Transmitting (NAT) to 46.19.209.14:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 46.19.209.14;branch=z9hG4bK6vxvLaBc;received=46.19.209.14;rport =5060
From: 16173730982 <sip:16173730982#46.19.209.14>;tag=3B8DECC2-58A132ED0008B979-D 29D1700
To: <sip:17818100188#xx.xx.xx.xx:5060>;tag=as6ad8c2be
Call-ID: 16-471011CE-58A132ED0008BA04-D29D1700
CSeq: 10 INVITE
Server: Asterisk PBX 13.10.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLIS H, MESSAGE
Supported: replaces, timer
Contact: <sip:17818100188#xx.xx.xx.xx:5060>
Content-Type: application/sdp
Content-Length: 269
v=0
o=root 876537524 876537524 IN IP4 xx.xx.xx.xx
s=Asterisk PBX 13.10.0
c=IN IP4 xx.xx.xx.xx
t=0 0
m=audio 17380 RTP/AVP 18 0 8
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:150
a=sendrecv
<------------>
<--- SIP read from UDP:46.19.209.14:5060 --->
ACK sip:17818100188#xx.xx.xx.xx:5060 SIP/2.0
Via: SIP/2.0/UDP 46.19.209.14;branch=z9hG4bKtk4jVaWe;rport
From: 16173730982 <sip:16173730982#46.19.209.14>;tag=3B8DECC2-58A132ED0008B979-D 29D1700
To: <sip:17818100188#xx.xx.xx.xx:5060>;tag=as6ad8c2be
CSeq: 10 ACK
Call-ID: 16-471011CE-58A132ED0008BA04-D29D1700
Contact: <sip:46.19.209.14:5060>
Max-Forwards: 70
Content-Length: 0
<------------->
-- <SIP/46.19.209.14-0000023b> Playing '/var/lib/asterisk/sounds/es/enter_PI N.slin' (language 'es')
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027986, ts 000320, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027987, ts 000480, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027988, ts 000640, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027989, ts 000800, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027990, ts 000960, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027991, ts 001120, len 000020)
> 0x7fb8f0019460 -- Probation passed - setting RTP source address to 46.1 9.209.79:51054
Got RTP packet from 46.19.209.79:51054 (type 18, seq 021627, ts 2308319632, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027992, ts 001280, len 000020)
Got RTP packet from 46.19.209.79:51054 (type 18, seq 021628, ts 2308319792, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027993, ts 001440, len 000020)
Got RTP packet from 46.19.209.79:51054 (type 18, seq 021629, ts 2308319952, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027994, ts 001600, len 000020)
Got RTP packet from 46.19.209.79:51054 (type 18, seq 021630, ts 2308320112, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027995, ts 001760, len 000020)
Got RTP packet from 46.19.209.79:51054 (type 18, seq 021631, ts 2308320272, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027996, ts 001920, len 000020)
Got RTP packet from 46.19.209.79:51054 (type 18, seq 021632, ts 2308320432, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027997, ts 002080, len 000020)
Got RTP packet from 46.19.209.79:51054 (type 18, seq 021633, ts 2308320592, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027998, ts 002240, len 000020)
Got RTP packet from 46.19.209.79:51054 (type 18, seq 021634, ts 2308320752, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 027999, ts 002400, len 000020)
Got RTP packet from 46.19.209.79:51054 (type 18, seq 021635, ts 2308320912, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 028000, ts 002560, len 000020)
Got RTP packet from 46.19.209.79:51054 (type 18, seq 021636, ts 2308321072, len 000020)
Sent RTP packet to 46.19.209.79:51054 (type 18, seq 028001, ts 002720, len 000020)

I would recommend to switch to SIP INFO dtmf mode (set this both on your SIP client and in Asterisk "dtmfmode").
Then you will be able to see the DTMF messages clearly in the SIP signaling.

Why TCPDUMP shows Ethernet packet when querying TCP packet?

I am using TCPDUMP to intercept the network traffic on an Android device.
The command I use is
./tcpdump -tt -nn -vv tcp > tcp.log
In the result file (tcp.log), I found that there are not only TCP packets, but also some others with Ethernet address. (Some IP and Ethernet addresses are obfuscated due to privacy purpose).
1410451676.980763 IP (tos 0x0, ttl 41, id 0, offset 0, flags [DF], proto TCP (6), length 60)
54.204.ABC.144.80 > 172.31.DEF.178.59949: Flags [S.], seq 572870324, ack 3778403975, win 17898, options [mss 1380,sackOK,TS[|tcp]>
1410451676.980916 IP (tos 0x0, ttl 64, id 44656, offset 0, flags [DF], proto TCP (6), length 52)
172.31.DEF.178.59949 > 54.204.ABC.144.80: Flags [.], seq 1, ack 1, win 1369, options [nop,nop,TS[|tcp]>
1410451676.982167 IP (tos 0x0, ttl 64, id 44657, offset 0, flags [DF], proto TCP (6), length 701)
172.31.DEF.178.59949 > 54.204.ABC.144.80: Flags [P.], seq 1:650, ack 1, win 1369, options [nop,nop,TS[|tcp]>
1410451676.996114 00:24:f9:c3:XX:00 > d8:50:e6:2b:YY:6a, ethertype IPv6 (0x86dd), length 86:
0x0000: 6000 0000 0020 0634 2607 f8b0 400d 0c03 `......4&...#...
0x0010: 0000 0000 0000 00bc 2001 0468 0c80 4340 ...........h..C#
0x0020: b040 b100 7831 4228 146c c1cc ceb8 fc7a .#..x1B(.l.....z
1410451677.000783 00:24:f9:c3:XX:00 > d8:50:e6:2b:YY:6a, ethertype IPv6 (0x86dd), length 535:
0x0000: 6000 0000 01e1 0634 2607 f8b0 400d 0c03 `......4&...#...
0x0010: 0000 0000 0000 00bc 2001 0468 0c80 4340 ...........h..C#
0x0020: b040 b100 7831 4228 146c c1cc ceb8 fc7a .#..x1B(.l.....z
1410451677.000935 d8:50:e6:2b:YY:6a > 00:24:f9:c3:XX:00, ethertype IPv6 (0x86dd), length 86:
0x0000: 6000 0000 0020 0640 2001 0468 0c80 4340 `......#...h..C#
0x0010: b040 b100 7831 4228 2607 f8b0 400d 0c03 .#..x1B(&...#...
0x0020: 0000 0000 0000 00bc c1cc 146c 3b74 2fa9 ...........l;t/.
1410451677.011006 IP (tos 0x0, ttl 41, id 62137, offset 0, flags [DF], proto TCP (6), length 52)
54.204.ABC.144.80 > 172.31.DEF.178.59949: Flags [.], seq 1, ack 650, win 75, options [nop,nop,TS[|tcp]>
In a regular TCP packet header, the result includes its timestamp (UNIX time), IP packet flag+options, source IP address+port, destination IP address+port, and TCP flags.
BUT, what I do not understand is that there are some Ethernet packets in between and according to the results, these packets include their MAC address, instead of IP address.
Why is the case? Are they TCP packets?
Thanks for your answers/insights.

All those packets are Ethernet packets.
The version of tcpdump you're using was apparently not built with IPv6 support, so, while it can recognize IPv4-over-Ethernet packets and printout the IP information, it can't recognize IPv6-over-Ethernet packets, and just prints out the Ethernet-layer information.
You should ask whoever built that version of tcpdump why it doesn't include IPv6 support.

Network with vlans, tcpdump show connections and icmp replies and requests, but ping not received

I have network with switches which have set pvid on every port on every switch to 1.
Server is on linux debian with authoritative dhcp.
Some of ip addresses do not have access to gateway. I dont know what is blocking: switches or gateway.
The most strange thing is that on ping request, gateway receive it and answer on it. Client also send request and receive answer, but ping program does not show replies. I checked replies with tcpdump:
Client tcpdump:
18:18:20.283614 ARP, Request who-has 192.168.0.102 tell 192.168.1.1, length 46
18:18:21.135348 IP kicok-K53SJ > 192.168.1.1: ICMP echo request, id 6937, seq 46, length 64
18:18:43.766916 ARP, Request who-has 192.168.0.101 tell 192.168.1.1, length 46
18:18:44.135326 IP kicok-K53SJ > 192.168.1.1: ICMP echo request, id 6937, seq 69, length 64
18:18:44.164008 IP 192.168.1.1 > kicok-K53SJ: ICMP echo reply, id 6937, seq 69, length 64
18:18:44.238354 ARP, Request who-has 192.168.1.1 tell 192.168.0.234, length 46
18:18:44.618056 ARP, Request who-has 192.168.0.102 tell 192.168.1.1, length 46
18:19:09.135332 IP kicok-K53SJ > 192.168.1.1: ICMP echo request, id 6937, seq 94, length 64
18:19:09.139740 IP 192.168.1.1 > kicok-K53SJ: ICMP echo reply, id 6937, seq 94, length 64
18:19:09.332947 ARP, Request who-has 192.168.0.102 tell 192.168.1.1, length 46
18:19:10.135329 IP kicok-K53SJ > 192.168.1.1: ICMP echo request, id 6937, seq 95, length 64
18:19:10.137030 IP 192.168.1.1 > kicok-K53SJ: ICMP echo reply, id 6937, seq 95, length 64
18:19:11.135345 IP kicok-K53SJ > 192.168.1.1: ICMP echo request, id 6937, seq 96, length 64
18:19:33.771534 ARP, Request who-has 192.168.0.101 tell 192.168.1.1, length 46
18:19:34.121969 ARP, Request who-has 192.168.1.1 tell 192.168.0.55, length 46
18:19:34.135323 IP kicok-K53SJ > 192.168.1.1: ICMP echo request, id 6937, seq 119, length 64
18:19:34.139833 IP 192.168.1.1 > kicok-K53SJ: ICMP echo reply, id 6937, seq 119, length 64
18:19:34.218611 ARP, Request who-has 192.168.0.102 tell 192.168.1.1, length 46
18:19:34.771301 ARP, Request who-has 192.168.0.101 tell 192.168.1.1, length 46
18:19:35.135326 IP kicok-K53SJ > 192.168.1.1: ICMP echo request, id 6937, seq 120, length 64
18:19:58.969345 ARP, Request who-has 192.168.0.102 tell 192.168.1.1, length 46
18:19:59.135327 IP kicok-K53SJ > 192.168.1.1: ICMP echo request, id 6937, seq 144, length 64
18:19:59.143169 IP 192.168.1.1 > kicok-K53SJ: ICMP echo reply, id 6937, seq 144, length 64
18:18:36.955859 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 60, length 64
18:18:37.950910 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 61, length 64
18:18:37.955877 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 61, length 64
18:18:38.950981 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 62, length 64
18:18:38.956643 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 62, length 64
18:18:39.951068 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 63, length 64
18:18:39.956960 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 63, length 64
18:18:40.583070 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 101.0.168.192.in-addr.arpa. (44)
18:18:40.951113 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 64, length 64
18:18:40.969777 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 64, length 64
18:18:41.584863 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 101.0.168.192.in-addr.arpa. (44)
18:18:41.951164 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 65, length 64
18:18:41.965874 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 65, length 64
18:18:42.951232 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 66, length 64
18:18:42.957989 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 66, length 64
18:18:43.587702 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 101.0.168.192.in-addr.arpa. (44)
18:18:43.951288 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 67, length 64
18:18:43.978219 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 67, length 64
18:18:44.951377 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 68, length 64
18:18:44.980280 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 68, length 64
18:18:45.485589 IP 192.168.1.133.60758 > xxx.pl.domain: 57978+ PTR? 210.0.168.192.in-addr.arpa. (44)
18:18:45.490642 IP xxx.pl.domain > 192.168.1.133.60758: 57978 NXDomain 0/1/0 (115)
18:18:45.951413 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 69, length 64
18:18:45.979881 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 69, length 64
18:18:46.951478 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 70, length 64
18:18:46.972661 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 70, length 64
18:18:47.951557 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 71, length 64
18:18:47.982161 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 71, length 64
18:18:48.951626 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 72, length 64
18:18:48.977249 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 72, length 64
18:18:49.951717 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 73, length 64
18:18:49.953255 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 73, length 64
18:18:50.491068 IP 192.168.1.133.43288 > dns.xxx.pl.domain: 57978+ PTR? 210.0.168.192.in-addr.arpa. (44)
18:18:50.566751 IP dns.xxx.pl.domain > 192.168.1.133.43288: 57978 NXDomain 0/1/0 (115)
18:18:50.951760 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 74, length 64
18:18:50.953278 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 74, length 64
18:18:51.951802 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 75, length 64
18:18:51.960164 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 75, length 64
18:18:52.951854 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 76, length 64
18:18:52.953091 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 76, length 64
18:18:53.951879 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 77, length 64
18:18:53.953604 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 77, length 64
18:18:54.951972 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 78, length 64
18:18:54.954378 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 78, length 64
18:18:55.496499 IP 192.168.1.133.60758 > xxx.xxx.pl.domain: 57978+ PTR? 210.0.168.192.in-addr.arpa. (44)
18:18:55.501014 IP xxx.pl.domain > 192.168.1.133.60758: 57978 NXDomain 0/1/0 (115)
18:18:55.951978 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 79, length 64
18:18:55.956163 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 79, length 64
18:18:56.952149 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 80, length 64
18:18:56.960399 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 80, length 64
18:18:57.952172 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 81, length 64
18:18:57.952201 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 81, length 64
18:18:58.952182 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 82, length 64
18:18:58.952203 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 82, length 64
18:18:59.952278 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 83, length 64
18:18:59.958884 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 83, length 64
18:19:00.501918 IP 192.168.1.133.43288 > xxx.pl.domain: 57978+ PTR? 210.0.168.192.in-addr.arpa. (44)
18:19:00.507208 IP dns.xxx.pl.domain > 192.168.1.133.43288: 57978 NXDomain 0/1/0 (115)
18:19:00.952422 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 84, length 64
18:19:00.955510 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 84, length 64
18:19:01.952401 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 85, length 64
18:19:01.952870 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 85, length 64
18:19:02.952495 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 86, length 64
18:19:02.953525 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 86, length 64
18:19:03.952538 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 87, length 64
18:19:03.952904 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 87, length 64
18:19:04.952573 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 88, length 64
18:19:04.953364 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 88, length 64
18:19:05.608089 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 210.0.168.192.in-addr.arpa. (44)
18:19:05.952649 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 89, length 64
18:19:05.952904 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 89, length 64
18:19:06.609875 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 210.0.168.192.in-addr.arpa. (44)
18:19:06.952744 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 90, length 64
18:19:06.953540 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 90, length 64
18:19:07.952727 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 91, length 64
18:19:07.953864 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 91, length 64
18:19:08.612728 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 210.0.168.192.in-addr.arpa. (44)
18:19:08.952852 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 92, length 64
18:19:08.954535 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 92, length 64
18:19:09.952912 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 93, length 64
18:19:09.953297 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 93, length 64
18:19:10.510580 IP 192.168.1.133.35953 > xxx.pl.domain: 64751+ PTR? 155.0.168.192.in-addr.arpa. (44)
18:19:10.518416 IP xxx.pl.domain > 192.168.1.133.35953: 64751 NXDomain 0/1/0 (115)
18:19:10.952931 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 94, length 64
18:19:10.957117 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 94, length 64
18:19:11.953017 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 95, length 64
18:19:11.954464 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 95, length 64
18:19:12.953078 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 96, length 64
18:19:12.957269 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 96, length 64
18:19:13.953118 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 97, length 64
18:19:13.956323 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 97, length 64
18:19:14.953260 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 98, length 64
18:19:14.954302 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 98, length 64
18:19:15.516043 IP 192.168.1.133.55284 > dns.xxx.pl.domain: 64751+ PTR? 155.0.168.192.in-addr.arpa. (44)
18:19:15.591622 IP dns.xxx.pl.domain > 192.168.1.133.55284: 64751 NXDomain 0/1/0 (115)
18:19:15.953235 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 99, length 64
18:19:15.953812 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 99, length 64
18:19:16.953311 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 100, length 64
18:19:16.955149 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 100, length 64
18:19:17.953353 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 101, length 64
18:19:17.957049 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 101, length 64
18:19:18.953643 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 102, length 64
18:19:18.954942 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 102, length 64
18:19:18.964016 ARP, Request who-has 192.168.1.1 tell 192.168.1.133, length 46
18:19:18.964654 ARP, Reply 192.168.1.1 is-at 44:1e:a1:3d:e3:36 (oui Unknown), length 28
18:19:19.953499 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 103, length 64
18:19:19.954509 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 103, length 64
18:19:20.521712 IP 192.168.1.133.35953 > xxx.pl.domain: 64751+ PTR? 155.0.168.192.in-addr.arpa. (44)
18:19:20.524172 IP xxx.pl.domain > 192.168.1.133.35953: 64751 NXDomain 0/1/0 (115)
18:19:20.953602 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 104, length 64
18:19:20.953625 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 104, length 64
18:19:21.953619 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 105, length 64
18:19:21.955911 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 105, length 64
18:19:22.953700 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 106, length 64
18:19:22.953724 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 106, length 64
18:19:23.953721 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 107, length 64
18:19:23.954634 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 107, length 64
18:19:24.953837 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 108, length 64
18:19:24.955166 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 108, length 64
18:19:25.526973 IP 192.168.1.133.55284 > dns.xxx.pl.domain: 64751+ PTR? 155.0.168.192.in-addr.arpa. (44)
18:19:25.527718 IP dns.xxx.pl.domain > 192.168.1.133.55284: 64751 NXDomain 0/1/0 (115)
18:19:25.953872 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 109, length 64
18:19:25.954173 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 109, length 64
18:19:26.953926 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 110, length 64
18:19:26.954283 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 110, length 64
18:19:27.953975 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 111, length 64
18:19:27.954940 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 111, length 64
18:19:28.954047 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 112, length 64
18:19:28.954219 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 112, length 64
18:19:29.954161 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 113, length 64
18:19:29.956431 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 113, length 64
18:19:30.633106 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 155.0.168.192.in-addr.arpa. (44)
18:19:30.954208 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 114, length 64
18:19:30.954535 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 114, length 64
18:19:31.634965 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 155.0.168.192.in-addr.arpa. (44)
18:19:31.954242 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 115, length 64
18:19:31.956892 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 115, length 64
18:19:32.954308 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 116, length 64
18:19:32.954323 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 116, length 64
18:19:33.637792 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 155.0.168.192.in-addr.arpa. (44)
18:19:33.954386 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 117, length 64
18:19:33.955436 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 117, length 64
18:19:34.954469 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 118, length 64
18:19:34.956300 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 118, length 64
18:19:35.535640 IP 192.168.1.133.49359 > xxx.pl.domain: 25834+ PTR? 109.1.168.192.in-addr.arpa. (44)
18:19:35.540854 IP xxx.pl.domain > 192.168.1.133.49359: 25834 NXDomain 0/1/0 (115)
18:19:35.954492 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 119, length 64
18:19:35.958736 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 119, length 64
18:19:36.954570 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 120, length 64
18:19:36.957627 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 120, length 64
18:19:37.954587 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 121, length 64
18:19:37.957188 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 121, length 64
18:19:38.954707 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 122, length 64
18:19:38.954731 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 122, length 64
18:19:39.954721 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 123, length 64
18:19:39.958968 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 123, length 64
18:19:40.541158 IP 192.168.1.133.51285 > dns.xxx.pl.domain: 25834+ PTR? 109.1.168.192.in-addr.arpa. (44)
18:19:40.617464 IP dns.xxx.pl.domain > 192.168.1.133.51285: 25834 NXDomain 0/1/0 (115)
18:19:40.954839 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 124, length 64
18:19:40.955927 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 124, length 64
18:19:41.954885 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 125, length 64
18:19:41.956015 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 125, length 64
18:19:42.954885 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 126, length 64
18:19:42.954908 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 126, length 64
18:19:43.954963 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 127, length 64
18:19:43.957784 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 127, length 64
18:19:44.955045 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 128, length 64
18:19:44.958610 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 128, length 64
18:19:45.546565 IP 192.168.1.133.49359 > xxx.pl.domain: 25834+ PTR? 109.1.168.192.in-addr.arpa. (44)
18:19:45.547949 IP xxx.pl.domain > 192.168.1.133.49359: 25834 NXDomain 0/1/0 (115)
18:19:45.955110 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 129, length 64
18:19:45.956237 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 129, length 64
18:19:46.955326 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 130, length 64
18:19:46.961571 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 130, length 64
18:19:47.955220 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 131, length 64
18:19:47.955244 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 131, length 64
18:19:48.955309 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 132, length 64
18:19:48.955332 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 132, length 64
18:19:49.955391 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 133, length 64
18:19:49.963315 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 133, length 64
18:19:50.552030 IP 192.168.1.133.51285 > dns.xxx.pl.domain: 25834+ PTR? 109.1.168.192.in-addr.arpa. (44)
18:19:50.558578 IP dns.xxx.pl.domain > 192.168.1.133.51285: 25834 NXDomain 0/1/0 (115)
18:19:50.955424 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 134, length 64
18:19:50.958131 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 134, length 64
18:19:51.955457 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 135, length 64
18:19:51.956353 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 135, length 64
18:19:52.955532 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 136, length 64
18:19:52.956103 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 136, length 64
18:19:53.955572 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 137, length 64
18:19:53.962819 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 137, length 64
18:19:54.955635 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 138, length 64
18:19:54.965442 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 138, length 64
18:19:55.658235 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 109.1.168.192.in-addr.arpa. (44)
18:19:55.955686 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 139, length 64
18:19:55.956405 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 139, length 64
18:19:56.659989 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 109.1.168.192.in-addr.arpa. (44)
18:19:56.955766 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 140, length 64
18:19:56.959140 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 140, length 64
18:19:57.955818 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 141, length 64
18:19:57.955832 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 141, length 64
18:19:57.966401 ARP, Request who-has 192.168.1.1 tell 192.168.1.133, length 46
18:19:57.966407 ARP, Reply 192.168.1.1 is-at 44:1e:a1:3d:e3:36 (oui Unknown), length 28
18:19:58.662824 IP 192.168.1.133.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 109.1.168.192.in-addr.arpa. (44)
18:19:58.955878 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 142, length 64
18:19:58.959587 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 142, length 64
18:19:59.955935 IP 192.168.1.133 > 192.168.1.1: ICMP echo request, id 6937, seq 143, length 64
18:19:59.958454 IP 192.168.1.1 > 192.168.1.133: ICMP echo reply, id 6937, seq 143, length 64
18:20:00.560680 IP 192.168.1.133.34705 > xxx.pl.domain: 22360+ PTR? 219.0.168.192.in-addr.arpa. (44)
In this log we can see that server sends reply to client, and client receive some of them, but ping program dont show any answers. When i change client ip address to one from working addresses, it pings gateway and everything is ok. I have half random addresses which dont work and i dont know how to recognize them and find out why they dont work.

I have resolved my problem. It was old /etc/ethers file without write access and with very old entries.

Need some help interpreting tcpdump output

I've checked the tcpdump man page and thought I understood the example provided there. But the one that I am getting is something I'm not able to understand completely.
ORIGINAL: Simulator Output
LINE 1: 20:01:13.442111 IP 10.0.0.1.12345 > 10.0.0.2.54321: S 1234:1234(0) win 65535
LINE 2: 20:01:13.471705 IP 10.0.0.2.54321 > 10.0.0.1.12345: S 4321:4321(0) ack 1235 win 65535
LINE 3: 20:01:13.497389 IP 10.0.0.1.14640 > 10.0.0.2.12756: . ack 4322 win 65535
LINE 4: 20:01:13.497422 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 1235:2682(1447) win 65535
LINE 5: 20:01:14.023273 IP 10.0.0.2.12756 > 10.0.0.1.14640: . ack 5768 win 65535
This is what I understand:
LINE 1: 1 sends 2 0 bytes starting with SEQ number 1234
LINE 2: 2 sends 1 0 bytes starting with SEQ number 4321 and an ACK = (1's SEQ + 1) i.e. 1235
LINE 3: 1 sends 2 0 bytes with an ACK = (2's SEQ + 1) i.e. 4322
LINE 4: 1 sends 2 1447 bytes starting with SEQ number 1235 until 2682 (1447 bytes in total)
LINE 5: 2 sends 1 0 bytes with an ACK = 5768? What is this number? Isn't it supposed to be 2683?
Maybe I am missing something too obvious. Can someone point it out please?
EDIT 1: Simulator output (grepped one connection info)
20:01:13.442111 IP 10.0.0.1.12345 > 10.0.0.2.54321: S 1234:1234(0) win 65535
20:01:13.471705 IP 10.0.0.2.54321 > 10.0.0.1.12345: S 4321:4321(0) ack 1235 win 65535
20:01:13.497422 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 1235:2682(1447) win 65535
20:01:14.573322 IP 10.0.0.2.54321 > 10.0.0.1.12345: . ack 5981 win 65535
20:01:14.593870 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 4129:5576(1447) win 65535
20:01:14.639457 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 7023:8470(1447) win 65535
20:01:14.639606 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 9917:10640(723) win 65535
20:01:14.660971 IP 10.0.0.2.54321 > 10.0.0.1.12345: . ack 11769 win 65535
20:01:14.693847 IP 10.0.0.1.12345 > 10.0.0.2.54321: . 12087:13534(1447) win 65535
20:01:14.726564 IP 10.0.0.2.54321 > 10.0.0.1.12345: . ack 15964 win 65535
Question: The ACK still seems to be different. It is 5981 instead of 2683.
EDIT 2: Real TCP output
22:20:14.492625 IP 72.14.204.99.80 > 10.0.2.15.59745: S 255616001:255616001(0) ack 1727704513 win 65535 <mss 1460>
22:20:14.495606 IP 10.0.2.15.59745 > 72.14.204.99.80: . ack 255616002 win 5840
22:20:14.501015 IP 10.0.2.15.59745 > 72.14.204.99.80: P 1727704513:1727705327(814) ack 255616002 win 5840
22:20:14.501746 IP 72.14.204.99.80 > 10.0.2.15.59745: . ack 1727705327 win 65535
22:20:14.562197 IP 72.14.204.99.80 > 10.0.2.15.59745: P 255616002:255616102(100) ack 1727705327 win 65535
22:20:14.562298 IP 10.0.2.15.59745 > 72.14.204.99.80: . ack 255616102 win 5840
22:20:14.630749 IP 10.0.2.15.59745 > 72.14.204.99.80: P 1727705327:1727706096(769) ack 255616102 win 5840
22:20:14.631228 IP 72.14.204.99.80 > 10.0.2.15.59745: . ack 1727706096 win 65535
22:20:14.692324 IP 72.14.204.99.80 > 10.0.2.15.59745: P 255616102:255616338(236) ack 1727706096 win 65535
22:20:14.692361 IP 10.0.2.15.59745 > 72.14.204.99.80: . ack 255616338 win 6432
Question: I tried as per your suggestion and grep'ed one connection's output. But this time, why is the ACK the way it is instead of SEQ+1?

check from the port number, It seems that LINE1, LINE2 and LINE5 belong to one session while LINE2 and LINE4 is in another session.
Instead using tcpdump for packet analysis, I highly suggest you to capture packets with tcpdump, and analyze the result with wireshark tool.
EDIT：
For the simulator stream, it mess up. Since the 10.0.0.1 -> 10.0.0.2's packets's sequence numbers is not completely, so I think maybe there some packet did not be captured and the timing is not show the real status. so you can ignore it.
For the real stream, it is okay. For syn packet, ack reply = seq +1; for content sending, ack = seq + len. The stream actually show this to us.

Resources