| Bug ID |
10702
|
| Summary |
Wiresharks assumes all IEEE 1722 packets transporting IEC 61883-6 stream data, regardless of the actual composition
|
| Product |
Wireshark
|
| Version |
1.12.2
|
| Hardware |
x86-64
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Minor
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 13264 [details]
Wireshark trace of three different AVB streams to check the decoding bug
Build Information:
Version 1.12.2 (v1.12.2-0-g898fa22 from master-1.12)
Copyright 1998-2014 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15, with Gcrypt 1.6.2,
without Kerberos, with GeoIP, with PortAudio V19-devel (built Nov 12 2014),
with
AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 3.2.15, Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, with 16174MB of physical memory.
Built using Microsoft Visual C++ 10.0 build 40219
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
Hi,
I've encountered the following nuisance when using Wireshark to debug an AVB
streaming solution:
Wireshark assumes that every 1722 packet contains an IEC 61883-6 stream
interface (sampled PCM audio), regardless of the actual contents of the packet.
Here's a sketch of an IEEE 1722 packet containing an IEC 61883-n stream
interface:
http://www.ieee802.org/1/files/public/docs2009/avb-rboatright-p1722-explained-0903.pdf
(Go to slide 11).
The IEEE 1722 header has to fields to announce what it's carrying, that's the
subtype field (0x00 on default, 0x6F for vendor specific and 0x7F for
experimental). Plus there's the Tag field which shows if the payload is
embedded in an IEC 61883 stream-interface (0x01) or not (0x00).
The 61883 stream interface has a format flag FMT which describes the type of
streaming data which is embedded, for example audio (0x10) or MPEG2-TS video
(0x20).
But Wireshark is apparently ignoring all these fields and interpreting each
1722 packet as containing a 61883-6 PCM audio stream interface. I've attached a
wireshark trace to clarify the problem. The trace shows three active IEEE 1722
streams:
Stream #0, Multicast Address 91:E0:F0:00:FE:00, length 98:
Sampled PCM audio
Subtype: 0x00
Tag: 0x01
FMT: 0x10
Stream #1, Multicast Address 91:E0:F0:00:FE:01, length 434 or 242:
MPEG2-TS
Subtype: 0x00
Tag: 0x01
FMT: 0x20
Stream #3, Multicast Address 91:E0:F0:00:FE:03, length 78:
Custom stream
Subtype: 0x6F
Tag: 0x00
FMT: -
Stream #0 is correctly decoded as an 61883-6 interface, with the audio samples
being shown.
Stream #1, however, is also decoded as an 61883-6 interface, despite the fact
that it is declared as containing MPEG2-TS samples (via the FMT field).
And Stream #2 is also decoded as an 61883-6 interface, despite not even having
a 61883 header (tag 0x00). Because of this, the first eight byte of Stream #2's
payload are decoded as a 61883 header by wireshark.
You are receiving this mail because:
- You are watching all bug changes.