Unable to login using Free radius



  • Hi Team,

    Need help !

    Scenario : Pfsense 2.0.2 i386
    captive portal running with Freeradius2 package.
    For some its working but for few people connecting , they get the login page but after enter the credentials the login page redirects to the same login page again, no error but to login again. Even after multiple attempt it doesnt allow to log in.

    Does this have anything to do the DHCP scope ?
    As i could find dhcp lease getting full each day the maximum given 250 leases.



  • check your captive portal logs. under status / System Logs

    do you have … log enties that look like this... ?

    CONCURRENT LOGIN - REUSING IP xx.xx.xx.xx WITH DIFFERENT MAC ADDRESS xx:xx:xx:xx:xx ?

    P.S You should open your IP range to accept more users since it seems that you need it...

    (on your LAN or OPT interface, depending on where your DHCP runs , Change your subnet mask from 255.255.255.0 (/24) to 255.255.254.0 (/23)

    Go to you DHCP server settings and change your DHCP Pool settings and modify the new IP Range Pool.



  • @abinjacob:


    Does this have anything to do the DHCP scope ?
    As i could find dhcp lease getting full each day the maximum given 250 leases.

    Your talking about handed out IP's - understand that every device that get in range of your Wifi network will ask an IP, this is not related to the facrt the these devices (clients) actually login.
    Are these handed out IPs still 'active' or: is the lease still non-expired ?
    Expired leases are printed in grey, non-expired leases are black.
    What is your DHCP (Portal) expire time ?
    What is your idle and hard time out on your portal interface ?



  • @jaspras,

    CONCURRENT LOGIN - REUSING IP xx.xx.xx.xx WITH DIFFERENT MAC ADDRESS xx:xx:xx:xx:xx
    Didn't find such logs  :(

    Changing the subnet mask from 255.255.255.0 (/24) to 255.255.254.0 (/23) and then changing the scope in the web GUI - Will this make any impact with the connection or services?



  • @Gertjan,

    Hard timeout in the captive portal is not set.
    default and maximum dhcp lease time is set for 1 hour.
    handed out IPs do stay active till the lease time and then expire. (grey out) , but will this expired IPs be used by the next connecting device?



  • @abinjacob:

    Hard timeout in the captive portal is not set.

    So, if the device stays in wifi range, it will renew its DHCP lease every half way "maximum dhcp lease" (this is how DHCP works).
    If the device puts out some info - as all devices do, the connection stays up …..
    And won't get disconnected.
    If the device goes off-wifi, only a idle-timeout could disconnect that client.

    You better check if your Captive Portal Idle Timout is working: See the Portal log if you can find "TIMEOUT" lines.

    If connected devices do not become idle (no more communication), then all your IP's will be used ….. and when the IP DHCP server pool goes full which means => problems.

    @abinjacob:

    default and maximum dhcp lease time is set for 1 hour.

    So the lease will be renew every 30 minutes - the DHCP client (the clints device) will do that. See you DHCP log for confirmation, you'll see DHCP clienst asking for an (identical) IP every 30 minutes (my 'Windows' PC do exactly this).

    @abinjacob:

    handed out IPs do stay active till the lease time and then expire. (grey out) , but will this expired IPs be used by the next connecting device?

    Expired IP's will get recycled.
    That how a DHCP server works.
    If a "known" device connects again, and an old DHCP lease is present (greu) with has an identical MAC then this device will get its previous IP.
    Otherwise, il will have a new IP.



  • both idle and hard timeout are not set.

    Will it be useful if i set the idle timeout at this moment to solve the present issue?



  • @abinjacob:

    both idle and hard timeout are not set.

    That close to "asking for troubles".
    Clients connect - and stay connected for live (the session file could probably survive a reboot).

    Do you have a reason not to set at "Idle timeout" and "Hard Timeout" ?

    Clients will be disconnected after this amount of time, regardless of activity. They may log in again immediately, though. Leave this field blank for no hard timeout (not recommended unless an idle timeout is set).



  • No particular reason for NOT setting idle and hard timeout, just wanted users to stay connected without any issues.

    Shall i set the idle timeout alone ? with a point that if a device stays idle say for 1 hour, let it disconnect.
    And if such a disconnect occurs, will that IP expire and available for reuse, because at the moment i'm manually deleting all expired IPs.

    And please let me know what the below system logs mean.

    kernel: arp: 192.168.0.30 moved from 90:27:e4:f6:af:ec to 9c:20:7b:c4:27:ac on vr0
    dnsmasq[31537]: read /etc/hosts - 144 addresses



  • one of the weird thing that i have noticed is, as you know the issue is login page reappears again and again.
    and i'm able to get the mac address of the machine which is impacted to this via system logs.

    but if i add that mac to by pass captive portal then the issue gets resolved for that machine, how is that possible, since it will also need 1 IP from dhcp scope?



  • one more system log which i'm not aware what this is

    dhcpd: uid lease 192.168.0.222 for client 38:aa:3c:c6:9c:ce is duplicate on 192.168.0.0/24



  • @abinjacob:

    … because at the moment i'm manually deleting all expired IPs.

    Expired "record" (== IP's) are just kept for reference.
    and for this reason: If the same device (== the same MAC) comes back and the DHCP server finds the MAC in an expired record AND the IP is available, it will give the same IP to that device.
    Otherwise, another IP will be given.

    I do not understand why you should clean out the expired leases.

    @abinjacob:

    kernel: arp: 192.168.0.30 moved from 90:27:e4:f6:af:ec to 9c:20:7b:c4:27:ac on vr0

    Me neither: but … the first message on this search list shows what the problem might be ; https://www.google.fr/search?q=kernel%3A+arp%3A+192.168.0.30+moved+from+90%3A27%3Ae4%3Af6%3Aaf%3Aec+to+9c%3A20%3A7b%3Ac4%3A27%3Aac+on+vr0&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla🇫🇷official&client=firefox-a&channel=sb&gfe_rd=cr&ei=YJupU4bwFOuXigbArIDQBw#channel=sb&q=kernel:+arp:++moved+from++to++on+vr0&rls=org.mozilla🇫🇷official

    @abinjacob:

    dnsmasq[31537]: read /etc/hosts - 144 addresses

    Don't worry, this is insignificant is log-dust.
    dnsmasq like to say this often, its ok. We all have these line several times.

    @abinjacob:

    one more system log which i'm not aware what this is
    dhcpd: uid lease 192.168.0.222 for client 38:aa:3c:c6:9c:ce is duplicate on 192.168.0.0/24

    https://www.google.fr/?gws_rd=ssl#q=dhcpd:+uid+lease++for+client++is+duplicate+on+
    In 'my' words: the IP's / MAC's you put in a "Static mapping" have no 2 IP's for an identical MAC.

    My advise: make your IP pool big enough, and restart the DHCP server. This list: "Status -> DHCP Leases" should be empty to start with, and you will be fine.


Log in to reply