Ask Your Question
0

Wireshark does not read padding

asked 2020-05-27 03:45:50 +0000

Dennis gravatar image

I use Scapy to read packet and apply encryption to payload and write the new packet to a pcap file. When I read the new packet using Scapy, I can see the TCP payload size is 304 bytes. But Wireshark only shows the TCP payload size 301 bytes. Interesting that the original packet's tcp payload size is 301 bytes and the AES encryption adds 3 bytes padding to make it 304 bytes(multiple of 16 bytes), and Wireshark does not show the extra 3 bytes added by the padding. Any ideas?

Thanks!

edit retag flag offensive close merge delete

Comments

Was ip.len updated in the new packet?
Can you share the pcaps?

Chuckc gravatar imageChuckc ( 2020-05-27 04:13:21 +0000 )edit

Yes I did update ip.len which has the correct value 344. Everything looks good to me on Scapy. But Wireshark displays a red line on packet length as the value is 344 but the actual length to it is 341..

Sorry I cannot upload the pcap as I don't have 60 points :(

This is what Scapy sees:

pac[5]
Out[439]: <Ether  dst=20:e5:2a:b6:93:f1 src=00:08:02:1c:47:ae type=IPv4 |<IP  version=4 ihl=5 tos=0x0 len=344 id=65 flags=DF frag=0 ttl=128 proto=tcp chksum=0x4d00 src=10.1.21.101 dst=xx.xx.xx.xx |<TCP  sport=49158 dport=http seq=3457856379 ack=2093840789 dataofs=5 reserved=0 flags=PA window=256 chksum=0xdce5 urgptr=0 |<Raw  load='\x08\x1a\xc2>\xd2!?\x89\x1f\x11\x9dD\xf2\xa1PX\xe7\x13q\x9fX\xb6\xed\xca ...
(more)
Dennis gravatar imageDennis ( 2020-05-27 15:29:21 +0000 )edit

Upload the capture to a public share, e.g. Google Drive, DropBox etc. and post a link to the file back here.

grahamb gravatar imagegrahamb ( 2020-05-27 15:31:23 +0000 )edit

https://drive.google.com/file/d/1Vut0...

Please see the packet #6 in question.

Thanks!

