Age | Commit message (Collapse) | Author | Files | Lines |
|
svn path=/trunk/; revision=54089
|
|
"new" style dissectors.
Now that "bytes consumed" can be determined, should tcp_dissect_pdus() take advantage of that?
Should tcp_dissect_pdus return length (bytes consumed)? There are many dissectors that just call tcp_dissect_pdus() then return tvb_length(tvb). Seems like that could all be rolled into one.
svn path=/trunk/; revision=53198
|
|
svn path=/trunk/; revision=51852
|
|
svn path=/trunk/; revision=51692
|
|
svn path=/trunk/; revision=51688
|
|
The LLRP Standard 1.0.1 defines the ProtocolID Parameter as 8 bit value (see
LLRP Standard 1.0.1 document, page 138, AccessSpecParameter) but Wireshark
treats it as 16 bit value and therefore doesn't recognize the
EPCGlobalClass1Gen2 protocol type and marks the whole packet afterwards as
invalid.
svn path=/trunk/; revision=49991
|
|
svn path=/trunk/; revision=48686
|
|
svn path=/trunk/; revision=48685
|
|
was done using textual search+replace, not anything syntax-aware, so presumably
it got most comments as well (except where there were typos).
Use a consistent coding style, and make proper use of the WS_DLL_* defines.
Group the functions appropriately in the header.
I ended up getting rid of most of the explanatory comments since many of them
duplicated what was in the value_string.c file (and were out of sync with the
recent updates I made to those in r48633). Presumably most of the comments
should be in the .h file not the .c file, but there's enough churn ahead that
it's not worth fixing yet.
Part of https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8467
svn path=/trunk/; revision=48634
|
|
svn path=/trunk/; revision=45017
|
|
Manually expand some of the macros in packet-llrp.c that were only being used
in one place. Makes for a more traditional set of hf_ registrations.
svn path=/trunk/; revision=44817
|
|
clang and cppcheck.
svn path=/trunk/; revision=44687
|
|
svn path=/trunk/; revision=44686
|
|
svn path=/trunk/; revision=44646
|
|
function in the switch statement. This keeps us from calling through an
uninitialized pointer for custome parameter numbers other than
LLRP_VENDOR_IMPINJ (as warned of by at least some compilers).
svn path=/trunk/; revision=44624
|
|
Major enhancements to the LLRP dissector.
svn path=/trunk/; revision=44621
|
|
Also:
- In one case #include <epan/prefs.h> not needed;
- Do some minor whitespace reformatting.
svn path=/trunk/; revision=44537
|
|
Create/use extended value strings for several value-string arrays;
Minor whitespace cleanup.
svn path=/trunk/; revision=43960
|
|
sub-dissector/col_...()/expert...() fcns
svn path=/trunk/; revision=43226
|
|
svn path=/trunk/; revision=42387
|
|
Given the problems with the original attempt, and the fact that there's a new
version of the protocol spec out (v1.1), I took a crack at writing a new
dissector from scratch. It doesn't decode the fields within the message
parameters (there are far too many to bother with for an initial draft), but it
decodes everything else.
Even though it's not complete, I feel it's worth checking in as an intermediate
step (assuming it passes review), since it's still far better than nothing, and
adding full parameter-field decoding is going to take a lot of time simply for
transcribing all the different fields.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1957
svn path=/trunk/; revision=42383
|