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.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
