This patch adds support for key-mgmt session attributes in SDP (defined in RFC 4567). The patch also contains a Multimedia Internet KEYing (MIKEY is defined in RFC 3830) dissector plugin for "mikey" key-mgmt data.
svn path=/trunk/; revision=20977
Admittedly not much, so if you have any ideas what the rest means or where
I'm wrong please provide feedback.
As tapa uses udp 5000 and ip protocol 4, I needed to add a hack for the
ip part to properly dispatch betweeen ipip and tapa-tunnel (actually I
was unable to turn the ipip dissector into a heuristic dissector :-)
svn path=/trunk/; revision=20971
- move dcom-cba and pn-rt files into profinet plugin (where they really belong)
- move some common pn functionality into new packet-pn.c/h instead of having duplicate code
svn path=/trunk/; revision=20825
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
Generally found within a file (.p12 or .pfx) or as a directory attribute (userPKCS12 from iNetOrgPerson).
Wiki page and sample file to follow.
svn path=/trunk/; revision=20416
I have added a new dissector for DMP (STANAG 4406 Direct Message
Profile) as defined in STANAG 4406 Annex E. The DMP protocol has no
assigned UDP port number yet, so the default value in this dissector
is 0 (I suppose this is som sort of "disabled"?) until we get this
registered.
The dissector has been tested on OSX Intel/PowerPC and Solaris SPARC.
Changes in this patch:
* Added DMP dissector
* Added a new CRC table and functions in crc16.c
* Made NonDeliveryReasonCode and NonDeliveryDiagnosticCode available
from X.411
* Made NonReceiptReasonField and DiscardReasonField available from X.420
svn path=/trunk/; revision=20133
This is a new dissector for STUN v2, that is currently in WGLC at the IETF.
- Keep packet-stun.c for the RFC 3498 protocol, plus the STUN and TURN
drafts up to draft-ietf-behave-rfc3489bis-02 and
draft-rosenberg-midcom-turn-08, as there is some huge deployments using
this. There will be no modification to this dissectors in the future,
excepted perhaps to add support for retransmission or things like this.
- Add a new dissector packet-stun2.c for the new STUN (currently in
WGLC), the STUN relay-usage (formerly known as TURN) and the other
usages that will be added in the future (IPv6, NAT Behavior, etc...).
svn path=/trunk/; revision=20131
New dissector for ETSI DCP (ETSI TS 102 821).
Code rearranged to look more like other Wireshark dissectors and some warnings/errors
on Windows fixed.
svn path=/trunk/; revision=19981
The RDM protocol has been accepted as ANSI standard E1.20-2006. The following patch updates the decoder to that spec.
At the same time it is promoted to a build-in dissector.
svn path=/trunk/; revision=19596
this is a wrapper protocol to store SCSI frames inside usb bulk data transfers
the dissector is far from complete but does
track ITL and ITLQ structures and will also call the SCSI dissector to
dissect the SCSI CDB.
what is still missing is handling of data in/out and scsi responses
at least it will now display the SCSI CDB and dissect it. woohoo
svn path=/trunk/; revision=19589
packet-cisco-wireless.c is actually trying to dissect WLCCP:
I have attached a dissector I wrote from scratch for the
frames that I'm seeing. It has #defines for the field offsets and
lengths so it should be easier to merge. I also attached a sample
capture with one of the frames that I'm seeing. There are more fields
in the frame I haven't yet figured out, hopefully your dissector has
those that I'm missing.
Me: - Commented in wlccp over udp as well, it works most of the time.
- Leave the file packet-cisco-wireless.c in for the time being to
copy over knowledge until no usable info is left in the file.
svn path=/trunk/; revision=19447
dissector for Enea's LINX protocol?
A protocol spec is available at <http://www.enea.com/templates/Extension____8947.aspx>. The source of the kernel module could be obtained from Enea by sending a request to "linx at enea dot com".
Currently they use ethertype 0x9999 which is not registered at IEEE.
svn path=/trunk/; revision=19430
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
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
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 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
New protocol: epl v1
Hi,
in addition to the recently submitted dissector for the EPL v2 protocol,
this is the dissector for the first version of the EPL protocol.
Best Regards,
David
svn path=/trunk/; revision=19125
this patch adds support for MPEG2 transport stream packets in RTP (type
MP2T). It currently dissects the headers of the MPEG2 packets
svn path=/trunk/; revision=19023
new protocol: veritas low latency transport
---
Attached is a patch file that adds a new dissector for the LLT protocol
(Veritas Low Level Transport, used for server clustering). They use
ethertype 0xCAFE even though it isn't assigned to them :(. There are
other fields and possibly other message types directly between servers
it does not yet dissect as no one outside of Veritas knows what they
are. This dissector understands the one people will run across most -
multiple servers broadcasting these heartbeats all over the place. I
figured out these fields through many Internet searches.
I will add the protocol to the Wiki after it is committed.
Thanks,
Steve
svn path=/trunk/; revision=18944
Luis Ontanon