create a new dissector table where MAC algorithms for dns/tsig can be registered.
register gssapi for the algorithm "gss.microsoft.com" since this is what w2k uses when performing dns updates.
svn path=/trunk/; revision=16895
also change one (of several:-( ) arrays to be accessed through accessor functions so proper bounds checking is done.
there are many other inbstances of arrays in this dissector that are accessed with no proper bounds checking and the same thing should be done for them
svn path=/trunk/; revision=16891
Hi list,
On the Ethereal Wiki is a CDP capture of a Broadcom BCM1100 VoIP chipset.
It has a power consumption TLV, which was not yet dissected. The attached
patch does that.
svn path=/trunk/; revision=16890
"error_t" is defined elsewhere on at least some versions of Fedora Core,
so it collides with our usage; use "expert_comp_dlg_t" instead.
svn path=/trunk/; revision=16889
make the dissection of the ACL check the type for each individual ACE and only dissect as access mask and sid those ACEs we know how to handle.
this prevents ethereal from dumping on w32 if we encounter any of these "special" ACE entries, such as the ones used for storing location data for offline files.
svn path=/trunk/; revision=16881
While looking into bug 239 I found a type mismatch in proto.c. Even
though tree_is_expanded is defined as a (gboolean *) the memory
allocation is carried out using sizeof (gint *). The attached patch
fixes this.
svn path=/trunk/; revision=16877
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
- Better nameing of tfs_ arrays
- Name and dissect "version" field (previously unknown)
- Name and dissect "add tag scheme" (previously unknown)
- Add lots of comments about meanings in the port data
- The first byte in the set command is probably some salt value
svn path=/trunk/; revision=16871
Taking a random dissector from the list on the Wiki I picked packet-enip.c. Nothing wrong with this one, I still ememified it.
From Bart Braem:
packet-mip.c does not have support for all registration denials by the foreign agent, code 77 was left out. The attached patch fixes that.
svn path=/trunk/; revision=16868
Fix a memory leak found by valgrind:
Although dir isn't a directory it may still use memory
packet-xml.c:
Reformat the relevant function in packet-xml.c to be readable on systems
where a tab is 8 spaces.
svn path=/trunk/; revision=16865
Three patches here:
eth-ed-2.diff
-------------
1) The handling of HashSet Answer messages was wrong
2) Add dissection of some more eMule extension packets to do with
error recovery
eth-bt-1.diff
-------------
New versions of the Azureus BitTorrent client implement a new extension to the protocol, which is effectively a text based encapsulation of the binary BitTorrent protocol, embedded within the BitTorrent protocol. Who knows why they thought that was a good idea, but this patch can pick apart their new headers.
eth-bt-2.diff
-------------
By registering a normal dissector as well as the heuristic one, BitTorrent shows up on the Decode As... list so you can manually override its mistake.
svn path=/trunk/; revision=16856
Ulf Lamping