Captive portal accounting does not work properly
-
bandwidthd was only explicitly setting "promiscuous true" in the conf file, and leaving it blank if the promiscuous mode GUI check box was off. I have made it always explicitly set "promiscuous true" or "promiscuous false" in the conf file (I think it is better not to depend on the default at all). Now I can change the promiscuous setting in the GUI back and forth, do "ifconfig | grep PROMISC" and the "PROMISC" setting comes and goes from my LAN device.
Note that a bandwidthd man page says that the default is true - http://manpages.ubuntu.com/manpages/lucid/man5/bandwidthd.conf.5.html - which is true in practice!
If someone can look at the pull request, then others can give this a run and see if their bandwidthd reports look more believable in non-promiscuous mode. -
I set promiscuous false in /usr/pbi/bandwidthd-i386/bandwidthd/etc/bandwidthd.conf
Restarted Bwd and ran 2 100MB files through the system. In both times Bandwidthd went from user at 12 MB too 450 MB .
/root(1): ifconfig rl0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500 options=3808 <vlan_mtu,wol_ucast,wol_mcast,wol_magic>ether 00:40:f4:84:09:44 inet6 fe80::240:f4ff:fe84:944%rl0 prefixlen 64 scopeid 0x2 inet 192.168.0.13 netmask 0xffffff00 broadcast 192.168.0.255 nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>) status: active em0: flags=108843 <up,broadcast,running,simplex,multicast,ipfw_filter>metric 0 mtu 1500 options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:04:23:b9:ba:fa inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::1:1%em0 prefixlen 64 scopeid 0x3 nd6 options=1 <performnud>media: Ethernet autoselect (100baseTX <full-duplex>) status: active em1: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500 options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:04:23:b9:ba:fb media: Ethernet autoselect status: no carrier plip0: flags=8810 <pointopoint,simplex,multicast>metric 0 mtu 1500 lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384 options=3 <rxcsum,txcsum>inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 nd6 options=3 <performnud,accept_rtadv>pflog0: flags=100 <promisc>metric 0 mtu 33200 enc0: flags=0<> metric 0 mtu 1536 pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 syncok: 1 ipfw0: flags=8801 <up,simplex,multicast>metric 0 mtu 65536</up,simplex,multicast></promisc></performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast></pointopoint,simplex,multicast></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></broadcast,simplex,multicast></full-duplex></performnud></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,simplex,multicast,ipfw_filter></full-duplex></performnud,accept_rtadv></vlan_mtu,wol_ucast,wol_mcast,wol_magic></up,broadcast,running,simplex,multicast>
-
It would be good to edit /usr/local/pkg/bandwidthd.inc - otherwise when you save settings, reboot (or perhaps even when you restart bandwidthd?) the conf file will be rewritten the old way.
- Find the if(promiscuous) statement at around line 80 and add the 2 lines of "else" as below:
if($promiscuous) $promiscuous = "promiscuous true\n"; else $promiscuous = "promiscuous false\n";
- Save bandwidthd settings on the GUI - this will rewrite the conf file and restart bandwidthd.
- Examine bandwidthd.conf to make sure it has "promiscuous false".
- Run some test data - copy some big things between systems on the LAN, it should not see or count that traffic, copy some stuff through the pfSense box, it should see and count that traffic.
From the post above, it still looks like it is reporting about double? I will try some controlled tests at home…
-
I edited the file and got a syntax error on line 12??
So I copied back the same file from another system and got can't open htt.docs or something error.
I'm going to uninstall and reboot, wait for the next 2.1 snap then reinstall.I saw in the rest of the inc file where the term else was used it was } else { . Don't know if that would make a difference?
If you want to post a working inc file I can replace mine after the next snap. -
It should have just been a matter of adding:
else $promiscuous = "promiscuous false\n";
after the if statement bit. You could add brackets to the whole statement to make it like:
if($promiscuous){ $promiscuous = "promiscuous true\n"; } else { $promiscuous = "promiscuous false\n"; }
It is odd to have a syntax error at line 12???
-
I did some testing. Downloaded a 147MB nanobsd snapshot. The file said it was 150MB on disk - the difference between 1,000,000 byte MBs and 1024*1024 byte MBs - depends who is using what units. The bandwidthd receive counts for my PC, subnet and LAN all went up about 155MB. Allowing for packet overhead, that's pretty good to only have 5MB extra. The sent was a couple of MB (ACKs etc).
Then copied 2.8GB file from on PC to another on the LAN. No change to the bandwidthd counts. Of course, there should be no change, the 2 PCs and pfSense LAN port are connected to a switch. The switch quickly learns which MAC address is where and only shunts the file copy packets between the 2 ports involved. This can easily be seen just watching the flashing lights. So there is no way that pfSense LAN could ever sniff this traffic. It needs a different hardware configuration to really test if promiscuous mode is working or not.
Then downloaded another 22MB file - the received count went up 23MB and the sent count went up a little, as expected.
So, for me it is counting fine. I have an Alix 2D13 with LAN, WAN and OPT1 (2nd ISP) running July 9 2.1 snapshot.
Maybe others have more complicated setups with VLANs etc, where different traffic flows end up seen by pfSense. -
It should have just been a matter of adding:
else $promiscuous = "promiscuous false\n";
after the if statement bit. You could add brackets to the whole statement to make it like:
if($promiscuous){ $promiscuous = "promiscuous true\n"; } else { $promiscuous = "promiscuous false\n"; }
It is odd to have a syntax error at line 12???
That's exactly the way I added it from the top example.
I have only had the 1 machine ( a laptop ) on a switch / switch too pf2.1 test box. So there is no other traffic on the lan side , only through the PF box.
I'm using a dual port intel card chip is fk31791a2. Could it be this card causing the problems? -
If you want to try, can download edited bandwidthd.inc from here: http://ptt.4mg.com/pfSense/
It is from an 2.0.1 AMD 64 pfSense install (not sure if it will work with 2.1)
-
I updated then re installed BWD
A 10 MB file download for some reason was the first thing I tried. I waited for 30 minutes and BWD showed only 59KB.?
CP in the syslog showed 11MB Just where it should be.So I the next file was 100MB BWD showed 243.8M CP showed 122MB. So Cp is working fine at counting.
Next I tried a 50 MB file BWD went too 342.6MB
again 10 MB - 354.5M
'' 10 MB 376.7M
50 MB 450.9MSo in total I downloaded 240MB of files.
CP in the syslog shows user is at 253MB used –---- This sounds correctBWD counted up a total of 450.9 total sent 14.6M total received 436.3M
I'm going to try and swap out the Nic on the Lan interface.
I don't know if this might be the cause or not.
Currently I have the PF box wan connected too my home network 192.168.0.x/24
it's lan is 192.168.1.1/24
1 laptop through a switch back too the PF box. Ubuntu.
I download from an HFS file server I have running on the .0.x/24 lan. -
Ok So I swapped out my dual server nic for a realtek 8179 I think it is. PF calls it rl1
I get the same results,
100 MB file download cp counts from 258 too 368. Correct .. Bandwidthd counts from 522.4 too a whopping 743.7 witch is about double what it should be.
Is there anyway I can force BWD too get it's info from the same place CP does?
I want to set hard limits monthly some daily I would like to be able to offer users a way to keep exact tracking of what they have used/left.