Dennis gravatar imageDennis ( 2020-05-27 16:10:22 +0000 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2020-05-27 17:28:03 +0000

Guy Harris gravatar image

Packet 6 in the capture has both the length and captured length as 355 bytes. The total length field in the IPv4 header is 344 bytes; as RFC 791 section 3.1 says, "Total Length is the length of the datagram, measured in octets, including internet header and data." The packet also has a 14-byte Ethernet header, so the total length of the packet should be 344+14 = 358 bytes.

So the packet was written incorrectly. If it was written by code running in Scapy, either Scapy has a bug or the code running in Scapy has a bug.

If I use the View > Reload as File Format/Capture item to cause Wireshark to read the raw file and show the internal structure of the file, packet 6 has a captured length of 358 bytes and an "on the network length" of 355 bytes. It is never valid for the captured length to be larger than the on-the-network length.

edit flag offensive delete link more

Comments

Thank you for your answer. You meant the Total Length field in IP header should include the 14 bytes Ethernet header? When I look at other packet captures, total length just equals to TCP payload + TCP header + IP header.

Yes Scapy does write 358 bytes to the pcap file, and Wireshark only shows 355 bytes "on the network length". I still do not understand what does this mean. Why Wireshark cannot display the extra 3 bytes?

Thanks.

Dennis gravatar imageDennis ( 2020-05-27 23:03:24 +0000 )edit
0

answered 2020-05-27 16:44:59 +0000

Chuckc gravatar image

Maybe check your code that is writing the pcap.
Here's scapy for the comment above. Writing this to a pcap comes into Wireshark with no issues.

a=Ether(dst="20:e5:2a:b6:93:f1",src="00:08:02:1c:47:ae",type="IPv4")/IP(version=4,ihl=5,tos=0x0,len=344,id=65,flags="DF",frag=0,ttl=128,proto="tcp",chksum=0x4d00,src="10.1.21.101",dst="8.8.8.8")/TCP(sport=49158,dport="http",seq=3457856379,ack=2093840789,dataofs=5,reserved=0,flags="PA",window=256,chksum=0xdce5,urgptr=0)/Raw(load='\x08\x1a\xc2>\xd2!?\x89\x1f\x11\x9dD\xf2\xa1PX\xe7\x13q\x9fX\xb6\xed\xca}\xb7\xd0~\xef\x9f\x1a[$\x92"eNW\xb8\[email protected]\x08\xfa1!\n>\x11\xd5\xb7T\xd5l\x1b\xd8\x84\x8cOx\xec\xd59\xad\xe2\xd8C\xa0\xb4_y\xaf\x13\x9c\x8a\xf5\xa8\xed\rK\x13\x9a\xcd\xa2\xe2\r\xc8\xd5\xc7\xda\x1cv\x9d\xd6\xa7\xc9&\xccU\x84\x96\x93\x86\xb4\xb17f\xcb\x97+\xebw\xb1\xc9-"\xb6n\x8a\xcf\x18q\x19o\xc3\xa7\x11\x1b+/\x0f\x0f`\xb1\xfe\xa5j\xe30\x02\x00\t\xd28\x12nh\xbe\x11\xa1;\x1b\xa5\x187\xc1\xea\x87[U%\xa9\xed\xda\x1d5\x1fN\x16\xa3V=\xea\xb3\xf6\xdc\xb2W\x13A\xee\xe4\xac\xdb\xa6\xd4\x03\xbc\x90\x8c|\xd3Y\x9ey\xca0\xd2\xbaC\x1a;\xe7\r~U\xa9\x1d\xb8\xb5\x16Y4\xa1\[email protected]\x96w\x80\xe2\x05\x9f|\xe1`\xc7\'\xc8\tbx\x08rs\xb3\xd8 j8y\x16v\x01\x1c\x94,\xc6~*u\xb0\xff]\xd9\xa7\xc1\xe7\xfe\xe7\x12|\[email protected]\xf4\xe9\xd3\xd3)oE{~\rD\x84\xad\x80\x8an\x97&n\x1b\xb4e\xe4\x1bRY\x99 z\x188\xfaPG\xd0uW\x9d')

>>> a
<Ether  dst=20:e5:2a:b6:93:f1 src=00:08:02:1c:47:ae type=IPv4 |<IP  version=4 ihl=5 tos=0x0 len=344 id=65 flags=DF frag=0 ttl=128 proto=tcp chksum=0x4d00 src=10.1.21.101 dst=8.8.8.8 |<TCP  sport=49158 dport=http seq=3457856379 ack=2093840789 dataofs=5 reserved=0 flags=PA window=256 chksum=0xdce5 urgptr=0 |<Raw  load='\x08\x1a\xc2>\xd2!?\x89\x1f\x11\x9dD\xf2\xa1PX\xe7\x13q\x9fX\xb6\xed\xca}\xb7\xd0~\xef\x9f\x1a[$\x92"eNW\xb8\[email protected]\x08\xfa1!\n>\x11\xd5\xb7T\xd5l\x1b\xd8\x84\x8cOx\xec\xd59\xad\xe2\xd8C\xa0\xb4_y\xaf\x13\x9c\x8a\xf5\xa8\xed\rK\x13\x9a\xcd\xa2\xe2\r\xc8\xd5\xc7\xda\x1cv\x9d\xd6\xa7\xc9&\xccU\x84\x96\x93\x86\xb4\xb17f\xcb\x97+\xebw\xb1\xc9-"\xb6n\x8a\xcf\x18q\x19o\xc3\xa7\x11\x1b+/\x0f\x0f`\xb1\xfe\xa5j\xe30\x02\x00\t\xd28\x12nh\xbe\x11\xa1;\x1b\xa5\x187\xc1\xea\x87[U%\xa9\xed\xda\x1d5\x1fN\x16\xa3V=\xea\xb3\xf6\xdc\xb2W\x13A\xee\xe4\xac\xdb\xa6\xd4\x03\xbc\x90 ...
(more)
edit flag offensive delete link more

Comments

Thanks for you answer. It is the way I create the packet. Although my packet looks the same as your packet "a", after writes it to pcap using wrpcap, it has issues. The "pkt == a" operation does return False although I cannot tell any difference from the two packets.

Dennis gravatar imageDennis ( 2020-05-27 22:56:12 +0000 )edit

Is it one of these: 1083 or 1101 such that Scapy isn't recalculating the frame.len after the encryption padding is added?
Maybe this is a question for the Scapy issues .

Chuckc gravatar imageChuckc ( 2020-05-28 03:06:12 +0000 )edit

Yes I think it is a Scapy issue. Thanks!

Dennis gravatar imageDennis ( 2020-05-28 04:25:17 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2020-05-27 03:45:50 +0000

Seen: 187 times

Last updated: May 27