Captive portal accounting does not work properly



  • When using CP accounting with freeradius2 , it seems the longer a user has continuous traffic flow the faster the usage file fills up.
    I noticed this bug in 2.0 and 2.01.
    http://forum.pfsense.org/index.php/topic,50785.msg271217.html#msg271217

    Any chance this can be worked on?



  • Again testing with users as mac address with FR2
    If I kick a user I get this error page

    Fatal error: Call to undefined function bcmod() in /usr/local/captiveportal/radius_accounting.inc on line 337 
    

    And I don't know if it's a bug or not but I tried the redirect URL and that does not work. The user was locked out and could not browse anywhere.  I had to restart CP and FR2 too get the user back online.
    Any word on the traffic accounting bug?

    Also is it possible too add an option too re auth users every 5 or 10 minutes instead of every minute?



  • So I installed Bandwidthd
    Set it up and let it be for a while.
    Then downloaded a 700 Mb file . Bandwidthd counted 1.5 G
    Can someone comment on PF 2.1's ability to count traffic?
    I saw this same problem in PF2.0 last year.
    When I upgraded from 1.2.3 the next week /month all users were all of the sudden using over double what they normally do.



  • Any comment on this problem?



  • known issue, there's a ticket open on it.



  • Noted Bug 1974.
    Bandwidthd seems to count a sporadically as CP does. So the problem could lie deeper in the system.
    Does anyone know if pfflowd pulls it's data from the same source?



  • bandwidthd listens on bpf on the NIC where it's listening, either in promiscuous mode or not depending on whether you have that enabled, it's 100% accurate of what the bpf shows (either all traffic on that NIC or all traffic through that NIC). The captive portal stats issue isn't even close to the same, and it's been fixed now. pfflowd pulls from a different source than either of those, from the pf state table.



  • Yes CP does seem to work properly now.
    Bandwidthd does not. On my system at least. It counts 3 times or more what actually passes through the nic.



  • If you have it in promiscuous mode, it can see a lot more than what the system is actually passing, how much depends on the network.



  • For my test system I have promiscuous mode unchecked and 1 laptop on the lan. Some times 2 but the last week it's been the one ubuntu laptop.
    Today I had little time to mess with it but CP in the syslog shows 14Mb used and bandwidthd shows 33.5. I updated too the july8th snap this morning. So both were set to 0 this morning.


  • Rebel Alliance

    @Alan87i:

    Yes CP does seem to work properly now.
    Bandwidthd does not. On my system at least. It counts 3 times or more what actually passes through the nic.

    @Alan87i:

    For my test system I have promiscuous mode unchecked and 1 laptop on the lan. Some times 2 but the last week it's been the one ubuntu laptop.
    Today I had little time to mess with it but CP in the syslog shows 14Mb used and bandwidthd shows 33.5. I updated too the july8th snap this morning. So both were set to 0 this morning.

    From some tests done using BandwidthD  long time ago (2.0RC3) seems that it still leaves the interface in "promiscuous" mode Even if you set to Not….

    Check if your interface is in promiscuous mode using "ifconfig"



  • looks like it is.

    /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=108943 <up,broadcast,running,promisc,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,promisc,simplex,multicast,ipfw_filter></full-duplex></performnud,accept_rtadv></vlan_mtu,wol_ucast,wol_mcast,wol_magic></up,broadcast,running,simplex,multicast> 
    


  • 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.

    1. 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";
    
    1. Save bandwidthd settings on the GUI - this will rewrite the conf file and restart bandwidthd.
    2. Examine bandwidthd.conf to make sure it has "promiscuous false".
    3. 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.



  • @phil.davis:

    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?


  • Rebel Alliance

    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.9M

    So in total I downloaded 240MB of files.
    CP in the syslog shows user is at 253MB used –---- This sounds correct

    BWD 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.


Locked