Wireshark-dev: Re: [Wireshark-dev] Ethernet dissector

From: Antonello Tartamo <antonellotartamo@xxxxxxxxx>
Date: Sun, 23 May 2021 19:09:48 +0200
I manually added the MAC addresses using proto_tree_add_ether().
I thought there was a better way.
Thanks in advance
Regards
Antonello

Il giorno dom 23 mag 2021 alle ore 18:33 John Thacker <johnthacker@xxxxxxxxx> ha scritto:
On Sun, May 23, 2021 at 12:18 PM John Thacker <johnthacker@xxxxxxxxx> wrote:
On Sun, May 23, 2021 at 11:59 AM Antonello Tartamo <antonellotartamo@xxxxxxxxx> wrote:
The problem is that I don't have a predefined ether type as the ether type field is used as length field.
Is there any other way to reuse the ethernet dissector ?
Thanks in advance

So if I understand correctly, you have a protocol that does not contain Ethernet, but has a two MAC addresses (destination and source), followed by a field which is two octets but *always* is a length field (like a 802.3 Ethernet frame, not Ethernet II), even if over 1500? Or is it something where it's only for lengths less than 1500 bytes, like 802.3 Ethernet, but it's not any of the non Ethernet II frame types (raw 802.3 or 802.3 followed by LLC, with or without SNAP)?

Then it's not on Ethernet, and you need to manually add the source and destination addresses in your dissector and not call the Ethernet dissector. It's not difficult at all to add two FT_ETHER fields to your dissector.

Are you trying to have your protocol work on capture files that claim to have an Ethernet link layer, with this not quite compatible link layer instead?

Note that you can do that, that's what the table you've used is for (a non-Ethernet packet inside Ethernet framing), you just can't subsequently call dissect_eth*() with the same tvb again without creating an infinite loop.

It sounds like what you want is something similar to making dissect_address_data() packet-eth.c a function in the header instead of static, because you want the various subfields (U/L, I/G bits, etc.) broken out like in Ethernet (see https://gitlab.com/wireshark/wireshark/-/issues/15493), which is a little bit of a pain.

John Thacker
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe