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
I have developed a plugin for Pro-MPEG FEC packets over RTP (see
previous posts on ethereal-dev). I have added a page and example capture
file to the Wiki (http://wiki.wireshark.org/2dParityFEC). The source and
Windows makefile for the plugin are attached. Unfortunately I do not
have access to other systems so this plugin has been tested on Windows
only.
The attached version of my plug-in has only had the copyright header
added.
I will translate this into a proper dissector rather than a plug-in as
requested, but this may take a little time as I have a lot of other
things
to do at the moment.
Me:
Convert into a normal dissector
Reorder / reformat code a bit
Added Marks name to the top of the file.
svn path=/trunk/; revision=18908
This patch adds a new dissector for the daytime protocol (like the time
protocol, but the date and time is send as a text string). This protocol and
dissector work s over TCP or UDP.
svn path=/trunk/; revision=18823
A disassembly module I wrote for Pegasus Lightweight Stream Control, a protocol used by some cable set-top boxes for video-on-demand.
svn path=/trunk/; revision=18807
- allow SDP to parse the IP address + port for the MSRP session from the
path attribute
- setup an MSRP conversation using this address, whose data points back
to the SDP frame
- link to the SDP setup frame while dissecting MSRP (can be switched off
by a preference)
- I also changed sdp.media.port to be a numeric field
svn path=/trunk/; revision=18806
this dissector will not yet detect when ppp is passed over the rfcomm link
but the old code to detect and deescapt the ppp data is still in the dissector, though ifdeffed out to serve as inspiration when ppp over rfcomm captures are made available.
the only captures i have with rfcomm are for raw serial communications so they dont contain any ppp frames. :-(
svn path=/trunk/; revision=18221
acl chandle + direction + l2cap-CID to uniquely identify a single specific
flow of PDU packets.
So we need to pass the chandle upp from acl to l2cap at least.
It would have been nice to handle this using "conversations" but the bluetooth
stack does not eaily map to the idiom host:port<->host:port
instead in bluetooth you have unidirectional flows that are identified by ACL-chandle:L2CAP-CID:direction and additional state held inside l2cap would attach two such flows together into a "conversation".
Bluetooth packets themself only indentify "half" of the two way conversation.
svn path=/trunk/; revision=18218
the fragment reassembly from the old patch is commented out since it has to be redone completely using emem and se_trees the proper way.
but to do this i would need example captures of fragmented bluetooth traffic first.
svn path=/trunk/; revision=18149
Ronnie Sahlberg