Hi Michael,
Could you tell me which Ethereal version you patched the X11 dissector?
Regards,
Olivier
PS see answer to your question at the bottom of this mail.
| -----Original Message-----
| From: Michael Shuldman
|
| Biot Olivier wrote,
| > | From: Michael Shuldman
| >
| > [...]
| >
| > | When doing a quick test now I noticed that it crashed due
| > | to the following code in dissect_x11_request():
| > |
| > | /* In the interest of speed, if "tree" is NULL, avoid building a
| > | protocol tree and adding stuff to it if possible. Note,
| > | however, that you must call subdissectors regardless of whether
| > | "tree" is NULL or not. */
| > | if (!tree)
| > | return;
| >
| > If tree is NULL, then ethereal/tethereal is not interested
| in the *details*
| > of the protocol. The if (tree) construct allows a developer
| to short-circuit
| > code that only displays protocol details
| (proto_XXX_DO_YYY() calls). It is
| > important however that you don't put important protocol
| state computations,
| > packet reassembly, conversation setup etc into such a
| block, otherwise you
| > need a dfilter or you need to select a given packet in
| order to have this
| > computed (since then tree will be different from NULL).
| >
| > To word it differently:
| >
| > 1. if tree is NULL,
| > then [t]ethereal should only run the non-display code that
| is required to
| > correctly understand the protocol (check the validity if
| applicable, update
| > the Info and Protocol column, build conversations if
| applicable, same for
| > reassembly if the protocol supports this, maybe state
| information like
| > matching requests with replies or keeping track of session
| capabilities, and
| > of course also the handoff to other dissectors.
| >
| > 2. if tree is not NULL,
| > then [t]ethereal wants to render the protocol in all its
| glory (read: be
| > able to access all internal details of the protocol such as
| the different
| > protocol field names and their values, etc. as required by
| the evaluation of
| > a dfilter).
|
| Ok, I understand. I attach a new version of packet-x11.c, only
| changes are some added checks for if we have a tree or not.
|
| > | Also one other problem, tcp desegmentation needs to be switched
| > | on for the parsing of keypresses and related stuff to work,
| > | the X11 keyboardmap is too big to fit in a single ip packet.
| >
| > It is not a problem, the TCP protocol provides a protocol preference
| > allowing the end-user to control TCP reassembly for
| higher-level protocols.
|
| I understand, but not why it's defaulting to being switched off.
| At one point I wondered if I was supposed to "cache" the previous
| packets my self, but I couldn't get that to make sense when that
| must be what the tcp dissector does when desgmenting is switched on.
When doing reassembly, Ethereal potentially consumes much more memory than
without reassembling the packets. This is the main reason why is is not
enabled by default.
Regards,
Olivier