wireshark SHOULD be able to filter on multiple hf's with the
same field-name, BUT there is a little bug in the code. I have pinpointed it to
the following in epan/dfilter/dfvm.c:
...
It actually loops through all the hf's with the same name, but only checks
against the original (first) hf.
svn path=/trunk/; revision=21372
Add a table of DPCs and SSNs that allow to override the protocol that would be choosen
so that the same SSN can use two different protocols in two different DPCs.
I did not believe it someone could have done it, then I saw the captures...
svn path=/trunk/; revision=21321
(Temporarily disable the warnings as errors default on Unix to get
to get the buildbots and people with gcc40 going again until those
additional warnings gcc40 generates can be fixed-I'm working on it
ASAP)
Patch for configure.in which disables by default the treatment of
warnings as errors.
It can be enabled with './configure --with-warnings-as-errors'.
The macro will test first if GCC is present. If it's the case,
HAVE_WARNINGS_AS_ERRORS is defined. All the USING_GCC have been replaced
by HAVE_WARNINGS_AS_ERRORS.
With this switch, people won't suffer from unexpected warnings when
downloading svn sources during the transition time ;)
svn path=/trunk/; revision=21153
* Remove macros_dlg, the DFMacros UAT goes in the menu with all the rest
* in packet-user_encap.c WTAP_ENCAP=XXX has become useless information for the user leave just the DLT#
svn path=/trunk/; revision=20753
* fields of an uat table now are passed using an array of uat_filed_t
* field callbacks take two more userdata arguments
* add some macros to define uat field callbacks.
* uats can be registered as preferences for a specific protocol
- the preference widget is a button that opens the uat's window
* dfilter-macro => reflect changes to API
svn path=/trunk/; revision=20695
32-bit numbers. Separate signed and unsigned accessors have been
added and used where appropriate.
Definitely not for 0.99.5.
svn path=/trunk/; revision=20472
this primarily removes code and simplifies (==eliminates) the need to track the data that is allocated and should potentially be slightly faster than a slab allocator.
however these functions are called A LOT so there might be a performance hit when using emem with full debugging canary values and all the bells and whistles activated.
this change also makes any future attempt to parallellize dissection of frames easier if we just make the ep allocator allocate from a threads specific ep pool.
(something we would have to do anyway to make ep allocations multithreaded)
this works in all my tests so far but needs more test coverage.
svn path=/trunk/; revision=20194