Bandwidthd not seeing P2P traffic
-
I've got bandwidthd running on my box (2.0.3 x64), and everything seems to be working fine, except it doesn't detect any P2P traffic. Instead, it shows all (or at least most) the P2P traffic as just UDP traffic. I'm not really sure where to go with this issue, and my Google-fu is failing me since every mention of bandwidthd seems to include a reference to its ability to see P2P traffic, so my results are useless.
Thanks.
-
There is a promiscuous mode check-box - that will make the ethernet adapter pass in all the traffic it sees. But typically the pfSense LAN is attached to a switch (not hub), and the switch is only sending broadcast packets and packets that have a destination MAC of the pfSense. So there is no way for the pfSense to collect/analyze everything on LAN. To do that, the switch port would also have to be in a "promiscuous" mode that repeated all switched packets up to the pfSense.
Edit: This entry is about seeing local traffic on the LAN - turns out that has nothing to do with the P2P traffic category that bandwidthd reports on, and which the OP was asking about. See further down for a (hopefully) better answer. -
Well, that explains it. I completely misunderstood what P2P meant in this context. I just assumed that it referred to data over P2P protocols (e.g. Bittorrent). Thanks.
-
Apologies - I was thinking about local traffic on the LAN. But actually it does log some P2P protocols on well-known ports. But the source code hasn't been enhanced in a long time (bandwidthd V2.0.1 looks like since 2005?). The readme that comes with the source code download on SourceForge has:
PURPLE Peer2Peer (Lots of TCP ports generally used by P2P software)
The actual code in bandwidthd.c does:
if (sport == 1044|| dport == 1044|| // Direct File Express sport == 1045|| dport == 1045|| // '' <- Dito Marks sport == 1214|| dport == 1214|| // Grokster, Kaza, Morpheus sport == 4661|| dport == 4661|| // EDonkey 2000 sport == 4662|| dport == 4662|| // '' sport == 4665|| dport == 4665|| // '' sport == 5190|| dport == 5190|| // Song Spy sport == 5500|| dport == 5500|| // Hotline Connect sport == 5501|| dport == 5501|| // '' sport == 5502|| dport == 5502|| // '' sport == 5503|| dport == 5503|| // '' sport == 6346|| dport == 6346|| // Gnutella Engine sport == 6347|| dport == 6347|| // '' sport == 6666|| dport == 6666|| // Yoink sport == 6667|| dport == 6667|| // '' sport == 7788|| dport == 7788|| // Budy Share sport == 8888|| dport == 8888|| // AudioGnome, OpenNap, Swaptor sport == 8889|| dport == 8889|| // AudioGnome, OpenNap sport == 28864|| dport == 28864|| // hotComm sport == 28865|| dport == 28865) // hotComm Stats->p2p += size;So, those are the well-known ports that it thinks (back in 2005) are used by P2P protocols.
Might be missing a few modern ones :) and the modern ones will be more evasive in their port use and thus not always this simple to count. -
Ok, so I did understand correctly. Unfortunately, that doesn't really help me :P. My biggest use for bandwidthd is trying to identify computers running P2P software on the network, and I was hoping bandwidthd would do some deep state inspection or something to identify P2P. Fortunately, almost all P2P traffic is UDP, so I can pinpoint it that way.
Now that I think about it, a combination of nmap, snort, and bandwidthd should give me exactly what I need.