> On a fresh power on, everything works normal. I am not sure how the
> develops as I am not aware until we get calls. At that point, a new
> will get an IP via DHCP fine. However, an http request will just time
> Clients already authenticated (Like the business center PC, often
> will never time out, even with the idle timeout set. They, and
> "allowed IP addresses" will work fine.
Which means something is holding it up, which CPU type/memory
Can you confirm if this only happens on systems with more then
50concurrent user logins?
If the http doesn't work anymore: the mini_httpd still seems to run,
even if you wait 10seconds the page doesn't show up?
You can try to higher the max number of concurrent sessions from default
16 to 32 for mini_httpd in the config.
Also you can try to kill the minicron ' /usr/local/bin/minicron 60
/var/run/minicron.pid /etc/rc.prunecaptiveportal' process and to start
it back up manual using the exec and instead of 60 use 300 (= 300sec) If
there is a huge number of users and the radius is slow it can happen
that the timeout values are a little bit too high and that the m0n0wall
isn't able to update all accounting within a 60sec interval, especially
when the radius is configured with a delay if has to answer with a
You can change this behaviour by changing the config and adding a
'hidden' option key to the captiveportal section:
Since for the rest everything is still accessible there isn't a problem
> > Can you give me a more detailed explanation of the situation? Could
> > also try to install 1.23b1 on this 'problematic' systems? The
> > rewritten in 1.23b1 to avoid problems which happened to appear with
> > browsers like mozilla (firefox).
> How stable is it? This problem only occurs in heavily used production
> systems. If you wish, I can give you access to the to locations that
> done this the most.
You are talkin gabout heavily used: how many users at min. ?
Well, it contains bugfixes that ain't incorporated into 1.22, it should
be more stable ;)