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