Wireshark-dev: Re: [Wireshark-dev] Using "ip.id" for dissector_add
From: Michael Tüxen <[email protected]>
Date: Tue, 1 Jan 2008 13:16:20 +0100
Hi Lars,

are really sure that your protocol looks at the ip-id field,
not the ip.proto field?

The ip-id field is not intended yo be used for protocol demultiplexing,
but for IP reassembly. This field is normally under control of
the sender which is free to put any value into it, for example
the value you chose. So be prepared that you receive packets which
are not your protocol. Also IP fragmentation will not work...

Why are you misusing the ip.id field? What kind of protocol are
you considering?

Best regards

On Jan 1, 2008, at 12:04 PM, Lars Friedrichs wrote:

Hi Abhik,

thanks for the reply but at least looking at packet-sctp doesn't help me
here. I see that it uses "ip.proto" but that is not what I need since
the protocol does not rely on the "ip.proto" field but on "ip.id".
Yust to get this straight:
A protocol registers its header fields, shouldn't all these fields be
possible to be added a subdissector to? Maybe anyone can explain line
697 of packet.c to me:
As I am not used to C I would read that line as if it tries to get some
assumptions about "sub_dissectors" straight. I hoped it would be the
following lines:
   switch (sub_dissectors->type) {

   case FT_UINT8:
   case FT_UINT16:
   case FT_UINT24:
   case FT_UINT32:
        * But you can't do a port lookup in any other types
        * of tables.
would the failing be done by the last line? So the g_assert above fails
because of the following code? Because that code would mean to me that
if the sub_dissector that was found has non of the given types it would fail. But I checked the type of the ip.id field - it is FT_UINT16 and so
it is in the list and so it should not fail.
Something may be wrong with my eyes or my understanding of things here.
Could anybody help me clear that up?


Abhik Sarkar schrieb:
Hi Lars,

Perhaps the table you are looking for is "ip.proto". Check packet- sctp
for example.

Good luck!

Wireshark-dev mailing list
[email protected]