new code (rc.31) on the server
Carter Bullard
carter at qosient.com
Wed Oct 11 14:38:58 EDT 2006
Hey Rick,
I worked the bit length and masking strategies, and found an issue, so the
next round of code may fix all things. I'll try to have it on the server by
tomorrow night!!!
Carter
rick wrote:
>>Hey Rick,
>>Ahhhhhh, programatic progress!!! I'll do some testing either tonight or Thur. There are a few spots where it could be wrong, filter wise. I'll also set the len correctly when its 0. I agree, if you put 0 for a cidr len, you take saddr out of the model.
>>
>>
>>
>
>the v6 addresses a bit annoying :) the way they being stored.. :/
>
>
>
>>I suspect that we'll need to have separate v4 and v6 specifiers, since saddr/54 doesn't make much sense for v4 addresses?p
>>
>>
>>
>
>while looking at it i thort this may be the case.. but then looking at how
>you had actually handled it you could get away with leaving it as it is..
>
>it was concerning... i was thinking the same thing.. will have to change to
>v6 but then that becomes dependent on filter.. and the filter may not necc
>specify addresses so will be hard to determine if it is correct or not
>anyway.. cos you may just end up with someone saying daddr6/56 on a v4
>address anyway..
>
>since you have the union in the ArgusIPAddrStruct (or whatever it was
>called.. it is too early i can't remmeber :)).. then anything less than 32
>will be in the first 4 bytes of the struct anyway.. this is fine for both v4
>(which will only use the first) and v6 so not a real issue doing it that
>way...
>
>you will have issue of a match all filter.. or a filter that is supposed to
>match v6 amd v4 with a daddr or saddr... but you can't have both in a model
>either.. as that also doesn't make much sense for aggregating..
>
>so user just has to think about it and specify different rules for both v4
>and v6 since they can't go together unless you want a /0 mask really :\
>
>but that being sed using the same 'mode' isn't an issue.. will just yeield
>bad results if you don't think about it.. but not much can do about that :)
>
>
>
>
More information about the argus
mailing list