PfFlowd not sending packets
-
Not sure how a bridge might interact with that, but have you used tcpdump on both the "wan" and "lan" side when looking for the netflow packets?
I do not know how to do that really, but I am currently running tcpdump grepped looking for 9996 and nothing on that port number is showing up.
tcpdump | grep 9996 is what I ran.
-
Try:
tcpdump -ni <wan interface=""> port 9996</wan>
Where <wan interface="">is the physical WAN interface, like em0, vr1, etc.
If that doesn't find anything, use the LAN interface.Or just use Diagnostics > Packet capture and fill in the box to filter by port.</wan>
-
Nothing. I tried bge0, bge1, bridge0, nothing. Diagnostics did the same thing.
This is really annoying. I have been trying for weeks now to find something that I can use to track our internet usage and can find…nothing!
-
Should I file a bug report?
-
Unfortunately I can't replicate your issue, it works for me when I set it up.
It's a little more manual process but you could try softflowd
http://doc.pfsense.org/index.php/Exporting_NetFlow_with_softflowd -
That was going to be my next step.
You are not testing in Bridge mode though. That can be considered it's own bug.
-
Actually I am testing in bridge mode as well as normal mode. I get netflow packets either way.
It does appear that the collector system had to be online before the packets started going though.
-
What were you using as a collector?
-
Nothing at the moment, just sending the packets at a random BSD VM.
-
Nothing at the moment, just sending the packets at a random BSD VM.
Sorry, I thought you meant the collector software. I have been sending to my own PC and still nothing.
-
Softlowd is sending packets.
One question, the doc says this:
Launching softflowd
To launch softflowd at boot time, backup your configuration, and above the line, add the following line.
<shellcmd>softflowd -i em0 -v 5 -m 50000 -n 10.0.0.100:9999</shellcmd>What file is it referring to? I am not familiar enough with BSD, more of a Linux guy.
-
Ignore that bit, install the shellcmd package and add it there. It's in the raw config.xml, and the shellcmd package can maintain that entry for you rather than editing the config xml manually.
-
The way some applications bind, they don't function entirely correctly with bridging unless the IP they're using is on the bridge itself (which is only supported in 2.0), I suspect that's what you're seeing here. The only thing I've seen to date that has issues in that scenario is nmap but other applications likely have the same issue.