[netflow-tools] problems with pfflowd that don't happen with softflowd

[Damien Miller]

Michael W. Lucas wrote:
>>That is possible: softflowd's timeouts are pretty conservative,
>>especially for TCP - 30 minutes post-FIN. You can tune these on the
>>commandline though :)
> 
> 
> Ah, you learn something every day.
> 
> That 30 minutes can be important when you want to, say, grovel through
> netflow data looking for port scans and worms and whatnot.  :-)

gah, it it not 30 minutes, it is really 5 minutes post-FIN. I probably
started out writing 300 seconds, but botched changing the units. My
apologies.

>>When you run tcpdump, did you try the "-T cnfp" to get it to parse the
>>NetFlow packets? What collector are you using?
> 
> I'm using flow-tools' flow-capture.
> 
> Under softflowd, -T cnfp on the collector shows:
> 
> 08:08:01.118622 IP a.b.c.d.52011 > w.x.y.z.9318: NetFlow v5, 179.007 uptime, 1114862881.120821000, #0, 29 recs
> 08:08:01.118770 IP a.b.c.d.52011 > w.x.y.z.9318: NetFlow v5, 179.007 uptime, 1114862881.120821000, #0, 30 recs
> 08:08:01.118918 IP a.b.c.d.52011 > w.x.y.z.9318: NetFlow v5, 179.007 uptime, 1114862881.120821000, #0, 29 recs
> 08:08:01.118923 IP a.b.c.d.52011 > w.x.y.z.9318: NetFlow v5, 179.007 uptime, 1114862881.120821000, #0, 29 recs

OK, that looks like a softflowd bug there - it is not updating the
sequence number correctly. I can see one bug there (fix attached), but
I don't see how it could give rise to all the sequence numbers being
zero like this...

> with pfflowd, we see:
> 
> 08:10:20.540514 IP a.b.c.d.57523 > w.x.y.z.9318: NetFlow v5, 8.741 uptime, 1114863020.542900000, #0, 12 recs
> 08:10:20.540519 IP a.b.c.d.57523 > w.x.y.z.9318: NetFlow v5, 8.741 uptime, 1114863020.542953000, #12, 12 recs
> 08:10:20.540662 IP a.b.c.d.57523 > w.x.y.z.9318: NetFlow v5, 8.741 uptime, 1114863020.542971000, #24, 12 recs
> 08:10:20.540668 IP a.b.c.d.57523 > w.x.y.z.9318: NetFlow v5, 8.741 uptime, 1114863020.542987000, #36, 11 recs
> 
> The only difference I see is that with softflowd, the # doesn't
> increment.

There might be more to it. Could you try capturing with
"tcpdump -s1500 -vvvTcnfp"? It will show some more details.

> I'm willing to accept that there's something in flow-capture that's
> choking on something with pfflowd.  Still, it seems that there will be
> more people on this list using flow-capture than there will be on the
> flow-capture list using pfflowd and softflowd.  :-)
> 
> I'm also using the same flow-capture binary to collect netflow from a
> Cisco router, so I somehow think that there's some detail with pfflowd
> that I just don't have right.

pfflowd doesn't fill in all the NetFlow fields - it just doesn't get
enough information for the pfsync interface to do it. IIRC some programs
may not like getting a 0 interface index.

You could try the second attached patch, which is a very crude hack that
might fool it (just hardcode a couple of interface numbers).

-d
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: softflowd-seqno.diff
Url: http://lists.mindrot.org/pipermail/netflow-tools/attachments/20050430/3d06409c/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pfflowd-fake-ifndx.diff
Url: http://lists.mindrot.org/pipermail/netflow-tools/attachments/20050430/3d06409c/attachment-0001.ksh