I'm looking at an Ethernet capture from a BroadR Reach camera using 1722 to send MJPEG video. I am confused by the wireshark output and wonder if there is a decoding issue or, more likely, a misunderstanding on my part. The IEEE 1394 spec indicates that the Tag value 00 indicates No CIP header included. The trace I have captured has a Tag value of 00 Associated with this is the fact that it seems to be ignoring the 1394 Header CRC between the 1394 Header and the CIP header. I'm totally confused as to whats going on. Is Wireshark throwing a wobble or is it me? Here is the pcap file 1722.pcap asked 01 Jun '16, 10:19  paulrbarnard edited 01 Jun '16, 10:24 |
However wireshark goes on to decode a CIP header. The values in the header are largely garbage from a comparison with the standard. For example Format ID in the screen shot is 0x0d which is not listed as a valid code in 1394. The values are pretty random landing in the reserved range for several elements. This suggests to me that Wireshark is decoding 1394 incorrectly.
One Answer:
The 1394 dissection is part of the 1722 dissection, which does assume the 1394 fields are all there all the time. If this is in error a bug report should be filed, with your capture attached and a reference to the protocol working group. answered 01 Jun '16, 15:02  Jaap ♦ |
Thank you Jaap. Having slept on it I'm pretty sure this is a bug so I have raised a ticket https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12490 to track this problem.