This patch adds decodes for 802.11n information elements. Since 802.11n
isn't a formal standard yet they are not using the final packet
structures or ie type numbers. But there are already 802.11n pre
release devices out there and these decodes do seem to correctly decode
the IEs that they use.
svn path=/trunk/; revision=20725
- enhance dissection or ErrorDecode2 (ErrorCode1 rta_err_cls_protocol specific) - a lot more of ErrorCode1/ErrorCode2 combinations still to go ...
svn path=/trunk/; revision=20724
- new: ICBALogicalDevice2::PBAddressInfo
- enhanced: GROUPERRORDEF
simplify ett registration
add a callback for SAFEARRAY data dissection
svn path=/trunk/; revision=20723
Wireshark complains about bogus udp length when processing last fragment of UDP data.
It compares length field from UDP header with payload size of last fragment.
Attached is my attempt to fix this by referring to tvp->length instead of pinfo->iplen - pinfo->iphdrlen.
Also set some items attribute to generated.
svn path=/trunk/; revision=20722
sminmpec_values array is marked as just "export" instead of "WS_VAR_IMPORT" in
epan/sminmpec.h. This prevents its using in Windows builds of plugins directly.
svn path=/trunk/; revision=20720
Steve has modified a while ago hex_str_to_bytes to handle Cisco MAC
format (xxxx.xxxx.xxxx). It did not test the nullity of the third and
fourth byte (*r, *s) which is however done for the second byte. The test
on the second byte is done as well in the following conditional tests.
If this test is not mandatory thanks to the return value of isxdigit (at
least on GNU/Linux and guess it should be the same on any platform), it
would be better to follow the same logic in all tests cases for the
comprehension of everyone (... which /could/ even, with luck, be turned
in a faster code).
Here is a light patch to follow the logic of the conditional tests done
in the function.
svn path=/trunk/; revision=20714
Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net>
I discovered that Wireshark K12xx detects the type of input (E1 timeslot or ATM)
based on the extra information. My previous patch to enable Wireshark to open
K12xx files with no extra information (extra_len equals 0 in SRCDEST record)
failed to give later dissectors the input type.
Attached is the patch to correct this for ATM PVC. It adds VPI/VCI/CID information
for display in the dissected tree (in k12_open function). k12_read and k12_seek_read
are also made more robust. These are reverse engineered based on hexeditor
and constants found in tektronix configuration file. Please apply the patch.
svn path=/trunk/; revision=20705
Fix an obvious error in the nfs4 stateid parsing. The stateid is used in a number of common operations (such as open and setattr), so this caused a lot of misparsing.
svn path=/trunk/; revision=20700
* 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
Wed, Jan 31, 2007 at 7:24 PM
To: wireshark-dev@wireshark.org
Hello,
Please consider for checkin the following new dissectors, for the FMP protocol.
FMP (File Mapping Protocol) is the network protocol basis for EMC's HighRoad (MPFS) technology. Highroad is used to allow multiple clients to share access to NAS-shared files while allowing clients to directly access data volumes (via, for example, Fibre Channel or iSCSI). EMC currently uses this technology in our Celerra NAS servers, and we're currently in the process of open sourcing portions of the technology.
FMP actually consists of two ONC/RPC-based protocols - the core FMP protocol, and FMP/Notify. The latter is used as an asynchronous callback to inform clients of status changes, such as lock revocation.
We'd like to offer these dissectors to Wireshark users for help in debugging or otherwise troubleshooting MPFS-related problems. There are still a few minor changes that need to be made ( i.e. a handful of fields that aren't decoded) but the dissector is overall fairly complete and very usable.
Let me know if there are questions or feedback, or otherwise if other info is needed (like sample captures, which I don't want to send out to the mailing list).
Thanks,
Ian Schorr
EMC Corporation
svn path=/trunk/; revision=20679
Gerald Combs