Closed crosser closed 4 years ago
I think the only possible improvement would be if dpkt threw NeedData exception here. Looks like the required data is outside of the packet boundary and likely requires reassembly (i.e. more packets). The options header decoding is using the correct length, expressed in octets, according to RFC 2460. Note that Wireshark (I tested v3.0.1 on OSX) refuses to decode this single packet as well, not even getting to decoding options.
Indeed the partial copy of the packet that induced "TooBig" response, that was included in the ICMP6 packet, was broken. I wonder though if it is a correct behaviour if broken "payload" crashes parsing of the packet?..
I think it's correct behavior (throwing NeedData that is, not crashing of course). If one were building a reassembling parser and received NeedData, one would add the next packet's payload and re-attempt parsing. I'm going to reopen this to fix the crash. Thanks.
@crosser please see pull request #489; let me know if the proposed solution works for you
When parsing an ICMP6 packet, I am getting "IndexError: index out of range" error:
I believe this is because the IPv6 option header unpacker uses bit length of the header when it should use byte length:
I am not 100% sure of my fix, but changing
while index < self.length - 2:
towhile index < self.len - 2:
seems like a right thing, and it does fix the crash. I will submit a pull request momentarily.