Currently there is no bounds checking and a traceback will occur if the packet
data is shorter than the purported extension header option length.
FWIW, I'm not using this exact diff in my project. Instead of raising
dpkt.UnpackError, I am just silently breaking out of the loop. That way most
of the pertinent IPv6 data (up and to including the bad extension header) is
successfully parsed out of the packet and accessible, as opposed to having only
the Ethernet portion. That said, I felt raising the error fit better with the
existing code. If the maintainers disagree then feel free to change this.
Original issue reported on code.google.com by aa...@monkey.org on 25 Apr 2011 at 1:12
Original issue reported on code.google.com by
aa...@monkey.org
on 25 Apr 2011 at 1:12Attachments: