Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Using "ip.id" for dissector_add

From: Lars Friedrichs <larsfriedrichs@xxxxxx>
Date: Tue, 01 Jan 2008 12:47:02 +0100
Hi Guy,

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?!
Did anyone ever write LUA dissectors? I have seen this page:

http://wiki.wireshark.org/Lua/Dissectors

and keep wondering if the postdissector would give me the ip.id value. I would then use Lua instead.
Bye
Lars

Guy Harris schrieb:
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.
    
If you're used to C, you'd read the line as if it tried to get one 
particular assumption, namely that the sub-dissector exists, straight.

Perhaps what that line needs to do is to return an error indication, 
with add_dissector() returning a Boolean, with FALSE being an error 
indication.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev