Argus with PF_RING DNA clusters

Carter Bullard carter at qosient.com
Mon Oct 1 13:21:17 EDT 2012


Oh yes, that would be modifying the packet.
This is not necessary, and there are " ways "
to solve this.  I'll definately look at this tonight !!
Sorry for the delay, lots on my plate at the moment.

Thanks !!!!!!
Carter


On Oct 1, 2012, at 1:03 PM, Chris Wakelin <c.d.wakelin at reading.ac.uk> wrote:

> I've just found in ArgusModeler.c
> 
>> ArgusCreateIPv6Flow (struct ArgusModelerStruct *model, struct ip6_hdr *ip)
>> {
> 
> ...
> 
>> 
>> #ifdef _LITTLE_ENDIAN
>>      ip->ip6_plen = ntohs(ip->ip6_plen);
>> #endif
> 
> Is that modifying the packet or a copy? It would match my symptoms of
> truncated IPv6 packets :-/
> 
> Best Wishes,
> Chris
> 
> On 27/09/12 22:38, Chris Wakelin wrote:
>> Yes, 3.0.6.1 with a fix to ArgusSource.c to allow PF_RING DNA interfaces
>> and Intel virtual interfaces (ethX at Y):
>> 
>>> @@ -4182,7 +4187,7 @@
>>>    if (device == NULL)
>>>       return;
>>> 
>>> -   if (strstr(device->name, "dag") || strstr(device->name, "nap")) {
>>> +   if (strstr(device->name, "dag") || strstr(device->name, "nap") || strstr(device->name, "dna") || (strstr(device->name, "eth") && strstr(device->name, "@"))) {
>>>       for (i = 0; i < src->ArgusInterfaces; i++) {
>>>          if (src->ArgusInterface[i].ArgusPd && (pcap_fileno(src->ArgusInterface[i].ArgusPd) > 0))
>>>             bzero ((char *)&src->ArgusInterface[i].ifr, sizeof(ifr));
>> 
>> 
>> Best Wishes,
>> Chris
>> 
>> On 27/09/12 22:32, Carter Bullard wrote:
>>> Hmmmm, not thinking that we modify packets, but will look.  Your
>>> running argus-3.0.6+ ?  Thanks for the bug report !!!!
>>> 
>>> Carter
>>> 
>>> On Sep 27, 2012, at 5:00 PM, Chris Wakelin
>>> <c.d.wakelin at reading.ac.uk> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I've been having some more problems with ARGUS and PF_RING DNA
>>>> clusters. It turns out that with ARGUS running, the other
>>>> applications reading the same packets are seeing truncated IPv6
>>>> packets. As soon as ARGUS is stopped, things go back to normal.
>>>> 
>>>> E.g. tcpdump output:
>>>> 
>>>>> 18:45:36.174466600 IP6 truncated-ip6 - 5355 bytes
>>>>> missing!2001:630:53:26:5026:29a2:5863:dbaf.65226 >
>>>>> 2a00:1450:400c:c06::5d.443: Flags [.], seq 2651079285:2651084641,
>>>>> ack 1774208329, win 259, length 5356 18:45:36.174535600 IP6
>>>>> truncated-ip6 - 8160 bytes missing!2a00:1450:400c:c06::5d.443 >
>>>>> 2001:630:53:26:5026:29a2:5863:dbaf.65226: Flags [.], seq 1:8161,
>>>>> ack 1, win 272, options [nop,nop,sack 1 {0:1}], length 8160
>>>> 
>>>> The PF_RING clusters use a zero-copy mechanism which means that
>>>> each application is seeing the exact same chunk of memory. Is it
>>>> possible that ARGUS is modifying this, in particular for the IPv6
>>>> handling?
>>>> 
>>>> The "select() returning immediately" problem is still there, but
>>>> the PF_RING authors say they're working on a fix. They don't think
>>>> the IPv6 issue is related.
>>>> 
>>>> Best Wishes, Chris
> 
> 
> -- 
> --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
> Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
> IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 2908
> Whiteknights, Reading, RG6 6AF, UK              Fax: +44 (0)118 975 3094
> 



More information about the argus mailing list