| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The "overlay" definition in print-sflow.c is correct, but the actual
extract for printing is using EXTRACT_32BITS rather than EXTRACT_64BITS,
which leads to an incorrect report for speed.
Reviewed-By: Guy Harris <guy@alum.mit.edu>
|
| |
|
|
|
|
|
|
| |
Thanks to some traces sent my way by Gavin McCullagh, and a comparison
against the output of inMon's sflowtool, I can confidently say "Yes
Virginia, there is an enterprise other than zero." Which means lest we
start trying to decode something as what it is not, we best actually
look at the enterprise field and make sure it is one we recognize.
|
| |
|
|
|
|
|
|
|
|
| |
around and created a bunch of smaller routines to more easily support
printing of both expanded and non-expanded counter and flow samples.
I've done simple testing of non-expanded counter and flow, and expanded
counter, but I don't have expanded flow at present with which to test.
So, that part of the change is only compile/eyeball tested.
Reviewed-and-tweaked-by: Guy Harris <guy@alum.mit.edu>
|
| |
|
|
|
|
|
|
|
|
|
| |
When dissecting a sample, or a flow or counter within the sample, make
sure we don't run past the length in the sample/flow/counter header.
This also means we count the sample length down as we process the
contents of the sample, so we only add what, if anything, remains of the
sample to the pointer into the packet, and subtract that from the
remaining data length in the packet, which means we properly handle
packets with multiple samples.
|
|
|
SFLOW protocol
|
