http://www.tcpdump.org/linktypes.html for the details, rather than to
some particular OS's net/bpf.h (assuming it even has one), and speak of
it as a LINKTYPE_ value rather than a DLT_ value (in those cases where
the LINKTYPE_ value for a given link-layer header type is different from
the DLT_ value, it's the LINKTYPE_ value that should be passed to
text2pcap, as it's what gets written to the file, and those should be
the always-platform-independent LINKTYPE_ values rather than the
possibly-platform-dependent DLT_ values).
svn path=/trunk/; revision=51008
DLT_ value, which is good because it's a numerical value and the
numerical values for some link-layer header types are OS-dependent, but
the numerical values for all LINKTYPE_ values are OS-independent. Use
LINKTYPE_RAW, not the value for the DLT_RAW on some but not all OSes,
for raw IP.
Also, 7 is LINKTYPE_ARCNET_BSD, emphasis on the "_BSD"; there's also a
Linux encapsulation for ARCNet that is different. Note that it's the
BSD flavor.
svn path=/trunk/; revision=51005
mktime(). That eliminates the need for casts.
It should *also* be part of a per-wtap-structure private data structure,
not a global variable; make it so.
svn path=/trunk/; revision=51000
argument to the -F flag for pcap format is "libpcap", not "pcap", we
have a problem. Make it "pcap", and add a backwards-compatibility hack
to support using "libpcap" as well.
Update the man pages to refer to it as pcap as well, and fix the
capitalization of "WinPcap" (see http://www.winpcap.org) while we're at
it.
Also, refer to http://www.tcpdump.org/linktypes.html for the list of
link-layer header types for pcap and pcap-ng.
svn path=/trunk/; revision=50989
Lua cannot store a 64 bit integer with full precision, which is used
for keys in tables, so this is not a 100% solution. But it will probably
be good enough for value strings, and it is better to have some support
than no support.
svn path=/trunk/; revision=50988
what's done after that.
If we want to set the all-interfaces capture filter string, just set it,
don't add anything to the drop-down list for it.
If, after we've succeeded starting a capture, all active interfaces have
the same capture filter, *do* add that filter to the all-interfaces
recent capture filters list.
Also, free g_strduped capture filter strings when we're done with them.
svn path=/trunk/; revision=50986
In recent_add_cfilter(), the list we're working on is cfilter_list;
properly remove an item from it - don't assign the result to
recent_cfilter_list, assign it to cfilter_list. This may fix some
crashes and Valgrind errors.
svn path=/trunk/; revision=50984
to override that to simple for valgrinding (we still force the allocator in the
allocator and timing tests, of course).
svn path=/trunk/; revision=50971
Move a few assignments around to avoid one extra subtraction. I suspect having
the two if statements next to each other is friendly to the compiler's optimizer
as well.
Shaves ~1.3% off my timing tests, bringing the new design *very* close to the
old one in raw allocation speed.
svn path=/trunk/; revision=50961
unobtrusive if statement got dropped. Without it the allocator exhibits the old
bad behaviour of 3x memory usage and heavy fragmentation.
We want it back, thank you very much.
svn path=/trunk/; revision=50960
addition to a "global" list. Store all of those lists in the recent
file. Maintain the lists in ui/recent.c, rather than attaching them to
widgets; have the code that populates the combo boxes get the lists from
the ui/recent.c code.
This makes a little more of the code GUI-toolkit-independent, and should
fix bug 7278.
#BACKPORT 1.10, 1.8
svn path=/trunk/; revision=50956
What was becoming apparent as more dissectors started using wmem was that the
old block allocator design had issues with memory fragmentation. This keeps the
same underlying memory layout, but completely changes how free blocks are kept.
It runs about 3% slower in my tests (still an order of magnitude faster than
g_malloc) but uses about 1/3 the memory.
I suspect some simple optimizations could reclaim that 3% as well - the design
is fast, but I did not code particularly for speed.
Thoroughly tested with the existing test suite (which caught half a dozen bugs
in my first draft) so it should actually work!
svn path=/trunk/; revision=50955
Guy Harris