Thanks Luis!
Just like you said, the following properly decodes the Ethernet part:
Edit->Preferences->Protocols,DLT_USER,Edit...
Click on Edit...
Click New
Leave encap at default of User 0 (DLT=147)
payload_proto - ip
header_size - 48 (14 for Ethernet + 34 for the proprietary header)
header_proto - eth_withoutfcs
trailer_size - leave blank
trailer_proto - leave blank
Click OK
Click OK
In my case, this is for decoding a Cisco protocol. The modular Cisco
multi-function firewall, the ASA, has an expansion slot that houses one
of 3 different modules. The data plane between the ASA and the
expansion module is (or is like) a gigabit ethernet connection. So, you
can actually capture what goes across. However, when data is
encapsulated from the ASA to the expansion module, it appears to put a
34 byte proprietary header in between the Ethernet header and the IP
header. It's actually not quite this simple though. When you look at a
capture, there are other frames that don't follow this simple pattern -
perhaps signaling between the ASA and the expansion unit or something?
In some cases it is useful to look at this information - hence the above
trick is useful.
I would certainly be happy to send you a sample if you'd care to look
but I guess I'm not sure if this would be interesting to the general
Wireshark community. Of course, if you're curious just let me know!
:-)
Thanks again,
--Jim
> -----Original Message-----
> From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-
> bounces@xxxxxxxxxxxxx] On Behalf Of Luis EG Ontanon
> Sent: Sunday, July 22, 2007 12:55 PM
> To: Community support list for Wireshark
> Subject: Re: [Wireshark-users] Setting up a display offset
>
> On 7/22/07, Small, James <JSmall@xxxxxxxxxxxx> wrote:
> > For the general Wireshark community - is there a way to do the above
and
> still see the Ethernet frame but ignore the data in the middle?
>
> I thought in a way to implement it but I could not find a viable way.
> The problem is that we cannot know how long a frame will be. We
> normally pass the entire frame to the ethernet dissector assuming that
> all of it is the ethernet frame and that usually works but in the
> scenario you are depicting that's not the case.
>
>
> > For example, if I have something that processes traffic and inserts
a 34
> byte proprietary header between the Ethernet header and the IP header,
can
> I still see the Ethernet header and the following IP header but ignore
the
> proprietary header in the middle (if I'm not slick enough to write a
> dissector!)?
>
> If you give us a capture with some frames and the background
> information behind what's encoded (port-ids (in the machine creating
> the packets), addresses, etc.) we might be able to reverse-engineer
> it, (For me there's always a certain satisfaction involved in
> rendering public knowledge that someone tries to keep away from the
> people :-).
>
> > I tried:
> > payload_proto - ip
> > header_size - 14 (14 for Ethernet)
> > header_proto - Ethernet (tried ether, ethernet, neither worked...)
>
> Ethernet is registered as either "eth_withoutfcs" (I think this may be
> your case) or "eth_withfcs".
> In revision 22381 I just added an "eth" one that finds out if there's
> an fcs at the end of the frame...
>
> I never thought about it but "eth_withoutfcs" is far from
user-friendly!
>
> > trailer_size - 34
> > trailer_proto - <blank>
> >
> >
> > Also - would this be a good thing to put in the WIKI? If so, any
> suggestions on where?
>
> Go ahead, someone might find it useful.
>
> --
> This information is top security. When you have read it, destroy
yourself.
> -- Marshall McLuhan
