Comment # 4
on bug 8362
from Dario Ciccarone
Jaap:
Did you (a) check the pcap, and (b) run the scapy script I provided ?
If you check the pcap, you will see that the destination of the traffic
correctly reassembled the packet, and replied.
If you run the scapy script against other hosts (OS/X, Cisco IOS) you will
see those OSes also reassemble the packet and reply.
Which means there's a difference in how Wireshark handles a Frag EH, and
how OSes out there do it. For the packet in question, the sequence is:
F(MF=0, OFF=0) | F(MF=1, OFF=0) | F(MF=0, OFF=0)
The way a host stack would process this would be:
1) for the first Frag EH - send the packet to the reassembly queue. Because
we have the first fragment, and also the last, reassembly is done - packet is
sent back for IPv6 Input processing
2) for the 2nd Frag EH - again, packet goes for reassembly - as MF=1, we
will set the reassembly timer, and drop if not all fragments are received
during the reassembly window. As all fragments in this example do arrive during
the reassembly window, we sent it again for input processing
3) as (1) before
Of course, as an optimization, if MF=0 and IFF=0 then we can just move to
the next header. But as soon as we run into any other combination - it has to
go for reassembly. Wireshark instead is parsing the chain in one pass - and
deciding "I'm done here". While in theory this may be OK, theory gives way to
test and observation - in this case, observation tells us that OSes out there
don't work the way Wireshark think they work.
And yes, Wireshark could add a check for this kind of combination - still, the
way Wireshark performs reassembly needs to be reviewed.
You are receiving this mail because:
- You are watching all bug changes.
