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: [EMAIL PROTECTED] [mailto:wireshark-users- > [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users