Gavin -
I was able to use tcpreplay to massage the MAC and IP addresses to send
some of your sflow PDUs to the ntop 4.0.3 I am running on Ubuntu
Maverick (64 bit) and can see messages like:
skipping
flow_sample_element 2 length error (expected 8, found 11)
SFABORT: 3
skipping
SFABORT: 1
flow_sample_element 2 length error (expected 1342177280, found 4)
SFABORT: 3
flow_sample length error (expected 136, found 63)
SFABORT: 3
Fri Apr 15 17:03:38 2011 **WARNING** Invalid packet received. Skipped.
SFABORT: 1
SFABORT: 1
SFABORT: 1
SFABORT: 1
SFABORT: 1
SFABORT: 1
SFABORT: 1
thought the binary doesn't seem to go belly-up.
("skipping" is something I've added....) Looking at the routine
skipTLVRecord() in plugins/sflowPlugin.c I see this:
static u_int32_t skipTLVRecord(SFSample *sample, u_int32_t tag, char
*description, int deviceId) {
char buf[51];
u_int32_t len;
if(SFLOW_DEBUG(deviceId)) traceEvent(CONST_TRACE_INFO, "skipping
unknown %s: %s\n", description, printTag(tag, buf, 50, deviceId));
len = getData32(sample, deviceId);
// sanity check
if(len > sample->rawSampleLen) SFABORT(sample, SF_ABORT_EOS);
else skipBytes(sample, len);
return len;
}
But in current sflowtool.c skipTLVRecord() looks like:
static void skipTLVRecord(SFSample *sample, u_int32_t tag, u_int32_t
len, char *description) {
char buf[51];
sf_log("skipping unknown %s: %s len=%d\n", description, printTag(tag,
buf, 50), len);
skipBytes(sample, len);
}
I'm at a loss to understand what the added len = getData32() is for -
that will advance the pointer in the parsing another 32 bits, but I
thought that would start advancing into the next flow record. as for
why sflowPlugin.c's skipTLVRecord is returning a value I've no idea
because nothing calling it actually uses it.
There is a place in the current sflowtool.c code where they do that
getData32(sample) thing - in readSFlowDatagram - because at that point
they don't have a length pulled.
I would need the "history" of sflowtool.c to know, but I'm guessing this
was a latent bug in an older version, and switching to passing-in the
length to skip to skipTLVRecord and making the suitable change to
readSFlowDatagram may be what is involved.
This would indeed be getting exposed thanks to the unknown enterprise id
of 8800 in some of those flow records.
Anyhow, that is what I have at the moment. It would really help if
someone who knows the history of that code could chime-in.
rick jones
_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop
