Captive Portal

Hello

I'm using CP (v1.231) in order to authenticate my wifi users against MS Radius. Sometimes users can not get the authentification page. I've not been able to determine a common point for all these users (different computers, browsers, etc...). In order to resolve this problem, the only way, I've founf is to reboot the monowall.
Has anyone got these problems ?

One more question : Could this happen because I have a only a hard timeout on CP of 600 minutes because my users complaind about beeing disconnected too often ? (I have often 150 and more users authenticated).

Thanks in advance for your help.

Regards

Vincent

In order to resolve this problem, the only way, I've founf is to reboot the monowall.
Has anyone got these problems ?

Yes! We also have these problems. I wrote about them in an email on the maillist but since we also had a suspicion that it was due to a dhcpd lease-time that was shorter than the CP timeout I didn't get any real answer.

Now I have a 30 minutes dhcp lease and a 15 minute timeout in CP but the problem rears its ugly head after a few weeks of uptime!

When this happens if I check the status.php page I notice that we have multiple entries like this:

Code:

20079       5474        432286 deny ip from 193.180.140.117 not MAC any 00:19:5b:35:90:06 any layer2 in

This seems to be due to a problem with CP not releasing the MAC address firewall rule when the user leaves or is logged off due to an timeout.

One more question : Could this happen because I have a only a hard timeout on CP of 600 minutes because my users complaind about beeing disconnected too often ? (I have often 150 and more users authenticated).

We also have about 120 users authenticated!

How often does this occur on your site? And the next time it happens could you please look at the status.php and check for the above mentioned rule if its possible for you?

Im at and end here and thinking aobut replaceing it. I can't find any commercial support in my timezone either!

Thanks for your answer.

I don't use the dhcp server from monowall, I use the dhcp server of my win 2003 server.
I've checked the lease time, It was shorter than the mono hard timeout : so, I've corrected it.

The problem mentionned above arrive about once per day, sometimes two or three times per day.
I diden't know the status.php page. I've checked it and I've seen same messages although I don't know if the problem was here or not because no users complain at this moment.

Regards

Vincent

Hello

I had the problem this morning. I had the same error message (this is the line from the user who complain)
deny ip from 172.16.2.19 not MAC any 00:13:02:7f:1a:6a.
In fact I have about 124 lines like this one at this moment and often see about 254 lines like this.

20003       0         0 deny ip from 172.16.4.16 not MAC any 00:1b:77:22:b5:26 any layer2 in
20003       0         0 deny ip from any to 172.16.4.16 not MAC 00:1b:77:22:b5:26 any layer2 out
20004       0         0 deny ip from 172.16.2.92 not MAC any 00:1b:77:22:aa:55 any layer2 in
20004       0         0 deny ip from any to 172.16.2.92 not MAC 00:1b:77:22:aa:55 any layer2 out
20005       0         0 deny ip from 172.16.2.94 not MAC any 00:1b:77:98:5c:cc any layer2 in
20005       0         0 deny ip from any to 172.16.2.94 not MAC 00:1b:77:98:5c:cc any layer2 out

Hope this can help someone to find the problem.

Thanks in advance

Regards

Vincent

At work I handle tech support for a public wireless hot spot using Captive Portal.

I have experienced a similar problem with captive portal using a D-Link.  As far as I know the technology of how it is done is similar.

What type of computers/browser are you using?  I have found out with the D-Link through trial and error that Safari on the Mac OS just will not work.  From what I am able to determine is the Safari does not handle the page redirects which is how CP works.

The work around that I have found that these people need to do is use some other program, such as Firefox, to handle the CP page.  Then after that, everything else works the way it should.  Including Safari until they need to see the CP page again.

Jeff

Here's my experience with it.

DHCP lease times have nothing to do with it. I've experimented with 1 day timeout for CP and 2 hour timeout for DHCP and have been able to login via CP, shutdown my laptop until I see that the DHCP has expired and removed from the m0n0wall DHCP status page. Power back up, laptop gets a "different" IP address and still CP lets the computer through without any fuss.

Other times, the CP gets "wedged" on the user and you have to use the CP status page to force a log out before they get the login screen again to authenticate. Otherwise, they get no connection, even if you go directly to the CP page and login again, it still will not let you through.

Very strange. The only solution so far has been the real short timeouts which I'm not a big fan of and wish I could get it to last at least a day or so. 

Ok, more to report on this topic.

After a ton of trial and error, from what I can tell, the Captive Portal (v1.233) has a "hard" inactivity limit of about 3 hours unless you set it for less. After 3 hours, it appears to enter a kind of "limbo" in which phantom traffic is counted towards being "active" in that if you had the inactivity timeout set for 6 hours and you shut off your PC, come back about 4 hours later, then you encounter the "can't connect, no login screen" problem most of the time. I say most of the time because I've seen it actually work, but most of the time it will not, no matter the OS (Windows, Mac, Linux, etc.).

So far, 3 hours seems to be the safe area in which I haven't seen any machine that was shutdown, come back before that time have issues.

Here's the weird thing, when your PC is in that "limbo" state with the captive portal, CP is still counting your "attempts" as activity even though you get nothing. Basically you have to "disconnect" the user manually from the status page to fix this issue.

Some more info to add to this topic.

I've noticed that windows machines generate traffic on the infamous port 137, 138, 139 which even though it doesn't really connect anywhere, m0n0wall counts the traffic as activity. The problem is I've noticed, this non-traffic keeps the inactive counter from timing out sessions, so a computer seems to be stuck logged in all night for example and when morning rolls around, you are stuck in limbo with no connection and no login screen. But if you check the logs, it shows you being active all night, even though no traffic has gone anywhere.

This I hope might be another clue to why captive portal can't use long inactivity timeouts due to phantom traffic fooling the timer, but confusing captive portal because something, somewhere is doing a timeout on it's connection state to captive portal.