Using "ip.id" for dissector_add

Hi there,

I have an obscure protocol I am writing a dissector for. It relies on
the ip.id value set to a certain value (253) so I want to add my
dissector to that value:

void proto_reg_handoff_lusc(void) {
/* registriert das Protokoll samt CallBack für den Dissector mit
Hinweisen auf die automatische Dekodierung */
        static gboolean initialized = FALSE;
        if (!initialized) {
                lusc_handle = create_dissector_handle(dissect_lusc,
proto_lusc);
                global_lusc_ipid_mark = 253;
                dissector_add("ip.id", global_lusc_ipid_mark, lusc_handle);
        }
}

I get an error while wireshark is initializing:
00:43:08          Err  file packet.c: line 697 (dissector_add):
assertion failed: (sub_dissectors)
Aborted (core dumped)

If I read and understand the sources correct it seems that ip.id is not
a known dissector_table but how can I change that? Using "tcp.port"
gives the expected result so I am sure it has to do with "ip.id" being
used with dissector_add.
Can anyone solve my problem?

Thanks,

Re: Using "ip.id" for dissector_add

Hi Lars,

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

Good luck!
Abhik.

On Jan 1, 2008 12:36 PM, Lars Friedrichs <larsfriedrichs <at> gmx.de> wrote:
> Hi there,
>
> I have an obscure protocol I am writing a dissector for. It relies on
> the ip.id value set to a certain value (253) so I want to add my
> dissector to that value:
>
> void proto_reg_handoff_lusc(void) {
> /* registriert das Protokoll samt CallBack für den Dissector mit
> Hinweisen auf die automatische Dekodierung */
>         static gboolean initialized = FALSE;
>         if (!initialized) {
>                 lusc_handle = create_dissector_handle(dissect_lusc,
> proto_lusc);
>                 global_lusc_ipid_mark = 253;
>                 dissector_add("ip.id", global_lusc_ipid_mark, lusc_handle);
>         }
> }
>
> I get an error while wireshark is initializing:
> 00:43:08          Err  file packet.c: line 697 (dissector_add):
> assertion failed: (sub_dissectors)

Re: Using "ip.id" for dissector_add

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:
    g_assert(sub_dissectors);
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:
...
        break;
...
    default:
        /*
         * But you can't do a port lookup in any other types
         * of tables.
         */
        g_assert_not_reached();
    }
would the failing be done by the last line? So the g_assert above fails

Re: Using "ip.id" for dissector_add

Lars Friedrichs wrote:

> 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".

Really?  The IP identification field, which is not guaranteed to have 
*ANY* particular value in an IP packet?  The *ONLY* guarantee you have 
about the ID field is that all fragments of a fragmented IP datagram 
have the same ID field.

IPv4 has a "protocol" field that indicates what the protocol is for the 
payload of an IP datagram; why would any field other than the protocol 
field *EVER* be the one to use to specify the code used to process the 
data in the payload of an IP datagram (except for a misdesigned protocol)?

> Yust to get this straight:
> A protocol registers its header fields, shouldn't all these fields be
> possible to be added a subdissector to?

Not if, in practice, there is nothing useful that all packets with the 
same value of one of those fields have in common that would cause all 
packets with that value, and no packets without that value, to be 
dissected by a particular subprotocol.

> Maybe anyone can explain line
> 697 of packet.c to me:
>     g_assert(sub_dissectors);
> As I am not used to C I would read that line as if it tries to get some
> assumptions about "sub_dissectors" straight.

Re: Using "ip.id" for dissector_add

Re: Using "ip.id" for dissector_add

Lars Friedrichs wrote:

> thanks for your reply. I know that the protocol is really misbehaving in 
> several ways but I am not the one who wrote it nor the one who may 
> change it. But from your answer I can conclude that it is not possible 
> to do so?!

Yes.

Is the implementation of the protocol assuming that the only other 
implementations of the protocol with which it exchanges packets assigns 
the identification field in such a fashion as not to put arbitrary 
values into the IP identification field?  And, therefore, is it assuming 
that, for example, this will cause no problems if any routers between 
the source and destination fragment any packets?

If so, then the designer of the protocol really needs to study RFC 791 
until their eyeballs bleeed.

If you really need to dissect such an utterly broken protocol, you could 
try adding to the IP dissector code to have an "ip.id" dissector table.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev <at> wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: Using "ip.id" for dissector_add

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
Michael

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:
>    g_assert(sub_dissectors);
> 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:
> ...
>        break;
> ...
>    default:
>        /*
>         * But you can't do a port lookup in any other types
>         * of tables.
>         */
>        g_assert_not_reached();
>    }
> 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?
>
> Thanks,
> Lars
>
>
> Abhik Sarkar schrieb:
>> Hi Lars,
>>
>> Perhaps the table you are looking for is "ip.proto". Check packet- 
>> sctp
>> for example.
>>
>> Good luck!
>> Abhik.
>>
>>
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev <at> wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev <at> wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: Using "ip.id" for dissector_add

Dear all,

comments in-line.

Best regards
Michael

On Jan 1, 2008, at 12:56 PM, Guy Harris wrote:

> Lars Friedrichs wrote:
>
>> thanks for your reply. I know that the protocol is really  
>> misbehaving in
>> several ways but I am not the one who wrote it nor the one who may
>> change it. But from your answer I can conclude that it is not  
>> possible
>> to do so?!
>
> Yes.
>
> Is the implementation of the protocol assuming that the only other
> implementations of the protocol with which it exchanges packets  
> assigns
> the identification field in such a fashion as not to put arbitrary
> values into the IP identification field?  And, therefore, is it  
> assuming
> that, for example, this will cause no problems if any routers between
> the source and destination fragment any packets?
>
> If so, then the designer of the protocol really needs to study RFC 791
> until their eyeballs bleeed.
>
> If you really need to dissect such an utterly broken protocol, you  
> could
> try adding to the IP dissector code to have an "ip.id" dissector  
> table.
but make sure that your dissector is not handling by accident a
packet from a different protocol... Not sure how that can be done,
it depends on the protocol.
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev <at> wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev <at> wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

code coverage measurement for a dissector?

Hi,

I would like to write some tests for my dissector. To check how far I could
cover my dissector code I could use the "--coverage" option of the gcc
(see http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-coverage-375 ).

Where do I have to put the "--coverage" option?
Will this work together with Wireshark?

	Márton Németh
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev <at> wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: code coverage measurement for a dissector?

On Tue, Jan 01, 2008 at 11:37:30PM +0100, Németh Márton wrote:

> I would like to write some tests for my dissector. To check how far I 
> could cover my dissector code I could use the "--coverage" option of 
> the gcc (see 
> http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-coverage-375 
> ).
> 
> Where do I have to put the "--coverage" option?

Set the environment variable CFLAGS to "--coverage" and re-run the 
configure script then rebuild Wireshark with make (see ./configure 
--help for more details).

> Will this work together with Wireshark?

Not sure - this is the first I have heard of that gcc option.  Try it 
out and let us know how it went.

Steve
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev <at> wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev