[Bill Fassler <bill.fassler@xxxxxxxxx>]

Thanks Guy!  I really appreciate your prompt and informative response.  I never used or seen Ethereal or Wireshark before last week nor have I ever worked with VoIP, so if it sounds like I don't know what I'm talking about its because I really don't know what I'm talking about.  This application is fairly easy to work with and I made good progress in the last few days for not having any idea how to do it before Monday.  With help from pros like you I should have this plugin spit and polished in no time.

Thanks again,
Bill

Guy Harris <guy@xxxxxxxxxxxx> wrote:
>  
> On Sep 15, 2006, at 12:14 PM, Bill Fassler wrote:
>
> > The traffic is initially captured and classified as "Ethernet  
> > II" (apparently the default selection when Wireshark can't determine  
> > what kind of Ethernet
>  traffic).
>
> What do you mean by "classified as 'Ethernet II'"?  If you mean it  
> displays
>
> Ethernet II, Src: IeeeRegi_33:7f:00 (00:50:c2:33:7f:00), Dst:  
> IeeeRegi_33:7f:fc (00:50:c2:33:7f:fc)
>      Destination: IeeeRegi_33:7f:fc (00:50:c2:33:7f:fc)
>      Source: IeeeRegi_33:7f:00 (00:50:c2:33:7f:00)
>
> that's not a "default selection", it's done for all traffic with a  
> type field (rather than a length field) *regardless* of whether it can  
> determine what kind of traffic it is, because *all* that traffic is  
> "Ethernet II" traffic (or whatever you want to call it - the current  
> 802.3 standards include both "Ethernet II" traffic with a type field  
> and "802.3" traffic with a length field).
>
> If you mean that, when your dissector isn't present, the traffic is  
> just classified as "Ethernet II" traffic, yes, that's the default for  
> traffic that it can't further identify.
>
> > Although it looks like I can get my
>  dissector to start on the packet  
> > after the byte that identifies ethernet type (byte 14)
>
> Well, yes, that's where dissectors for Ethernet traffic are supposed  
> to start, and that's where the Ethernet dissector will start them.
>
> > I don't know how to "backtrack" and over rule what the core  
> > Wireshark application has already dissected.
>
> You can't know how to do that, because it's not possible, by design.
>
> > As you can see from this snipped, my protocol (566F) is still  
> > considered "Type : Unkown" even though it just used that information  
> > to pass the packet to my plugin.
>
> The problem there isn't that your dissector can't go back and  
> "rewrite" what the Ethernet dissector has done, the problem is that we  
> don't have a mechanism by which the value_string table for a field can  
> be set up at run time.  We arguably should have that, so that, for  
> example, the table of Ethernet types can be
>  updated by dissectors of  
> Ethernet protocols - or, alternatively, so that the table can be read  
> from a file.
>
> >  Also there is information in the source and destination MAC  
> > addresses that I would like to dissect.
>
> Again, by design, you won't be able to update the way those fields are  
> dissected.  Dissecting them is the job of the Ethernet dissector, as  
> their contents are defined by the Ethernet spec.
>
> However, if you just need to *read* those in your dissector, you can  
> do that by looking at the dl_src and dl_dst fields in the structure  
> pointed to by the "packet_info" pointer argument to your dissector.
>
> You could also put into *your* dissector's protocol tree a dissection  
> of the relevant parts of those fields; the offset and length values  
> would both be 0, as you wouldn't be able to make them refer to the  
> data in the Ethernet header portion of the packet (again, by
>  design).
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev

---

 All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.