DHCP problem with Captive Portal



  • Hello,

    My server running version: 2.3.2-RELEASE-P1 (amd64)

    With i7 CPU and 8 GB RAM, and running services ( DHCP, IP Forwarder, Snort, Captive Portal and ntopng) and I have 80 users connected via Wi-Fi

    everything is working fine but when users logins exceeded 50 users online, the whole lan stop responding and when I access to the dash board from WAN I got error message on DHCP logs as below

    "dhcpd: failed to send 300 byte long packet over em0 interface"
    "dhcpd: send_packet: Permission denied"

    also; there are no special firewall rules running.



  • Hi,

    Tell us more, like :
    Who is "em0 on your system ? (mine is : WAN) ?
    Do you have enough spare IP's left in the DHCP pool ?



  • Hi Gertjan,

    em0 is my LAN interface, and there is one DHCP pool with range ( 192.168.10.20 : 192.168.10.200 )

    and maximum connected users on same time is: 70 user.

    by theway the problem solved when I reboot the system and occurred again after few hours



  • pfSense could log if somethings goes wrong.
    You inspected the logs ?

    These :
    System - General
    System - DNS Resolver
    and
    DHCP

    Look also at Captive Portal Auth.



  • Dear Gertjan,

    I appreciate
    your response, but I am already looked into all logs and the only error I got form DHCP while the problem occurred is:

    "dhcpd: failed to send 300 byte long packet over em0 interface"
    "dhcpd: send_packet: Permission denied"



  • @veileyes:

    ….
    "dhcpd: failed to send 300 byte long packet over em0 interface"
    "dhcpd: send_packet: Permission denied"

    and let me guess, when this happens, no more IP get handed out - so people do not get an IP anymore, and thus : can't logging upon the captive portal.

    The thing is Google knows about this "dhcpd: failed to send byte long packet over interface" but all is related to ancient bugs that dhcpd had ones, in the past.
    It can't be the em0 = LAN firewall : the GUI only filters the incoming stream - not the UDP outgoing stream.
    I think it is a interface issue.

    What are your LAN firewall rules ?
    What did you removed from default after you installed pfSense ?
    Can you use the Captive Portal "as it should be used" : on a dedicated, NOT LAN, but OPTx interface ?
    pfSEnse runs in a VM ? (and guess what, when it is NOT running in a VM, but running in its own box, the errors disappear ;) ?)

    Look at this case : (ok, it's a 'Linux issue, not FreeBSD) and he was actually blocking with his firewall (using to strict iptables rules) : http://www.linuxquestions.org/questions/linux-networking-3/dhcpd-complains-failed-to-send-300-byte-long-packet-over-fallback-interface-4175548986/ - so this is was a "between chair and keyboard" issue.

    This is another one : https://forums.freebsd.org/threads/45149/ with a happy end (and a complex setup).



  • I belive it's not IP range issue because the DHCP range contain more that 200 IP to use and I adjusted the lease time to 1 hour.

    • What are your LAN firewall rules ?
      I didn't configure any firewall rules on em0 (LAN), only the default rules (Anti-Lockout Rule & Default allow LAN to any rule).

    • What did you removed from default after you installed pfSense ?
      Nothing!

    • can you use the Captive Portal "as it should be used" : on a dedicated, NOT LAN, but OPTx interface ?
      is it mandatory to add OPTx interface for Captive Portal ?

    -pfSEnse runs in a VM ? (and guess what, when it is NOT running in a VM, but running in its own box, the errors disappear ;) ?)
    Not VM, I installed pfSense directly on PC.

    Finlay, after along time search in google I found that may be the problem occurred because of network memory buffer, so I am tried to increase the buffer size by adding some buffer tuning settings in "System Tunables" and "loader.conf.local"  , it helps some how as the error didn't occurred again but I got some delay on network.

    I don't know it's solved permanently or it will occurred again but for 2 days now it's not occurred. before the tuning settings it was occurred one or two times every day