Why TCPDUMP shows Ethernet packet when querying TCP packet? - networking

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.

Related

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

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?

Getting TCP Retransmission instead of ACK on TUN device

I'm trying to implement a TCP stack over TUN device according to RFC 793 in Linux. By default, my program is in the LISTEN state and is waiting for an SYN packet to establish a connection. I use nc to send an SYN:
$ nc 192.168.20.99 20
My program responds with SYN, ACK, but nc doesn't send an ACK at the end. This is the flow:
# tshark -i tun0 -z flow,tcp,network
1 0.000000000 192.168.20.1 → 192.168.20.99 TCP 60 39284 → 20 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1691638570 TSecr=0 WS=128
2 0.000112185 192.168.20.99 → 192.168.20.1 TCP 40 20 → 39284 [SYN, ACK] Seq=0 Ack=1 Win=10 Len=0
3 1.001056784 192.168.20.1 → 192.168.20.99 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 39284 → 20 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1691639571 TSecr=0 WS=128
|Time | 192.168.20.1 |
| | | 192.168.20.99 |
|0.000000000| SYN | |Seq = 0
| |(39284) ------------------> (20) |
|0.000112185| SYN, ACK | |Seq = 0 Ack = 1
| |(39284) <------------------ (20) |
|1.001056784| SYN | |Seq = 0
| |(39284) ------------------> (20) |
More info about my TCP header:
Frame 2: 40 bytes on wire (320 bits), 40 bytes captured (320 bits) on interface tun0, id 0
Raw packet data
Internet Protocol Version 4, Src: 192.168.20.99, Dst: 192.168.20.1
Transmission Control Protocol, Src Port: 20, Dst Port: 39310, Seq: 0, Ack: 1, Len: 0
Source Port: 20
Destination Port: 39310
[Stream index: 0]
[Conversation completeness: Incomplete, CLIENT_ESTABLISHED (3)]
[TCP Segment Len: 0]
Sequence Number: 0 (relative sequence number)
Sequence Number (raw): 0
[Next Sequence Number: 1 (relative sequence number)]
Acknowledgment Number: 1 (relative ack number)
Acknowledgment number (raw): 645383655
0101 .... = Header Length: 20 bytes (5)
Flags: 0x012 (SYN, ACK)
Window: 10
[Calculated window size: 10]
Checksum: 0x99b0 [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
NOTE: I'm aware of the ISN prediction attack, but this is just a test, and 0 for the sequence number is just as random as any other number in this case.
UPDATE: This is the output of tcpdump which says I'm calculating checksum wrong:
# tcpdump -i tun0 -vv -n
...
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 16f3 (->911b)!)
192.168.20.99.20 > 192.168.20.1.39308: Flags [S.], cksum 0x9bb0 (incorrect -> 0x1822), seq 0, ack 274285560, win 10, length 0
...
Here is my checksum calculator (From RFC 1071):
uint16_t checksum(void *addr, int count)
{
uint32_t sum = 0;
uint16_t *ptr = addr;
while (count > 1) {
sum += *ptr++;
count -= 2;
}
if (count > 0)
sum += *(uint8_t *)ptr;
while (sum >> 16)
sum = (sum & 0xffff) + (sum >> 16);
return ~sum;
}
And I'm passing the combination of pseudo-header with the TCP segment for TCP checksum. (in big-endian order):
uint16_t tcp_checksum(struct tcp_header *tcph, uint8_t *pseudo_header)
{
size_t len = PSEUDO_HEADER_SIZE + (tcph->data_offset * 4);
uint8_t combination[len];
memcpy(combination, pseudo_header, PSEUDO_HEADER_SIZE);
dump_tcp_header(tcph, combination, PSEUDO_HEADER_SIZE);
return checksum(combination, len / 2);
}
What am I doing wrong here?

Problem solved by calculating checksums via in_cksum.c from tcpdump source code, which is a line-by-line implementation of the RFC 1071. I also had to set IFF_NO_PI for the tun device. For this case, using a tap device instead of a tun device is probably a better choice to handle EtherType.

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).

Strange IP packet analysis?

I use tcpdump to catch some tcp packets, when analyzing them according to ip/tcp packet schema, the packet seems to be broken. Here is a sample packet I got from tcpdump output. Is any one familiar with them?
Should not the first 4 bit of ip packet always be 0100 in under ipv4?
ip packet: https://en.wikipedia.org/wiki/IPv4
some examples: http://mike.passwall.com/networking/samplepacket.html
13:11:43.330397 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.0.14.16668 > 36.24.146.114.64853: Flags [S.], cksum 0xdc0f (correct), seq 3029391223, ack 129060479, win 14480, options [mss 1460,sackOK,TS val 1254469916 ecr 1492278057,nop,wscale 6], length 0
0x0000: feee 809f 3247 5254 0054 aa9f 0800 4500 ....2GRT.T....E.
0x0010: 003c 0000 4000 4006 d813 ac10 000e 2418 .<..#.#.......$.
0x0020: 9272 411c fd55 b490 d777 07b1 4e7f a012 .rA..U...w..N...
0x0030: 3890 dc0f 0000 0204 05b4 0402 080a 4ac5 8.............J.
uname -a
# Linux VM_0_14_centos 2.6.32-754.2.1.el6.x86_64 #1 SMP Fri Jul 13 12:50:12 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
# tcpdump
tcpdump tcp -vv -XX -n -i eth0 port 16668

0x0000: feee 809f 3247 5254 0054 aa9f 0800 4500 ....2GRT.T....E.
The first 14 bytes are from the link layer (EN10MB). The IP layer only starts with 4500, where the 4 (binary 0100) are the first 4 bits which describe the version number, i.e. IP version 4.
These link layer data are explicitly requested by the -XX option which is used by the OP as pointed out in a comment by David Hoelzer. To cite from the documentation of tcpdump:
-XX When parsing and printing, in addition to printing the headers of each packet, print the data of each packet, including its link level header, in hex and ASCII.

How to plot HTTP message sequences with TCPDUMP?

