type, not a "how do I format addresses?" type; declare it as such, and
remove the comment that pointed out that the type field had the wrong
(C) type.
svn path=/trunk/; revision=24297
add dissection of the 16 byte header prior to the NDR data when NDR is
transported as a blob ontop of !dcerpc
like the LOGON_INFO in the PAC in kerberos
svn path=/trunk/; revision=24289
Add a dissector for the Scripting Service Protocol provided as part of the
RSPLIB package. RSPLIB is an Open Source implementation of the upcoming
Reliable Server Pooling standard. The scripting service is an application
for load distribution, based on Reliable Server Pooling.
From me:
Shorten the protocol name to SSP.
svn path=/trunk/; revision=24276
1) update SDP dissector with new IDs from assigned numbers document
https://www.bluetooth.org/apps/content/default.aspx?doc_id=49709
2) decode attribute IDs in an "attribute ID list" parameter (previously it
showed raw number only)
3) removed some duplicate entries in vs_service_classes
svn path=/trunk/; revision=24267
Added support for Symbian OS btsnoop.
The bluetooth HCI layer in Symbian OS can be configured to log all packets to a
file. The log format, "btsnoop" is based on the RFC1761 "snoop" format - but
differences in the header make it incompatible.
The btsnoop format supports logging of these formats:
"H1" (raw HCI packets without framing)
"H4" (HCI UART packets including packet type header)
"H5" (HCI 3 wire UART packets including framing)
"BCSP" (HCI bluecore serial protocol including framing)
"H1" and "H4" are section numbers in the original v1 bluetooth specifications,
but still used colloquially - wireshark's existing support for Linux bluez HCI
logs uses the "H4" name.
In practice, the "H1" format is used for H5,BCSP and USB HCI logs, as the HCI
packet logs are mainly useful for debugging higher layers, bluetooth profiles
and bluetooth applications.
From me:
Deleted some unused prototypes.
Mark an unused parameter.
svn path=/trunk/; revision=24263
L2CAP dissector is missing retransmission & flow control modes (these were
introduces in BT 1.2 specification)
Configuration commands were not fully decoded because of a bigend/littleend
issue
L2CAP commands had the wrong length set to the protocol tree by reading from
the wrong buffer offset
Also the dissect_options() function consumes all remaining data in the L2CAP
packet, which prevents decoding of other commands which follow a config
request/config response in the same packet.
From me:
Mark an unused parameter.
svn path=/trunk/; revision=24262
I was capturing an RTP stream the other day which contained JPEG images
streamed according to RFC 2435. However, Wireshark reported them as malformed.
After some debugging of the Wireshark code it turned out that the decoding of
JPEG images which contain a quantization table was incorrect. I have attached a
patch to correct the decoding.
svn path=/trunk/; revision=24246
The decoding of a SubscribeCOVProperty packet is not properly decoding the
Monitored Property Identifier field. It leaves a number of decoded bytes at the
end as data.
svn path=/trunk/; revision=24245
2) Support for RFC 3909 - cancelRequest extendedOperation
3) Support for RFC 3062 - passwordModify extendedOperation
4) Column information for ExtendedRequest, SearchResultRef and AbandonRequest
5) Column information for multiple LDAP operations in the same packet (uses " | " separator)
svn path=/trunk/; revision=24195
I have written the attached patch to improve the userfriendly-ness of the
summary displayed in the last column of the packet list for IGMP packets.
The current code only tells the user the type of packet (REPORT, LEAVE, QUERY),
but doesn't include any information about what multicast group is joined to or
left. Worse, for IGMPv3 Reports the user cannot tell quickly if the multicast
group is joined-to or left, without having to look at the inside of the packet
to know the type of report (include all, include none, exlude none, exclude
all, etc.).
svn path=/trunk/; revision=24190
Corrected display of attributes from previous patch (24165)
For V2, if field length was 0, do not display the empty field. This makes it
easier to read. I only did V2 as I do not have means to test V1.
svn path=/trunk/; revision=24189