numerous changes, most notably:
1) BACnetStatusFlags is bit string, not enum, in NotificationParameters
2) Fixes many places where enclosing context tags were not handled properly.
3) Simplify tag decoding logic. Change to explicit decoding in many
instances rather
than read tags in a loop and do a switch based on tag number. Looping
ignores out-of-order and other types of tagging errors.
svn path=/trunk/; revision=19410
few things to be fixed:
- // comments,
- not every hf_xxx used might be registered
some packages from the current h248 dissector are still missing.
svn path=/trunk/; revision=19407
- Indicate direction of DCH Data in info column
- Assume EDCH payload CRC if 2 bytes are left over (previous test was broken)
svn path=/trunk/; revision=19405
- set_filter() : sets the main window filter
- reload() : reloads the current capture file
- copy_to_clipboard() : copies its first arfg to the clipboard
- open_capture_file() : opens a capture file for viewing (still broken)
svn path=/trunk/; revision=19404
always register
itself on the port from the preferences (defaults to 0) upon launch.
This allows the user to right-click and use decode as.
svn path=/trunk/; revision=19403
Modifie the VNC dissector to desegment
the "server cut text" message type for cases where the cut text is in
the next tcp segment from the first part of the message.
svn path=/trunk/; revision=19402
account for this extra reserved byte in the ahs length so that the reconstructed cdb has the correct length and does not contain one extra byte at the end
svn path=/trunk/; revision=19387
This is used to display the field underlined and to allow the user to double-click on it (like FT_FRAMENUM) to open the URL in the configured browser.
Example usage in the x509ce and logotype certificate extensions.
svn path=/trunk/; revision=19383
iscsi: when iscsi transfers a cdb that is alrger than 16 bytes, the first 16 bytes are transferred in the normal place in the header and ther remainder of the cdb is transported inside the AHS.
reassemble these cdb into a proper tvb before passing it to the scsi dissector
svn path=/trunk/; revision=19376
Attached is a patch for consideration that changes the title in the
preferences notebook to be the full description of the preference (but
leaves the short name in the preferences list on the left).
svn path=/trunk/; revision=19370
add a test for (length > 0) in the dissector (dissect_xot_pdu), to avoid to
allocate a new tvb when the XOT decoded length is null.
svn path=/trunk/; revision=19365
Please find enclosed a patch about Mobile Network Prefix option in NEMO.
Following RFC3963 Section 4.3, lenght of this option is 18, not 16.
svn path=/trunk/; revision=19363
it is absolutely amazing that none of the iscsi implementors and users of wireshark had noticed this breakage and reported it. they apparently do not use wireshark.
svn path=/trunk/; revision=19362
various changes to the existing scsi dissector to start allowing different commandsets to be implemented in their own dissector files to prevent the scsi dissector to become as huge as the parlay dissector
svn path=/trunk/; revision=19360
- dissection of TIPCv2 internal messages now shows
all fields used according to the protocol spec
- there should be no issues with the current protocol
spec anymore
- the info column is more concise and gives more
details
- some code beautifications
svn path=/trunk/; revision=19354
I've two patchs for FMIPv6:
- FBU encapsulated in FNA are not correctly parsed;
- there is an error when parsing LLA Option.
svn path=/trunk/; revision=19351
I have figured out one of the fields in the MAPI
EcRRegisterPushNotification packet. The field is a UDP port number that
the client wants the Exchange server to send new mail notifications on.
These notifications are on a port > 1023 and are always 8 bytes long.
It looks like I would add the function name to the
dcerpc_mapi_dissectors[] for the register push notification. What would
my new function need to do besides display the field?
Thanks,
Steve
Here is a patch to add this functionality. It displays the notification
port and the notification payload (not sure what the payload itself
means yet). It also dynamically registers each notification port found
with a new dissector (that I called newmail for lack of a better name -
I'm open to suggestions) that displays the notification payload. This
is all undocumented by Microsoft in their usual fashion.
I also changed the code to always display the mapi.opnum field;
currently, the mapi.opnum is only displayed when the
dcerpc_mapi_dissector is null.
Steve
svn path=/trunk/; revision=19350
This patch adds support for dissecting ontap's nfsv4 filehandle,
as well as some updates to nfsv3 filehandle as well in the nfs
dissector.
Alex.
checked in with minor changes
svn path=/trunk/; revision=19345
Here are some patches and a new module to introduce the notion of Tcap context for a Tcap transaction. For each Tcap transaction, several parameters, like session identifier, start time or OID, will be saved in a hash table, to keep these informations available for the next messages. This context is then given to the upper layer, and can be used, for example, to generate transaction-associated statistics.
Moreover, the Upper protocol, detected in the Begin of the TCAP transaction ( according to the OID ), is saved in the context, and will be reused for the next messages of the transaction. This help the decoding of SS7 messages, without any SSN configuration in the "wireshark preferences".
You will have too, the possibility to apply a filter to see only the messages related to a TCAP transaction. (tcap.srt.session_id=XXX)
To enable the use of the Tcap context, you have 2 new parameters in the preferences,
- SRT, enable search for a Tcap context for any TCAP messages
- persistentSRT, keep the Tcap context, even after the transaction has been closed. This is mandatory with Wireshark, to have a clean display of the stats.
There is 2 new timers in the preferences for the statistics, to tune the retransmission timeout, and messages lost timeout.
svn path=/trunk/; revision=19341
this protocol is not too interesting yet since only the function names of this interface is known but it is more that no dissection at all
svn path=/trunk/; revision=19333
Luis Ontanon