RTP/ESP v2 records conversion issue

[Carter Bullard]

Hey Cedric,
    I have found the bug and fixed it in rc.26.  I'll try to have the
new code up later today, if not it will be Monday.  The problem
is in ArgusV2NtoH(), where it is getting incorrect dsr lengths
for some RTP DSRs.   My fixed version can read the file you
sent me earlier.

    Your fix will cause a part of the v2 to v3 conversion to stop at the
rtp dsr, which in your case is all right, as you only seem to have
user data DSR's after the rtp chunks.   However, its not the right
fix, all in all.

Carter


On Aug 17, 2006, at 11:56 AM, VIEAU Cédric 172196 wrote:

> Hey Carter,
>
> I'm having issues using argus-clients-v3.rc25 on Debian/Intel with  
> v2 records.
> Records were created with argus-server-2.0.6.fixes.1-10 (debian  
> package).
>
> racount v3 generates the following error:
> "ArgusReadStreamSocket (0xb7d43de0) record length is zero"
> whereas racount v2 doesn't complain.
>
> Using gdb, I found that for one particular record,  
> argus_util.c::ArgusV2NtoH() corrupts the next record writing beyond  
> the current record length in input->ArgusReadBuffer. As the buffer  
> is corrupted, ArgusReadStreamSocket parse bogus records and  
> eventually find a zero length record.
>
> The faulty record seems to be an ESP flow, with a type 0x01 DSR  
> (ip_p = 50), a type 0x14 DSR (ARGUS_V2_RTP_DSR) and some more data  
> after this DSR that doesn't seem to be valid DSRs!
>
> Looking further, I found that it happens for several ESP flow. Most  
> of the time ArgusV2NtoH() ignore the data following the  
> ARGUS_V2_RTP_DSR, but sometimes it randomly matches a valid DSR  
> type, and the corresponding 'struct' might be bigger than the  
> remaining record length.
>
> Here is an exemple (entering ArgusV2NtoH()) :
> --------------------
> (gdb) p/x *(struct ArgusV2FarHeaderStruct *)((char *)argus + 16)
> $322 = {type = 0x1, length = 0x48, status = 0x0}
> (gdb) p/x *(struct ArgusV2FarHeaderStruct *)((char *)argus + 16 +  
> 0x48)
> $323 = {type = 0x14, length = 0x24, status = 0x1}
> (gdb) p/x *(struct ArgusV2FarHeaderStruct *)((char *)argus + 16 +  
> 0x48 + 0x24)
> $324 = {type = 0x83, length = 0x30, status = 0x0}  <=== strange DSR  
> type...
> (gdb) p/x *(struct ArgusV2FarHeaderStruct *)((char *)argus + 16 +  
> 0x48 + 0x24 + 0x30)
> $325 = {type = 0xa5, length = 0xa7, status = 0x4530}
> (gdb) p/x *(struct ArgusV2FarHeaderStruct *)((char *)argus + 16 +  
> 0x48 + 0x24 + 0x30 + 0xa7)
> $329 = {type = 0x8d, length = 0x44, status = 0x50e1}
> --------------------
>
> As a (certainly bad) workaround, I applied the following patch, so  
> the ESP flows stop corrupting the next records.
> --------------------
> --- argus_util.c.orig   2006-08-17 15:55:45.000000000 +0200
> +++ argus_util.c        2006-08-17 15:57:11.000000000 +0200
> @@ -12007,6 +12007,10 @@
>                 break;
>              }
>
> +            case ARGUS_V2_RTP_DSR: {
> +               length = 0;
> +               break;
> +            }
>
>              case ARGUS_V2_AGR_DSR: {
>                 struct ArgusV2AGRStruct *agr = (struct  
> ArgusV2AGRStruct *) farhdr;
> --------------------
>
> I'm really not sure what is wrong here, this is far too deep into  
> argus for me. Carter, I will send you the records file so you may  
> take a look if you find time.
>
> Cedric
>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20060818/9337faa8/attachment.html>