Age | Commit message (Collapse) | Author | Files | Lines |
|
Added support for upcoming Netapp's ONTAP-GX nfsv3 filehandle.
Alex.
svn path=/trunk/; revision=19875
|
|
svn path=/trunk/; revision=19830
|
|
svn path=/trunk/; revision=19697
|
|
Hi,
This patch impelments a dissect for the SCSI SSC Medium Partition Page.
Patrick
svn path=/trunk/; revision=19495
|
|
USB dissector
svn path=/trunk/; revision=19480
|
|
This patch fixes a transposition of the orders of
Set Attribute Number
Set Attribute Length
In the page oriented get and set attributes CDB parameters format
Ref SCSI-OSD T10/1355-D Revision 10 section 5.2.2.2
svn path=/trunk/; revision=19460
|
|
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
|
|
You find attached a patch file (against svn 19058) to dissect packets
produced by the Linux kernel packet generator.
svn path=/trunk/; revision=19251
|
|
Hi folks,
We think we've found a bug in STANAG 5066 SIS layer dissector.
Problem is at S_EXPEDITED_UNIDATA_INDICATION S_Prim's parser
and occurs when we receive a U_PDU via expedited unidata channel.
Dissector tries to parse first 2 bytes of U_PDU as a header size of type
21 s_prim (S_UNIDATA_INDICATION). But, this is not an wanted process on
that parser. Maybe, it was forgotten unchanged from
S_UNIDATA_INDICATION dissector while copying it. So it shows
data (U_PDU) 2 bytes short. Moreover, if data is just 1-byte, TCP datagrams
receive TCP checksum error.
Confirmed.
It was indeed a "copy-paste-did not edit correctly" bug.
While going over the code once more, I found:
1 - One bug in the heuristic. (Changed '&&' to '||')
2 - One to-do that was already done. (Removed the /* TODO */)
3 - One to-do that is now done. ;-)
svn path=/trunk/; revision=19210
|
|
Also, there is still an outstanding issue regarding the default use of
the "media" dissector. The way it is currently coded there is no way to
have a heuristic decoder when a content-type header is specified.
In this way if there is a decoder for a specific content-type then it
will be used, then the heuristic decoders have a chance, and finally the
default of either the media-type decoder of the http_payload decoder.
svn path=/trunk/; revision=19208
|
|
svn path=/trunk/; revision=19205
|
|
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
|
|
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
|
|
svn path=/trunk/; revision=18831
|
|
Hi,
The attached file should fix the following two bugs in the AJP dissector.
1) The dissector doesn't know about CPING/CPONG
2) The dissector misinterprets multiple requests in one connection if a
prior request has a Body request part.
svn path=/trunk/; revision=18780
|
|
Peter Racz
svn path=/trunk/; revision=18733
|
|
KISMET protocol support
svn path=/trunk/; revision=18728
|
|
Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
(DSTE) as per RFC 4124.
svn path=/trunk/; revision=18727
|
|
REXEC support
svn path=/trunk/; revision=18642
|
|
fix dissection of get_auth_attr
svn path=/trunk/; revision=18619
|
|
- Makefile.am fix: elua_register.h generation + checking serialized
- ProtoField.new(..) parameter parsing fix and changes
- enabling gui_enabled() function in Lua (typo fix, thanks to Tamas Regos)
svn path=/trunk/; revision=18611
|
|
SSL updates and DTLS support
svn path=/trunk/; revision=18582
|
|
svn path=/trunk/; revision=18432
|
|
fix for ieee802.11 aid
svn path=/trunk/; revision=18411
|
|
RSerPool protocol stack and four new protocols
svn path=/trunk/; revision=18409
|
|
make icmp timestamps more readable
svn path=/trunk/; revision=18406
|
|
svn path=/trunk/; revision=18325
|
|
A dissector for "TiVoConnect Beacon" traffic.
svn path=/trunk/; revision=18308
|
|
ethereal.com -> wireshark.org
mailing lists and addresses
ETHEREAL -> WIRESHARK
Man pages
Automake/Autoconf names
svn path=/trunk/; revision=18271
|
|
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
|
|
svn path=/trunk/; revision=18206
|
|
refactyored from the affix patch by Christoph Scholz
svn path=/trunk/; revision=18112
|
|
libraries with which we link libethereal, fixing the reopened bug 878.
svn path=/trunk/; revision=18019
|
|
library. If that's not done, it leaves to ethereal or other binaries
using it the job of linking adns within them. This behaviour is
unreliable and breaks when using the --as-needed flag for GNU ld
(version 2.16 or better 2.17).
svn path=/trunk/; revision=17969
|
|
svn path=/trunk/; revision=17879
|
|
you find attached a patch for dissecting MPLS OAM pdus
as defind in Y.1711 ITU-T doc.
svn path=/trunk/; revision=17779
|
|
svn path=/trunk/; revision=17738
|
|
1. Decode A11 Session Update message
2. Decode A10 3GPP2 (GRE Payload Type 0x88D2) packets with the following attributes
- Flow Control
- Segmentation
- SDI Indicator
- Flow Discriminator
svn path=/trunk/; revision=17717
|
|
ppp/bpdu update
svn path=/trunk/; revision=17367
|
|
svn path=/trunk/; revision=17266
|
|
I have developed an external plugin to enable ssl decryption in
ethereal.
Me
- Remove unnecessary $Id$ from acinclude.m4
- Added packet-ssl-utils.h to Makefile.common
- Fixed a few warnings
TODO
- Lots of warning fixes (see separate mail)
- Reformat function headers to read like the others do
(return value<newline>function-name...)
- Test on Windows platform
- Review the patch to packet-ssl.c and new files packet-ssl-utils.[hc]
svn path=/trunk/; revision=17156
|
|
epan/dissectors/ncp2222.py - Fixes the NCP group values for all NCP's. Also fixes some additional return values and cleanup.
gtk/ncp_stat.c - Fixes the NCP group values for SRT.
gtk/service_response_time_table.c:
The SRT is broken if you hit the reload button or apply a filter. The table isn't cleared so each item in the list is duplicated and the second entries remain with initial values. This patch clears the GTK_CLIST so that the redundant entries no longer appear.
svn path=/trunk/; revision=17139
|
|
New OICQ dissector.
Me:
removed some not needed variables and some unneeded includes.
svn path=/trunk/; revision=16940
|
|
kpasswd over tcp support
svn path=/trunk/; revision=16885
|
|
After investigating the time-sequence graphs (Stevens and tcptrace) produced
using an FTP capture file supplied by Eduardo Segura
(see http://www.ethereal.com/lists/ethereal-users/200512/msg00153.html )
I've identified several problems in tcp_trace.c.
The problems mostly involve incorrect determination of the lower/upper
sequence number bounds (for the Y axis) in certain cases (e.g. having to do
with 'partial' conversations).
I've reworked the '...get_bounds' code to handle cases such as:
1. out of order data segments (e.g.: the first segment in a captured
conversation has a higher sequence number than a later segment);
2. 'ack' sequence numbers for initial ack segments in a conversation lower
than the sequence numbers of the initial data segments;
3. maximum 'ack + win' sequence number in a conversation greater than the
max data sequence number;
4. Stevens graph: only use data segment sequence numbers when
determining bounds;
5. TCP RST packet without 'ack' flag: do not try to use the 'ack' seq num from
the packet in this case. (This was the specific cause of the originally reported
problem).
I've also reworked the tcptrace display code slightly to properly handle
the initial ack packet of a sequence;
As an example of the some of the fixes the Ethereal tcptrace style graph
of the following conversation fragment will now be similar to the graph
produced by Tcptrace.
data: seq 10000 len 100
data: seq 10100 len 200
ack: ack 5000 win 6000
ack: ack 5400 win 5600
svn path=/trunk/; revision=16874
|
|
aligned in the About box).
svn path=/trunk/; revision=16850
|
|
svn path=/trunk/; revision=16849
|
|
svn path=/trunk/; revision=16848
|