Re: Ethernet dissector

[Antonello Tartamo <antonellotartamo () gmail com>]

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 () gmail com>
ha scritto:

> On Sun, May 23, 2021 at 12:18 PM John Thacker <johnthacker () gmail com>
> wrote:
>
> > On Sun, May 23, 2021 at 11:59 AM Antonello Tartamo <
> > antonellotartamo () gmail com> 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 () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe