Wireshark-bugs: [Wireshark-bugs] [Bug 13238] MPEG TS Parser stops parsing entire IP packet on MP
Comment # 11
on bug 13238
from Michael Mann
(In reply to Eric Kotz from comment #9)
> > I think the better solution would be to try to address the malformed portion
> > of the packet/data, however I don't have access to the spec (it's not free)
> > to confirm my findings.
>
> It's important to fix that, but that's not actually a solution to this issue.
>
> I believe this and Bug #13237 have become intertwined at this point, even
> though there are actually two separate issues here:
> 1. Wireshark is not parsing descriptor tag 0xA2 properly
Yea that was my fault. I started investigating and because the bugs were
related enough, I unintentionally started posting questions to the wrong bug
(although the original questions were more general). The patch I created will
close the other bug when submitted, but only "pinged" this one.
> 2. Wireshark should continue parsing other MPEG packets within the IP packet
> even if it hits a corrupt MPEG packet.
>
> Additionally, Jeremy brought up the suggestion (and I agree, but this is
> more of a feature request) that even if Wireshark didn't understand a
> descriptor, it should use the length field to continue after skipping it.
>
> Without (2) Wireshark will log continuity errors where they do not exist
> simply because it aborts parsing. While fixing (1) would fix this specific
> problem, any other MPEG parser bug would still trigger (2), which is why I
> believe it's a separate bug that should also be addressed.
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.
You are receiving this mail because:
- You are watching all bug changes.
