Comment # 13
on bug 13238
from Eric Kotz
Actually my last comment wasn't well-thought-out. I mixed up two things, so
ignore it and let me try again:
> This one is a lot harder to address because it depends on your definition of
> "corrupt". Because Wireshark can be used to find protocol bugs, it
> shouldn't always trust a length field. And if the length field is wrong,
> how do you really know where the next MPEG packet is in the frame? I'm
> tempted to close this as WONTFIX.
To look at this a different way, Wireshark doesn't give up on parsing
subsequent IP packets when it encounters a corrupt IP packets.
I think a reasonable compromise is to attempt to trust the length field is for
the desciptor, not the whole packet. If you want to not attempt to just skip
the descriptor (when a packet is corrupt) I'm not sure that's ideal, but I can
live with that.
Bug #13238 was never about trying to just skip the descriptor and go on (I did
not file a bug for that). Rather, I'm saying that when it encounters a
corrupted MPEG frame within an IP frame, it should just abort processing of
that MPEG frame and skip 188 bytes* forward (the length of an MPEG packet) and
look for the 0x47 MPEG sync pattern, then pick up with the next MPEG packet and
continue parsing.
*There are MPEG packets which have 4 bytes of TimeCode after them, creating 192
Byte packets, in existence. I do not know if Wireshark handles 192-byte MPEG
packets at all right now - if it does it should probably look for 0x47 and 188
bytes, and if not found try again 4 bytes later, or remember the length of the
last successfully parsed packet (188 or 192) and use that, as far as I know
they are never mixed in the same TS.
You are receiving this mail because:
- You are watching all bug changes.