Wireshark · Wireshark-dev: Re: [Wireshark-dev] Help understanding Epan's dissectors

[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

See the frame dissector in packet-frame.c for instance. It uses this line:

  if (!dissector_try_port(wtap_encap_dissector_table, pinfo->fd->lnk_t,
      tvb, pinfo, parent_tree)) {

It uses wtap_encap_dissector_table to search for the pinfo->fd->lnk_t
entry and calls that dissector (oke it's called try_port since it's
normally used for port based searches, but the idea is the same).

Another way to do this is with heuristic dissectors. More dissectors are
registered for the same lets say UDP port. Now they are called 'in random
order' and the first one that says it recognizes the packet can dissect
it. Chances are it's wrong, but then all we can do is improve the
heuristics of that dissector.

Thanx,
Jaap

On Mon, 30 Oct 2006 angustia@xxxxxxxxxxxxxxxxxx wrote:

> 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
> >
>
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>