[ARGUS] argus 5 ethernet parse error

Ming Fu via Argus-info argus-info at lists.andrew.cmu.edu
Wed Oct 23 08:38:33 EDT 2024


Hi Carter,

I tried the main branch; the problem is fixed.
I applied the diff to the 5.0.0 branch. The problem persists, Is there plan to release an update to 5.0.0 branch?

Regards,
Ming

-----Original Message-----
From: Carter Bullard <carter at qosient.com> 
Sent: Friday, October 18, 2024 12:06 PM
To: Ming Fu <Ming.Fu at esentire.com>
Cc: Argus <argus-info at lists.andrew.cmu.edu>
Subject: Re: [ARGUS] argus 5 ethernet parse error

Hey Ming,
Problem found, fixed and committed to main branch of argus on GitHub/openargus/argus
The errant packet was an 802.3 LLC SNAP encapsulated packet … 
In 802.3 the next protocol field (ether_type) is dependent on the type … the field can either be the packet length or the next protocol (or a vlan tag) ...

We parsed the packet correctly and updated all the needed data structs, but in this particular case, we reported the next protocol using the length ...
This length was slightly special and caused us to say that the packet is an ethernet packet, but we setup to process the IP header that was there, so … boom !!!

Should work fine now …
We will report the 2 packets within the same flow, even though one uses Ethernet II and the other is SNAP encapsulated …. This is correct behavior ...

Carter

> On Oct 17, 2024, at 9:21 PM, Ming Fu <Ming.Fu at esentire.com> wrote:
> 
> Hi Carter, 
> 
> Thank you
> 
> -----Original Message-----
> From: Carter Bullard <carter at qosient.com> 
> Sent: Thursday, October 17, 2024 9:17 PM
> To: Ming Fu <Ming.Fu at esentire.com>
> Cc: argus-info at lists.andrew.cmu.edu
> Subject: Re: [ARGUS] argus 5 ethernet parse error
> 
> Hey Ming,
> I'll look into it tomorrow !!
> Carter
> 
>> On Oct 17, 2024, at 9:15 PM, Ming Fu via Argus-info <argus-info at lists.andrew.cmu.edu> wrote:
>> 
>> Hi,
>> 
>> I noticed that the argus 5.0.0 can crash with an odd Ethernet head.
>> I tried the argus from the head of repo as of today, the code crash at the same location.
>> 
>> (gdb) where
>> #0  0x000055555556baad in ArgusCreateIPv4Flow ()
>> #1  0x000055555556c6bd in ArgusCreateFlow ()
>> #2  0x000055555556c985 in ArgusProcessPacket ()
>> #3  0x0000555555570c64 in ArgusEtherPacket ()
>> #4  0x00007ffff7f7cb95 in ?? () from /lib/x86_64-linux-gnu/libpcap.so.0.8
>> #5  0x00007ffff7f7d004 in ?? () from /lib/x86_64-linux-gnu/libpcap.so.0.8
>> #6  0x00005555555752cd in ArgusGetPackets ()
>> #7  0x00007ffff7f56609 in start_thread (arg=<optimized out>) at pthread_create.c:477
>> #8  0x00007ffff7d04353 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
>> 
>> Looks like the odd ether type caused argus to not fill the IP address when calling into the in ArgusCreateIPv4Flow()
>> 
>> I attached a small pcap file, the second packet is the one that can crash the argus. It has an ether type of 0x0056 rather than the usual 0x8000.
>> 
>> Regards,
>> Ming
>> 
>> 
>> 
>> 
>> 
>> 
>> <twopacket.pcap>



More information about the argus mailing list