Pascal Quantin wrote:
> Hi
> 
> 2010/10/25 Pascal Quantin <[email protected] 
> <mailto:[email protected]>>
> 
>     Hi,
> 
>     2010/10/25 Jeff Morriss <jeff.morriss.ws
>     <http://jeff.morriss.ws>@gmail.com <http://gmail.com>>
> 
>         Pascal Quantin wrote:
>          > Hi,
>          >
>          > since revision 34640, none of UDP heuristic dissectors I use
>         (LTE-MAC,
>          > LTE-RLC or LTE-PDCP) work: all the frames are decoded as ADwin
>          > configuration protocol.
>          >
>          > When looking at the code in function dissect_adwin_config() (file
>          > packet-adwin-config.c), the heuristic seems a bit weak:
>          > [...]
>          >     length = tvb_reported_length(tvb);
>          >
>          >     if (pinfo->ipproto == IP_PROTO_UDP &&
>          >         ! (length == UDPStatusLENGTH
>          >            || length == UDPExtStatusLENGTH
>          >            || length == UDPMessageLENGTH
>          >            || length == UDPMessageLENGTH_wrong
>          >            || length == UDPInitAckLENGTH
>          >            || length == UDPIXP425FlashUpdateLENGTH
>          >            || length == UDPOutLENGTH))
>          >         return (0);
>          > [...]
>          >
>          > Could it be possible to do something more robust ?
> 
>         Oops, sorry.  We're discussing some stronger heuristics in bug 5324.
> 
> 
>     While you iterate on it, would it be possible to add a preference
>     (off by default) stating whether the ADwin heuristic dissectors are
>     activated or not (like what is done in packet-mac-lte.c for example) ?
> 
> 
> Having a second look at the code, it's even worse than what I first 
> thought. Any pinfo->ipproto different from IP_PROTO_UDP or IP_PROTO_TCP 
> will be intercepted by the ADwin dissector.
> 
> Adding something like:
> 
>     if (pinfo->ipproto != IP_PROTO_UDP && pinfo->ipproto != IP_PROTO_TCP)
>         return (0);
> 
> Solved the issue on my side.

Checked in rev 34644, thanks!
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Reply via email to