argus-clients-3.0.0.rc.20

[Peter Van Epp]

On Mon, Jul 31, 2006 at 02:39:25PM -0400, Carter Bullard wrote:
> Hey Peter,
>    So argus-3.0 is going to deal with ipv6 completely different from
> argus-2.x so we have an interesting issue.   Argus-2.0 reports ipv6
> as a L2 flow, with a next protocol header of ipv6.   Argus-3.0 will
> report ipv6 as a L3 flow, at a minimum, so if you mix and match,
> for converted records you will see proto ipv6, but see ethernet
> addresses in the flow identifier, and that will be slightly confusing.

	If thats all we've got and it is consistsnt with what 2.0.6 would 
output then I'd say thats good enough (people with real V6 may disagree and
should have the say though :-)).

> 
>    In your case, because you have VLAN tags, the next hop protocol
> in the ethernet flow is 129, which is CLNS.   My version of argus-3.0
> clients, prints 'clns', yours prints 'well', which is incorrect.   
> Currently the
> argus  2.x -> 3.0 converter wants to use the ether headers next
> hop protocol as the flow identifier protocol, rather than the 802.1P/Q
> (VLAN tag) next hop id.      So, what to do?   I'm not sure.

	The last patch I posted fixes at least some of this. V3 now reports
the protocol as v6 rather than well (which was a bogus ip_id field in many
of the records which may or may not be important) and therefore matches what
2.0.6 says on the same data which is I think the correct answer. 

> 
> I would like to do what argus-3.0 is doing now, which is downgrade
> the flow to CLNS, and because we have no ipv6 identifiers, just
> toss any info related to that encapsulation.   Probably not a great  
> idea.
> 
>     Need some opinions here.  So if anyone has a comment, chime in.
> 
>    I'll try to get argus-3.0 to conform to 2.x when the syn/synack  
> status
> is unknown '.?.'
> 
>    I have the code to deal with the 'TIM' vs 'CON' flags, but it  
> doesn't seem
> to be working?  ....... so if you have a record that is incorrect,  
> send the
> argus record so I can debug.
> 
>    I need an IGMP record to see what's up with the ipid.
> 
> Carter
> 

	I have a fix which fixes most of those that works most of the time
It splits setting the source and dest indicators baased on whether there are 
source or dest packets or not (they are currently both set at the top of the
routine without regard to whether there are packets or not). It still gets 
screwed up under some conditions but I now think that is lack of initialization 
because it seems to depend on packets coming before. In an isolated stream 
the failing packets display correctly. I'm still (slowly) poking at that.  
I think that is likely to fix the igmp issue too (it shouldn't have a dest IP
id because it doesn't have any dest packets) however a quick test indicates
thats still an issue too:

1151432429.128613,1151432860.570569,1,431.441956,431.441956,142.58.60.61,239.255.255.253,igmp,22,0,0,0,1,0,100,0,16,0,2,0,1.85,0.00,0.00,0.00,0.0000,0.0000,3848370891,q,0:11:24:97:47:52,1:0:5e:7f:ff:fd,->,,,CON,s[8]="........",,,,8857,,,0x0280,,0xd21c
1151432429.128613,1151432860.570569,1,431.441956,431.441956,142.58.60.61,239.255.255.253,igmp,,,0,255,1,255,100,0,16,0,2,0,1.854,0.000,0.005,0.000,0,0,229.97.122.203, v       ,0:11:24:97:47:52,1:0:5e:7f:ff:fd,->,,,INT,s[8]="........",,,,8857,,,0x0280,,0x1cd2,0x0000


Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada