1

I am monitoring an openvpn link with tcpdump a la tcpdump -i tun5 -w capture.dump -W 100 -C 100M -s 0 -n There is http/xml traffic going over that link which is basically caputered just fine. However, some packages contain bytes I'd not expect. See this example:

No.     Time           Source                Destination           Protocol Length Info
     15 0.021249       10.150.1.7            10.150.9.6            TCP      1355   8180 → 53327 [ACK] Seq=32056 Ack=1 Win=513 Len=1315

Frame 15: 1355 bytes on wire (10840 bits), 1355 bytes captured (10840 bits)
Raw packet data
Internet Protocol Version 4, Src: 10.150.1.7, Dst: 10.150.9.6
Transmission Control Protocol, Src Port: 8180 (8180), Dst Port: 53327 (53327), Seq: 32056, Ack: 1, Len: 1315

0000   45 00 05 4b 6a c8 40 00 7f 06 6c ac 0a 96 01 07  E..Kj.@...l.....
0010   0a 96 09 06 1f f4 d0 4f ff 91 41 fc b2 6c 8e b9  .......O..A..l..
0020   50 10 02 01 8c fc 00 00 65 63 74 65 64 41 72 72  P.......ectedArr
0030   69 76 61 0d 0a 32 30 30 30 0d 0a 6c 54 69 6d 65  iva..2000..lTime
0040   3e 32 30 31 36 2d 30 33 2d 31 31 54 31 33 3a 31  >2016-03-11T13:1
0050   32 3a 34 37 2b 30 32 3a 30 30 3c 2f 45 78 70 65  2:47+02:00</Expe
0060   63 74 65 64 41 72 72 69 76 61 6c 54 69 6d 65 3e  ctedArrivalTime>
0070   0a 20 20 20 20 20 20 20 20 20 20 20 20 3c 2f 4f  .            </O
0080   6e 77 61 72 64 43 61 6c 6c 3e 0a 20 20 20 20 20  nwardCall>
[...]

Just at the beginning, we have in ASCII:

ectedArriva..2000..lTime>2016-03-11T13:12:47+02:00....

This "..2000.." or 61 0d 0a 32 30 30 30 0d 0a in hex just shouldn't be there. And I am quite certain that the sender doesn't send that. Anyone got a clue what that is or could be?

regards Alex

1

For the record, this was http/chunked traffic and what I am seeing is the chunk header. When opening in wireshark, it will list those packages as TCP segement of a reassembled PDU. Going to the last package of the call, wireshark will decode the http traffic for us, telling us that 2000 ASCII = 8192 (integer), the chunk size. Not related to openvpn, and not a bug at all ;)

0

I suspect that 1) your certainty is misplaced and 2) that packet is a continuation of an HTTP request or response from an earlier TCP segment in the same direction on the same connection, so even though it doesn't look like something that would be sent by the sender, it's part of something that would be sent by the sender.

Try enabling TCP reassembly for HTTP, if it isn't already enabled. Open up Preferences (Edit -> Preferences or, if this is Wireshark 2.x on OS X, Wireshark -> Preferences), open up Protocols, select TCP, make sure "Allow subdissector to reassemble TCP streams" is checked, then select HTTP and make sure "Reassemble HTTP headers spanning multiple TCP segments" and "Reassemble HTTP bodies spanning multiple TCP segments" are both checked. Then it should reassemble all the pieces of the HTTP request or response including that text and show it to you as a reassembled HTTP request or response.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.