Wireshark-bugs: [Wireshark-bugs] [Bug 13238] MPEG TS Parser stops parsing entire IP packet on MP

Date: Fri, 23 Dec 2016 01:16:56 +0000

Comment # 13 on bug 13238 from
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.