> 1) The current code tries to guess the endianness of the packet using some
> heuristic rules. That would be unnecessary if the dissector could read (or
> maybe remember) the first non-empty segment from client to server (where
> the client tells the server the endianness that will be used for all the
> data stream). Is there any way to do it? This is related to question 2.
>
> [Yes, the guessing code could be still useful if the first segment has not
> been captured...]
I would rewrite
That would be unnecessary if the dissector could read (or maybe
remember) the first non-empty segment from client to server ...
with
That would be unnecessary for sessions where the first non-empty
segment from client to server was captured ...
which makes it clearer that the heuristics are still required.
Currently, we don't, for connection-oriented protocols, have any way for
the transport-layer dissector to tell the dissector it calls that a
given piece of data is the first piece of data in a new connection, so,
for now, the heuristics are required for all sessions.
Is there any reason *not* to use the heuristics for all sessions?
> 2) X11 replies (server->client) cannot be really dissected unless the
> dissector can read (or remember) the matching request (client->server).
> The matching request is up on the TCP stream. Any ideas?
>
> I thought to keep a cache of these data: i.e.
>
> the dissector gets called for the first packet ->
> endianness[tcp_connection_id]=get_end(packet)
> the dissector gets called for a request ->
> insert(pending_reqs, tcp_connection_id, req_type, req_serial)
> the dissector gets called for a reply ->
> extract(pending_reqs, rev(tcp_connection_id), req_serial) => req_type
That's what we do for other protocols where you need the request in
order to dissect the reply, e.g. ONC RPC and SMB transactions.
> [sorry for being such verbose]
>
> The problem is that the packets could be out of order on the wire: in that
> case the cache would be useless.
"Out of order" in what sense? Are you talking about a reply being seen
before the matching request?
> Is there an "easy" way to solve this? Maybe exploiting the support for
> desegmentation of TCP?
Currently, we don't have any mechanism in the TCP dissector for
supplying segments, in order, to the dissectors below it. I have been
working on one, but I don't expect that it'll be available in the short
term.