Florian,

There is a existing bug ticket open for this:

 http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2376

Thanks-Mike


Florian Lohoff wrote:
> On Thu, Apr 10, 2008 at 10:21:28AM -0400, Jeff Morriss wrote:
>   
>> Andrew Feren wrote:
>>     
>>> I've recently started getting a number of false positive hits from the new
>>> Redback Lawful Intercept heuristic.  I was going to try and tighten up the
>>> heuristic a bit, but I can't find any sort of protocol specification.
>>>
>>> Basically I use some protocols that start with a 32 bit version number. 
>>> However since the version numers are all well below 65,535 the first two
>>> bytes are always 0.  The Redback heuristic sees this as an end of header
>>> marker and returns true.
>>>
>>> My thought was to return false if the first avptype is an end of header
>>> marker, but without a protocol spec I can't be sure that this is actually 
>>> an
>>> invalid redback packet.
>>>
>>> Anyone have any more details?
>>>       
>> The dissector came in via 
>> http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2320
>>
>> I'm not sure if Florian is a member of this list or not.  Florian, can 
>> you provide some pointers?  (What about the Wiki page I asked for after 
>> checking in the dissector?)
>>     
>
> I thought about packets beeing all zero after the patch got added 
> and that might end up beeing taken by the redbackli dissector
> accidentally.
>
> I'll try to cook up a patch tonight which checks for the existance of some 
> "essential" avp's ...
>
> Basically the protocol is non published and i reverse engineered it
> from traces. Its a packet header for forwarding lawful intercept traffic
> from a RedBack Smartedge Router to some device which passes the traffic
> onto some government bodies. To differentiate the different lawful
> intercept session one can either use a "label" and/or a "lawful intercept
> id". At least one of those two and a sequence number should be present
> before an "eoh" avp ...
>
> Attached a simple trace - the traffic is artificial which is the cause
> for the udp packet encapsulated being broken ...
>
> Flo
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wireshark-dev mailing list
> [email protected]
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>   
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Reply via email to