I want to see HTTP massage sequence, headers, bodies, etc between localhost and 178.209.54.154 address.
Now I am using tcpdump -s 0 -i en0 -vvv -XX -n net 178.209.54.154 and tcp port http command.
and get something like:
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:37:53.995945 IP (tos 0x0, ttl 64, id 610, offset 0, flags [DF], proto TCP (6), length 64)
192.168.0.100.50145 > 178.209.54.154.80: Flags [S], cksum 0x816e (correct), seq 2583279465, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 921157274 ecr 0,sackOK,eol], length 0
0x0000: 10fe ed86 4692 2837 3719 e1e4 0800 4500 ....F.(77.....E.
0x0010: 0040 0262 4000 4006 8dde c0a8 0064 b2d1 .#.b#.#......d..
0x0020: 369a c3e1 0050 99f9 b769 0000 0000 b002 6....P...i......
0x0030: ffff 816e 0000 0204 05b4 0103 0305 0101 ...n............
0x0040: 080a 36e7 be9a 0000 0000 0402 0000 ..6...........
12:37:54.028202 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 60)
178.209.54.154.80 > 192.168.0.100.50145: Flags [S.], cksum 0xcc89 (correct), seq 2159366931, ack 2583279466, win 14480, options [mss 1460,sackOK,TS val 3897807146 ecr 921157274,nop,wscale 6], length 0
0x0000: 2837 3719 e1e4 10fe ed86 4692 0800 4500 (77.......F...E.
0x0010: 003c 0000 4000 3506 9b44 b2d1 369a c0a8 .<..#.5..D..6...
0x0020: 0064 0050 c3e1 80b5 5313 99f9 b76a a012 .d.P....S....j..
0x0030: 3890 cc89 0000 0204 05b4 0402 080a e853 8..............S
0x0040: d12a 36e7 be9a 0103 0306 .*6.......
12:37:54.028392 IP (tos 0x0, ttl 64, id 52651, offset 0, flags [DF], proto TCP (6), length 52)
192.168.0.100.50145 > 178.209.54.154.80: Flags [.], cksum 0x23b0 (correct), seq 1, ack 1, win 4117, options [nop,nop,TS val 921157306 ecr 3897807146], length 0
0x0000: 10fe ed86 4692 2837 3719 e1e4 0800 4500 ....F.(77.....E.
0x0010: 0034 cdab 4000 4006 c2a0 c0a8 0064 b2d1 .4..#.#......d..
0x0020: 369a c3e1 0050 99f9 b76a 80b5 5314 8010 6....P...j..S...
0x0030: 1015 23b0 0000 0101 080a 36e7 beba e853 ..#.......6....S
0x0040: d12a .*
12:37:54.028939 IP (tos 0x0, ttl 64, id 50669, offset 0, flags [DF], proto TCP (6), length 733)
192.168.0.100.50145 > 178.209.54.154.80: Flags [P.], cksum 0xf925 (correct), seq 1:682, ack 1, win 4117, options [nop,nop,TS val 921157306 ecr 3897807146], length 681
0x0000: 10fe ed86 4692 2837 3719 e1e4 0800 4500 ....F.(77.....E.
0x0010: 02dd c5ed 4000 4006 c7b5 c0a8 0064 b2d1 ....#.#......d..
0x0020: 369a c3e1 0050 99f9 b76a 80b5 5314 8018 6....P...j..S...
0x0030: 1015 f925 0000 0101 080a 36e7 beba e853 ...%......6....S
0x0040: d12a 504f 5354 202f 6170 692f 7075 7368 .*POST./api/push
Is it a way to see human readable texts?

I found here the answer here. Need: -A and -s 0, do not need: -X.
so now the command looks like: tcpdump -s 0 -i en0 -A -n net 178.209.54.154 and tcp port http
It is able to see as TCP message sequence built up:
//This is the first TCP SYN message
12:56:20.423947 IP 192.168.0.100.50309 > 178.209.54.154.80: Flags [S], seq 500264639, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 922261713 ecr 0,sackOK,eol], length 0
E..#2.#.#.^%...d..6....P..n.........kU.............
6...........
//SYN/ACK package
12:56:20.454469 IP 178.209.54.154.80 > 192.168.0.100.50309: Flags [S.], seq 2881439697, ack 500264640, win 14480, options [mss 1460,sackOK,TS val 3898083756 ecr 922261713,nop,wscale 6], length 0
E..<..#.4..D..6....d.P....G...n...8.^".........
.X .6.......
//SYN/ACK package
12:56:20.454569 IP 192.168.0.100.50309 > 178.209.54.154.80: Flags [.], ack 1, win 4117, options [nop,nop,TS val 922261743 ecr 3898083756], length 0
E..4.p#.#......d..6....P..n...G......J.....
6....X .
//TCP data segment request
12:56:20.454814 IP 192.168.0.100.50309 > 178.209.54.154.80: Flags [P.], seq 1:682, ack 1, win 4117, options [nop,nop,TS val 922261743 ecr 3898083756], length 681
E...].#.#./....d..6....P..n...G............
6....X .POST /api/push/push_notifications HTTP/1.1
Host: www.swisshttp.weact.ch
Connection: keep-alive
Content-Length: 79
Origin: chrome-extension://hgmloofddffdnphfgcellkdfbfbjeloo
X-CSRF-Token: L3rPWu32UJS_nFdt60nXsX1-QalAtyfu8SN4bulqka4
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.130 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: SESSddd86b861821645243debeb76dd4c66e=ukkmK9R2qpXb5qzXCs6qfGO5_cjSTrc7UwolrL94ylg; has_js=1
token=7fa88ba075b6b20e388bc6171379004c853a775dec08aa2a2559c34dfd79cd9h&type=ios
//TCP ACK maybe??
12:56:20.485212 IP 178.209.54.154.80 > 192.168.0.100.50309: Flags [.], ack 682, win 248, options [nop,nop,TS val 3898083764 ecr 922261743], length 0
E..4Nf#.4.M...6....d.P....G...qi...........
.X .6...
//TCP data segment response
12:56:20.638911 IP 178.209.54.154.80 > 192.168.0.100.50309: Flags [P.], seq 1:381, ack 682, win 248, options [nop,nop,TS val 3898083802 ecr 922261743], length 380
E...Ng#.4.Li..6....d.P....G...qi.....5.....
.X .6...HTTP/1.1 200 OK
Date: Mon, 10 Aug 2015 10:56:20 GMT
Server: Apache
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Vary: Accept
Content-Length: 77
Keep-Alive: timeout=30, max=50
Connection: Keep-Alive
Content-Type: application/json
{"success":1,"message":"This token was successfully stored in the database."}
//TCP FIN/ACK
12:56:20.639082 IP 192.168.0.100.50309 > 178.209.54.154.80: Flags [.], ack 381, win 4105, options [nop,nop,TS val 922261926 ecr 3898083802], length 0
E..4..#.#..r...d..6....P..qi..IN... .L.....
6....X .
^C
7 packets captured

Resources