Label issues with last week's release

[Carter Bullard]

Hey Dave,
This is what I get for the two filters…

thoth:common carter$ ra -r * -b - not src co ZZ
(000) ldh      dsr[19][4]
(001) jeq      #0x0             jt 4	jf 2
(002) jeq      #0x5a5a          jt 3	jf 4
(003) ret      #0
(004) ret      #150

thoth:common carter$ ra -r * -b - src co ZZ
(000) ldh      dsr[19][4]
(001) jeq      #0x0             jt 4	jf 2
(002) jeq      #0x5a5a          jt 3	jf 4
(003) ret      #150
(004) ret      #0

So this looks right, on Mac OS X 10.8.4 with gcc i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00).  Load the 16-bit value 4 bytes into the COCODE DSR, and if not zero, compare with "ZZ".

And, the filters works fine on this and all the 64-bit Linux's I have.
Are you on a 32-bit machine?

Carter



On Sep 3, 2013, at 12:30 PM, David Edelman <dedelman at iname.com> wrote:

> For flow records with valid cocode values including a lot of ZZs I get
> 
> ra -r * -b - src co ZZ
> 
> (000) ldh dsr[19][4]
> (001) jeq #0x0  jt 4. jf 2
> (002) jeq #0x5a5a jt 3 jf 4
> (003) ret #0
> (004) ret #150
> 
> 
> If I filter on not src co ZZ I get all the records including ZZ
> 
> 
> Dave Edelman
> 
> 
> On Sep 3, 2013, at 12:09, David Edelman <dedelman at iname.com> wrote:
> 
>> I'm not sure if this is related. If not I'll start a new thread. 
>> 
>> The sco and dco values are not making it into the cocode DSR correctly. I tried to kill the DSR and the clients still baulk. 
>> 
>> The ralabel config seems to play a role for some of the problems
>> 
>> Filtering on co also seems to be a problem and the generated BPF code looks odd. This may call for the use of offsetof in 64 bit environments. 
>> 
>> More when I can send samples. 
>> 
>> 
>> Dave Edelman
>> 
>> 
>> On Sep 3, 2013, at 8:13, Carter Bullard <carter at qosient.com> wrote:
>> 
>>> Hey Craig,
>>> So I'm back and its time to fix this label problem, as others are starting to report it.
>>> It may take me a little while to figure out where we are on this bug.  If you have any
>>> new observations, sending to the list would be great...
>>> 
>>> Radium is stable for you ( > 4 days ?).
>>> 
>>> Please send a separate email around your rastream() issue.  Better to have separate threads for each problem.
>>> 
>>> Carter 
>>> 
>>> On Aug 26, 2013, at 9:52 PM, Craig Merchant <cmerchant at responsys.com> wrote:
>>> 
>>>> Carter,
>>>>  
>>>> From previous emails sent to the list I was under the impression that you had discovered some differences between how ralabel handles labels vs how radium does.  Did those differences get resolved in the latest release?  I’m still seeing some issues with duplicate labels…
>>>>  
>>>> For example…  For IP 10.10.10.10, my label file (in order) looks like:
>>>>  
>>>> 10.10.10.0/24 internal,DC2,I5-Apache-UI
>>>> 10.10.10.10  apacheui,ri5
>>>>  
>>>> Yet my Argus events look like:
>>>>  
>>>> "1377565200.000,e *,tcp,63.166.75.3,0,->,10.10.10.10,9051,1599,685729,SRPA_SPA,56,300.000,478334,207395,2.857,2.467,0.443,US,ZZ,daddr=internal#DC2#I5-Apache-UI#apacheui#ri5#apacheui#ri5#apacheui#ri5#apacheui#ri5"
>>>>  
>>>> Not sure why the host-specific label is repeated 4 times, but that’s consistent with other events I’m seeing.
>>>>  
>>>> In other (good) news, it would seem like the radium crashing issue has been fixed in the latest release.  I know we are a corner case as far as radium stability goes, but it’s been running for four days without stopping and that’s a positive change.
>>>>  
>>>> We may be experiencing some issues with rastream though…  I sent you our rastream search and the shell scripts it calls at the end of each time interval.  It’s been working fine for a few days, but it seems to have lost track of the files it’s processing, so no new events are coming in and old files aren’t being deleted.  I’ll dive deeper into that that this week and see if I can narrow down the problem.
>>>>  
>>>> Thanksa again for all the fixes!
>>>>  
>>>> C
>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130903/cd25ae03/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6837 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130903/cd25ae03/attachment.bin>