Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 2672] Infiniband Dissector Plugin 1.2.0

Date: Mon, 14 Jul 2008 14:36:18 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2672





--- Comment #8 from Stephen Donnelly <stephen@xxxxxxxxxx>  2008-07-14 14:36:17 PDT ---
(In reply to comment #7)

> It looks as if the "payload type" in a normal data packet has an Ethernet type
> in the upper 2 bytes; is that just a convention, or does some Infiniband spec
> dictate that (at least when the lower 2 bytes are 0)?

When the LRH ink Next header (LNH) is 00b, it indicates a "Raw EtherType"
frame.

http://safari.ibmpressbooks.com/0321117654/ch21lev1sec10

The RWH header consists of a reserved field, and an EtherType value. It appears
that this is defined in reference to the IANA registry, so any registered
EtherType should be valid.

http://books.google.com/books?id=4s0BNIxPsdIC&pg=PA75&lpg=PA75&dq=infiniband+rwh&source=web&ots=Rhl2iwZ_b4&sig=0BWnI8xxIf3siKvYvGIHbRea_uE&hl=en&sa=X&oi=book_result&resnum=1&ct=result#PPA75,M1

> In parse_EtherType(), should it just call, for example, the ethertype()
> routine, rather than checking for particular Ethernet types?

Yes, if there is a more direct way to handle EtherTypes in Wireshark we should
use it.

> Most calculations should probably use tvb_reported_length() rather than
> tvb_length(), so that we correctly calculate the actual lengths of packets.  

Right, it would be possible to have a 'snaplen truncated' Infiniband frame.

Have you made the tvbuff_t accessor and reported_length changes, or would you
prefer me to have another go?


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.