http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1528
------- Comment #2 from guy@xxxxxxxxxxxx 2007-04-08 22:39 GMT -------
The file really is corrupt - the len field of the per-packet headers of the
packets are completely bogus.
I think Wireshark could ignore the bogosity - I don't think it's used to
allocate buffers, in which case at least you won't get "out of memory" crashes
- but it would mean that
1) some of the heuristics to discover the various annoying "we'll use the
standard libpcap magic number, but we won't use the standard libpcap per-packet
header format" bogosities might no longer work (it's too bad users, rather than
the developers responsible for those bogosities, will be the ones who suffer,
as the developers in question richly deserve to do so)
and
2) some statistics from those files will be massively untrustworthy.
I'd suggest filing a bug against the ulogd-pcap plugin to get it to stop
writing corrupt libpcap files. If there are a lot of corrupt files out there,
I might consider getting rid of the check in wiretap, but, if I do, I will
cheerfully mark all complaints about
1) the heuristics failing
or
2) the statistics being bogus
as "please complain to the ulogd-pcap developers, it's their fault".
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
