ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Help finding the link layer dissector call (netmon_802_11)

From: Guy Harris <gharris@xxxxxxxxx>
Date: Tue, 16 Feb 2021 02:57:38 -0800
On Feb 16, 2021, at 2:41 AM, Shai Shapira via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:

> I'm researching Microsoft's Network Monitor captures format (.cap files)

Unfortunately, you probably can't download NetMon from Microsoft any more, so you probably can't get the help file that documents the capture file format any more.

But if you have direct questions about it, I can answer them.

> and I need a lead in WS's code.
> Based on the 'link layer type' parsed from the file header the packets might be 802.11 frames with NM's special header.
> This dissector is known as "netmon_802_11" in wireshark.
> 
> It is the first protocol in every frame's stack and it's registration routine is directly to the "wtap_encap" table like so:
> dissector_add_uint("wtap_encap", WTAP_ENCAP_IEEE_802_11_NETMON, netmon_802_11_handle);
> 
> (from packet-ieee80211-netmon.c)
> 
> Could someone point me to the functoin where the actual 'call_dissector' or 'call_dissector_with_data' is happening for the inital layer?

It's happening in the

			switch (pinfo->rec->rec_type) {

			case REC_TYPE_PACKET:
				if ((force_docsis_encap) && (docsis_handle)) {
					dissector_handle = docsis_handle;
				} else {
					/*
					 * XXX - we don't use dissector_try_uint_new()
					 * because we don't want to have to
					 * treat a zero return from the dissector
					 * as meaning "packet not accepted,
					 * because that doesn't work for
					 * packets where libwiretap strips
					 * off the metadata header and puts
					 * it into the pseudo-header, leaving
					 * zero bytes worth of payload.  See
					 * bug 15630.
					 *
					 * If the dissector for the packet's
					 * purported link-layer header type
					 * rejects the packet, that's a sign
					 * of a bug somewhere, so making it
					 * impossible for those dissectors
					 * to reject packets isn't a problem.
					 */
					dissector_handle =
					    dissector_get_uint_handle(wtap_encap_dissector_table,
					        pinfo->rec->rec_header.packet_header.pkt_encap);
				}
				if (dissector_handle != NULL) {
					guint32 save_match_uint = pinfo->match_uint;

					pinfo->match_uint =
					    pinfo->rec->rec_header.packet_header.pkt_encap;
					call_dissector_only(dissector_handle,
					    tvb, pinfo, parent_tree,
					    (void *)pinfo->pseudo_header);
					pinfo->match_uint = save_match_uint;
				} else {
					col_set_str(pinfo->cinfo, COL_PROTOCOL, "UNKNOWN");
					col_add_fstr(pinfo->cinfo, COL_INFO, "WTAP_ENCAP = %d",
						     pinfo->rec->rec_header.packet_header.pkt_encap);
					call_data_dissector(tvb, pinfo, parent_tree);
				}
				break;

code in dissect_frame() in epan/dissectors/packet-frame.c

> Also, is that dependent on the file format we are parsing (pcap/pcapmg/cap)

No.  (And there are more formats than those, not that "cap" is a file format - several *different* file formats use ".cap" as the suffix, so there's no such thing as a ".cap file".)

> or is there a single function all eventually get to?

Yes.  The libwiretap library handles differences between capture file formats, supplying packet information in a standard fashion to libwireshark.