> Here is the basics of our portal config:
> No Idle timeout
> No Hardtimeout
> Max Concurrent Connections (we have tried 0 for none, 16, and left blank)
> Authentication - Radius
> Re-Authenticate connected users every minute (then at someones suggestion,
> manually coded this to 360 seconds)
There is a 'hidden' config.xml option, you don't have to hardcode it to
I'm not sure if its the same issue but I had something similar using radius
mac-authentication and mozilla-based browsers.
This got fixed something later in the 1.2x tree.
It would be nice if you could sent me a clientlevel networktrace (preferably
This should give some understanding on what is going on.
I'll check with Scott which m0n0wall CP version they're using since there
are some fixes in the current svn. (scott, if you read this ;) )
My second suggestion is to try a M0n0wall, it shouldn't be a problem if
you're only using it as a CP.
Following m0n0wall versions are considered to be stable CP wise :
> All else defaults.
> On another note (in case this is a resource issue), we are using the re-
> auth feature because we are providing 24x7 service and dont want to
> restrict the users service. However, since we use DHCP, when the clients
> get a new IP, they are forced to login anyways again. Well, this will work
> for us fine if that is how it is to work by design. Can you confirm that
> please? If a user does not pay their bill, we wanted it to cut off their
> service asap. If that has to transpire 24 hours later (after a DHCP
> renew), that is fine by use and maybe will help this issue if its resource
> related. I ran a top on all the boxes and showed the CPU bored to death at
> 99% idle. These are p4-2.4GHZ / 512MB / 80GB SATA150 Dell boxes.
A m0n0wall is definitely being able to handle more then 15user connections.
I've heard about handling 90-100users so 15should work ;)