| Bug ID |
8556
|
| Summary |
MP2T wiretap heuristic overriding ERF
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.8.6
|
| Hardware |
x86-64
|
| OS |
Ubuntu
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Capture file support (libwiretap)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 10532 [details]
Example MPLS ERF incorrectly decoded as MPEG2-TS (random 150 byte IP payload)
Build Information:
--
Some MPLS ERF traces have been found to incorrectly decode as MPEG2-TS.
The core of the issue seems to be that in wiretap/file_access.c mp2t_open is
listed at higher priority than erf_open (and incorrectly as a well-defined
magic-number identified format despite using single bytes as a heuristic). This
means the mpeg2ts wiretap is tried before the ERF wiretap. I tried moving it
below ERF and it immediately resolved the issue.
The problem appears to be with MPEG2-TS wiretap (wiretap/mp2t.c) added in
revision 41286 and present in at least 1.8.0+ and SVN. It uses a heuristic to
look for 10 consecutive packets that start with 0x47 (a sync byte), but
(because an MPEG TS stream file most likely won't start on a packet boundary)
it seeks to the first instance. It then searches 188-228 bytes ahead for the
next 0x47 (to blindly account for a trailer of up to 40 bytes). This
unfortunately means that it conflicts with ERF and the MPLS 0x8847 ethertype
where total record length are of equal length and between 188 and 228 bytes
long (for the first 10 records). There are no doubt other scenarios where this
might occur (essentially any fixed length record of the appropriate length with
0x47 at regular intervals, even in the timestamp).
The issue does not occur with 1.6.4 shipped with Ubuntu 12.04.
Is there any GUI workaround to disable a particular wiretap or specify what to
use to open the file? To me it would seem sensible to have a format selection
dropdown in the open dialog similar to most other software.
I have attached a generated MPLS ERF file that demonstrates the issue (it has
also been observed with DNS queries over MPLS). I have also attached a proposed
patch (against SVN 48723) to reduce the priority of the MP2T wiretap that
resolves the issue, but do not have any mp2t files to test against. The exact
ordering may need tweaking if there are false positives for other wiretaps.
This should probably be backported if there isn't a simple workaround.
You are receiving this mail because:
- You are watching all bug changes.