Regenerating packets from their str() output adds Padding

[abo <abo@…>]

Packets read in using rdpcap() can gain Padding when regenerated from their str() output;

>>> p.payload
<IP  version=4L ihl=5L tos=0x0 len=56 id=0 flags= frag=0L ttl=253 proto=ICMP chksum=0xdf56 src=172.26.130.243 dst=172.28.3.68 options='' |<ICMP  type=time-exceeded code=0 chksum=0xc5ed id=0x0 seq=0x0 |<IPerror  version=4L ihl=5L tos=0x0 len=40 id=51655 flags= frag=0L ttl=1 proto=TCP chksum=0xa247 src=172.28.3.68 dst=66.249.91.104 options='' |<TCPerror  sport=2040 dport=www seq=621806010L |>>>>
>>> IP(str(p.payload))
<IP  version=4L ihl=5L tos=0x0 len=56 id=0 flags= frag=0L ttl=253 proto=ICMP chksum=0xdf56 src=172.26.130.243 dst=172.28.3.68 options='' |<ICMP  type=time-exceeded code=0 chksum=0xc5ed id=0x0 seq=0x0 |<IPerror  version=4L ihl=5L tos=0x0 len=40 id=51655 flags= frag=0L ttl=1 proto=TCP chksum=0xa247 src=172.28.3.68 dst=66.249.91.104 options='' |<TCPerror  sport=2040 dport=www seq=621806010L |<Padding  load='\x00\x00\x00\x00P\x02 \x00\x13\x0f\x00\x00' |>>>>>
>>>

This apparently has something to do with the len field being out of sync with the payload lengths, such that when the packet is str()'ed you get a longer string than the original package. When this is regenerated, the extra bytes are seen as extra Padding. Note that this padding grows with each str() regenerate cycle.

[abo <abo@…>]

I now understand this better, and will start working on a fix. It is that the TCPerror package is normally truncated inside the ICMP packet. This works fine when loading using rdpcap, as the truncated data only initialises as many fields as can be read from the available data. However, when generating the packet the truncated fields are populated with default values and a full TCPerror packet generated. This means the generated packet contents are larger than specified by the ICMP packet header. When this generated data is re-loaded, the ICMP length field is still set to the smaller size and hence the data is re-read as containing the original truncated TCPerror package followed by some extra padding.

There are possible two ways to fix this;

1) make sure TCPerror packets know they can be truncated, so they build the same data they were originally interpreted from

2) make the ICMP build truncate the generated packet contents to match the specified length.

I think 1) is the better solution, but 2) may be easier and might have some other benefits... Posting on list to get feedback...