From: "Jonathan De Graeve" <Jonathan dot DeGraeve at imelda dot be>
> > On a fresh power on, everything works normal. I am not sure how the
> > problem
> > develops as I am not aware until we get calls. At that point, a new
> > client
> > will get an IP via DHCP fine. However, an http request will just time
> > out.
> > Clients already authenticated (Like the business center PC, often
> > will never time out, even with the idle timeout set. They, and
> > with
> > "allowed IP addresses" will work fine.
> Which means something is holding it up, which CPU type/memory
> (performance wise)?
All systems have 256 meg, and strong CPU. All system web consoles are
responsive, and all logs viable. You can not tell anything is wrong from
> Can you confirm if this only happens on systems with more then
> 50concurrent user logins?
No. However, now that local managers know a reboot fixes it, it is very
hard to get "before" snapshots. :-(
> 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?
IE, Firefox, and Opera all timeout. The error we get called on is "the
inter net is down."
> You can try to higher the max number of concurrent sessions from default
> 16 to 32 for mini_httpd in the config.
How is this done?
> 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
> Access-Reject packet.
> You can change this behaviour by changing the config and adding a
> 'hidden' option key to the captiveportal section:
AFIK, all of the systems doing this are not using RADIUS, but only a splash
page acceptance authentication. Would this still make a difference?
> Since for the rest everything is still accessible there isn't a problem
> with buffers.
Confusing, isn't it? :-)
> > 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. ?
All are in hotels. From 0 to 10 users can come on any time. Sometimes many
more. Mostly porn or music downloads. Light VPN outbound use from clients
in the LAN from 5:30 to about 8:00 then all porn. :-) Business users...
> Well, it contains bugfixes that ain't incorporated into 1.22, it should
> be more stable ;)
I can try it, or wait to see it break again to gather more information. PS:
1.23b1 doesn't have a "both" checkbox, does it? ;-)