Add support for parsing some X11 replies and events (and
the framework for handling X11 errors it looks like) to the
existing X11 code, which parses X11 requests.
It parses what is the most difficult part of the replies/events,
they Keycode stuff by parsing the Keyboardmapping replies and etc,
and then KeyPress, KeyRelease events and some related stuff (used
for a specific project).
Adding support for parsing the rest of the event/replies should not
be difficult, I think it will mostly consist of going through every
event/reply and add the missing calls for each dataitem i.e. register
the data, the remaining the eventcodes/replies are pretty
straightforward if I remember correctly.
All events and replies are reported, it's the "detailed" (-V option)
that's missing for most.
The replies, events and errors are listed in the Info column,
and are summarized in the protocol summary line.
Bogus if (tree) { } constructs have also been fixed.
List over other misc. stuff added:
- handle multiple outstanding requests.
- add AllocNamedColor to list of requests expecting a reply.
- body for parsing error replies.
- each packet can be sent to us multiple times, try to handle that.
- change request_length display to be what the client actually sends
for x11_request, not what it means (don't multiply by four).
- add some more opcodes expecting a reply (gone through all listed
in the ref. now, so should be complete).
- use hashtable and sequencenumber for matching reply to request.
svn path=/trunk/; revision=9520
to export to other dissectors.
Describe the "if (tree)" construct and its sense by introducing 2 operation
modes of Ethereal:
(a) operational dissection (tree == NULL)
and
(b) detailed dissection (tree != NULL).
Fix some typos.
svn path=/trunk/; revision=9495
also fixes a case where we'd put the same string into the Info column
twice.
Put the packet sequence number into the Info column for segmented invoke
and result PDUs, even if we don't try to reassemble them.
Don't put an entry into the protocol tree for the payload if there isn't
any payload.
svn path=/trunk/; revision=9493
by pass-through proxying dissectors such as the SOCKS dissector; it does
the work of processing a TCP segment, including desegmentation. Export
the "next sequence number" value to subdissectors, so they can use it
when calling "dissect_tcp_payload()".
Use that in the SOCKS dissector.
svn path=/trunk/; revision=9489
that dissectors for pass-through proxying protocols such as SOCKS can
allow the subdissectors they call to ask that desegmentation be done.
svn path=/trunk/; revision=9488
