Captive Portal Timeouts

RouterOS General
1

I’m fairly new to MicroTik boards (though so far they’ve lived up to everything I’ve heard about them [good]).

I’ve been configuring a captive portal system for a hotspot application and have it working well, with the exception of one item. Users are able to connect and if they stay connected can use the hotspot for up to a month without reauthenticating (basically for as long as they stay connected for most users). However, I’d like to set it up so that for 1 month they don’t have to ‘reauthenticate’, but the actual action that is happening is that after they disconnect when they reconnect they have to reauthenticate. Have I done something wrong or is this by design? I have idle-timeout set for 1w, but even so it’s not waiting a week before it ‘idle-outs’ a user.

Here are my settings:
PROFILES:
1 name=“trial” idle-timeout=1w keepalive-timeout=1w status-autorefresh=5m
shared-users=unlimited transparent-proxy=no

[admin@Indigo Router] /ip hotspot active> print
Flags: R - radius, B - blocked

USER ADDRESS UPTIME SESSION-TIME-LEFT IDLE-TIMEOUT

0 T-58:B0:xx:xx:xx:x 192.168.88.231 1m10s 4w1d23h58m50s 1w
1 T-00:1C:xx:xx:xx:xx 192.168.88.232 4m17s 4w1d23h55m43s 1w

The DHCP server is set to expire IPs after 1 hour – is this causing the hotspot to also forget the connections?
[admin@Indigo Router] /ip dhcp-server lease> print detail
Flags: X - disabled, R - radius, D - dynamic, B - blocked
0 D address=192.168.88.232 mac-address=00:1C:B3:xx:xx:xx client-id=“1:0:1c:b3:xx:xx:xx”
server=default status=bound expires-after=1h25m54s last-seen=4m6s
active-address=192.168.88.232 active-mac-address=00:1C:B3:xx:xx:xx
active-client-id=“1:0:1c:b3:xx:xx:xx” active-server=default

1 D address=192.168.88.231 mac-address=58:B0:35:xx:xx:xx client-id=“1:58:b0:35:xx:xx:xx”
server=default status=bound expires-after=1h22m10s last-seen=7m50s
active-address=192.168.88.231 active-mac-address=58:B0:35:xx:xx:xx
active-client-id=“1:58:b0:xx:xx:xx:xx” active-server=default

2

Add the ‘cookie’ login method - if they do get logged out, the browser will automatically log them back in.
I think that’s cleaner than keeping stale connections around forever.

3

Agreed - and I’ve got that turned on and have 67 cookies on the ‘cookie print’ screen.

1 name=“hsprof1” hotspot-address=192.168.88.1 dns-name=“” html-directory=hotspot
rate-limit=“” http-proxy=0.0.0.0:0 smtp-server=0.0.0.0
login-by=mac,cookie,http-chap,trial mac-auth-password=“” http-cookie-lifetime=4w2d
split-user-domain=no trial-uptime=4w2d/1m trial-user-profile=trial use-radius=no

Am I having issues because I have mac before cookie in the list?

4

I do not know. You can’t change the order of the items in the authentication method list.

5

Actually - does ‘cookie’ work for trial users? Cookie DOES work if I log in, but this is an open hotspot so everyone is ‘trialing’.

6

As a workaround, maybe try an automatic login. Write a login.html that submits an existing username and password to /login - same functionality (no one has to provide credentials), but you’re out of trial mode and to the router everyone is just authenticated, albeit without the customer having to interact with the router for that to work.

I don’t have much experience with the trial feature.

7

good idea - but I’m getting “web browser did not send challenge response (try again, enable JavaScript)” when I try that, obviously something the router doesn’t like about just sending creds through.

8

Enable HTTP-PAP instead of HTTP-CHAP - you don’t care that the password is clear text since there’s no secret for logging in as everyone is supposed to get free service.

9

That worked… thanks!