Wireshark does not read padding

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

Dennis
1 ●3 ●1

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 ( 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 ( 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 ( 2020-05-27 15:31:23 +0000 )edit

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

Please see the packet #6 in question.

Thanks!

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

add a comment

2 Answers

Sort by » oldest newest most voted

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

Guy Harris
19890 ●3 ●633 ●207

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

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 ( 2020-05-27 23:03:24 +0000 )edit

add a comment

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

Chuckc
2808 ●5 ●566 ●19

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\xb9P@\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\x805@\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|\xd2@V.\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\xb9P@\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

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 ( 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 ( 2020-05-28 03:06:12 +0000 )edit

Yes I think it is a Scapy issue. Thanks!

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

add a comment

Your Answer

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

Add Answer

Wireshark does not read padding

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

Wireshark does not read padding edit

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

Wireshark does not read padding