Wireshark · Wireshark-dev: Re: [Wireshark-dev] Crashes while Airpcap sniffing

[Guy Harris <guy@xxxxxxxxxxxx>]

On Jan 2, 2012, at 7:26 AM, Gisle Vanem wrote:

> There are some places in the ./gtk sources that causes a
> crash while sniffing on a AirPcap adapter. I don't know why;
> maybe most code assumes the captured frames contain network
> layer packets.

Or not.  They could be the result of various different bugs, and some or all may have nothing to do with the contents of captured packets, so my inclination would be to treat them as separate bugs (where "as ... bugs" means "file them in Bugzilla).

> I.e. here is one situation in gtk/stats_tree_stat.c:

	...

> Pressing the menu "Statistics | Sametime | Messages" while sniffing on AirPcap ... kaboom! Since "cfg != NULL", but "cgf->pr == NULL". What's the story here?
> 
> A simple patch:
> 
> --- SVN-Latest\gtk\stats_tree_stat.c    Mon Oct 31 11:17:42 2011
> +++ gtk\stats_tree_stat.c       Mon Jan 02 16:11:12 2012
> @@ -389,7 +389,7 @@
>               abbr = g_strdup_printf("%s",action_name);
>       }
>       cfg = stats_tree_get_cfg_by_abbr(abbr);
> -       if(cfg){
> +       if(cfg && cfg->pr){
>               tap_param_dlg_cb(action, cfg->pr->stat_dlg);
>       }else{
>        simple_dialog(ESD_TYPE_ERROR, ESD_BTN_OK,
> 
> But it would be nicer if that menu would be greyed out.

Or if cfg->pr could be set, if that's what's supposed to happen.  At least from how I read the code, it *is* supposed to happen, as long as register_tap_listener_stats_tree_stat() got called when Wireshark started up, and that should be called by register_all_tap_listeners() in gtk/wireshark-tap-register.c.

In any case, that shouldn't be a consequence of the device being captured on, or even of the contents of the packets.  What happens if you try to open some random capture file and use Statistics ->Sametime->Messages?

> There are also this situation (which I can get back to): when getting an unexpected "Information Element ID", the function capture_if_details_802_11_bssid_list() tries to hex-dump a buffer and reading beyond the buffer returned by wpcap_packet_request(). Kaboom again.

That's in the code that tries to get information about 802.11 adapters by making various NDIS requests; the AirPcap adapters aren't NDIS adapters, so, unless WinPcap is internally intercepting those NDIS requests and trying to return equivalent information, that shouldn't be happening on AirPcap adapters - and, if that's what WinPcap is doing, it might be returning IEs that capture_if_details_802_11_bssid_list() doesn't know about, and doing so with a bogus length.

That's not even parsing network packets, so, while it might be related to the Interfaces dialog mishandling non-NDIS adapters, it's not related to the content of captured packets.