[angustia@xxxxxxxxxxxxxxxxxx]

Hello,

I think I get it now. It is not the higher level dissectors that  
actively search for lower lever dissectors in their source file. It is  
the lower level dissectors that register themselves with all possible  
higher lever dissectors where they might occur. So the packet-*.c  
files don't probe for anything, they only dissect, and explain their  
values (like "udp.port"). After a dissector has finished doing its  
work, some function will search in its list of possibilities for the  
most correct sub-dissector.

Now, how does the library decide, in the list of possibilities, which  
is the most correct sub-dissector? I've looked some into  
call_dissector_work and functions like that, but I don't quite  
understand how that's done.

Thanks,
Ramiro Polla

Quoting Jaap Keuter <jaap.keuter@xxxxxxxxx>:

> Hi,
>
> Ah, so all is clear on the wiretap front. Well from there on (look in
> packet-frame.c) the frame dissector looks in wtap_encap_dissector_table
> for the dissector handling Ethernet (in this case). This dissector (see
> packet-eth.c) has registered itself during startup in this table (search
> for "wtap_encap") with the wiretap encapsulation for Ethernet. Therefor it
> well be selected to decode the next part of the frame.
> The Ethernet dissector itself knows where to look for the Ethertype (see
> packet-ethertype.c) in the frame and finds the IP protocol dissector (in
> this case). Therefor it well be selected to decode the next part of the
> frame.
> The IP dissector itself knows where to look for the Protocol (see
> packet-ip.c) in the frame ..........
>
> Etc etc etc.
>
> So it all depends on the dissectors which register themselves to a lower
> level dissector to handle a certain protocol. This can be via a dissector
> table (like frame uses) or, if there is no specific field which describes
> the next layer protocol (like a UDP payload), via a registration based on
> certain aspects of the lower layer protocol. Like the bootp dissector
> (see packet-bootp.c), which registers itself for udp.port 67 and 68.
>
> In this the design of Wireshark mimics the protocol stack model perfectly
> and makes it so extensible.
>
> Thanx,
> Jaap
>
>
> On Mon, 30 Oct 2006 angustia@xxxxxxxxxxxxxxxxxx wrote:
>
> > Hello,
> >
> > I understand that Wiretap passes the necessary information in
> > pseudo-headers, but how does the following subdissections work? I
> > mean, who finds out that an ethernet packet is IP, and from that,
> > which one is TCP, and from that, which one belongs to whatever
> > program...
> >
> > Thanks,
> > Ramiro Polla
> >
> > Quoting Jaap Keuter <jaap.keuter@xxxxxxxxx>:
> >
> > > Hi,
> > >
> > > Good question. For the answer you have to search further up the call
> > > chain. Lets see:
> > > file.c:add_packet_to_packet_list()
> > > epan/epan.c:epan_dissect_run()
> > > epan/packet.c:dissect_packet()
> > > epan/dissectors/packet-frame.c:dissect_frame()
> > >
> > > So when reading packets from a capture file, metadata (like wtap_encap) is
> > > available passed along with it for the frame dissector to use. It's up to
> > > the capture engine writing this capture file metadate to put the right
> > > stuff in there.
> > >
> > > Thanx,
> > > Jaap
> > >
> > > On Sun, 29 Oct 2006 angustia@xxxxxxxxxxxxxxxxxx wrote:
> > >
> > >> Hello,
> > >>
> > >> I've been studying Wireshark's source code for a while, but there's
> > >> something I still don't understand. It's specifically about the inner
> > >> workings of Epan. How does one dissectors knows and decides which
> > >> subdissector is the correct one?
> > >>
> > >> Such as, how does "frame" know which "wtap_encap" is the correct one?
> > >> Are there any probe functions around that I am missing?
> > >>
> > >> Thanks,
> > >> Ramiro Polla
> > >>
> > >
> > > _______________________________________________
> > > Wireshark-dev mailing list
> > > Wireshark-dev@xxxxxxxxxxxxx
> > > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> > >
> >
> >
> > _______________________________________________
> > Wireshark-dev mailing list
> > Wireshark-dev@xxxxxxxxxxxxx
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev