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
