We have been using MT-2.9.32 on a hotspot setup using satellite connections.
Our radius servers are located here in our data center, due to the latency of the VSATs we have MT radius timeout set at 10000ms.
We upgraded to MT-2.9.38 last night and since then we have seen errors and timeouts in our logs. When going in to check the MT boxes we found that the radius time out setting will no longer allow us to use 10000ms for the time out and now it gives us a popup saying the range can only be 10~3000ms
Is there a reason this was done? We need our time outs higher than the 3000ms the new release allows.
Our networks are based in several countries and all the radius and web servers are located here in the US in our data center. Add this to the fact that our sites use VSATs and the latency is to high for the new release limits.
For now we have had to down grade all the boxes back to 2.9.32 so they will operate correctly.
Is there a reason for this, or is this just something else MT thinks we all need? I don't see why there needs to be a limit on this or at least put a limit that can be used over Satellite links.
As it is now we will be stuck using the 2.9.32 ver as a 3s timeout just will not work for us. Our 10s timeout has been working well for us but set at 3s and we see many resends and timeouts in the logs.
We also did not see a reference to this change in the change log, at what version was this limit introduced?
Joined: Mon Feb 14, 2005 2:48 am Posts: 517
Thats seems weird! Normally MT allows the user complete control and if there is a problem it's yours for configuring it wrong. Thats one thing I like about it! This seems to be a bit low and I have used satellite links too and 3s would be too little to guarantee a reply in all circumstances.
I test lot of cases about a slow conexion (because of weather conditions, latency, ...), but I remark if you use a DB attached to radius server, this DB can be very slow, too. It happens because the DB has a hight load or a lack of memory of the machine.
Obviously, the unique solucion to mt is to wait, so the /radius timeoute has to be hight. Above all, this high timeout is usefull for roaming services because radius server do proxy radius and some AAA servar are too far or too slow to answer. My normal time in these cases are 8 secs.
Joined: Fri May 28, 2004 11:49 am Posts: 1551
If the high latency is inherent to the network in question, you can just tell your clients that it WILL take that long - and they WILL wait, if that's the only way to get internet...
Of course USUALLY so high timeouts will be too long and won't be necessary. But there are those situations (like the described satellite links) where you NEED to set the so high just to make things work.
RouterOS always prouds itself (and that's a big part of why I like it so much) of being super-flexible - this is clearly a step in the wrong direction here (although not affecting most users).
And - hey: What's the problem in just letting people configure the timeout they like? It's not that this should be something RouterOS is limiting by itself!
Joined: Sun Feb 20, 2005 1:16 pm Posts: 98
We too having some experiences with RADIUS authentification and
have to agree that 3000ms is too short. We usually set it to 10000ms (10s).
If you have a well stuffed DSL line because of many surfing customers,
the RADIUS connection can take some time. Especially if you are doing
roaming with other providers like "awacenter" already noticed.
We have far more INTERIM updates than START or STOP messages. And
the customer doesn't notice if this INTERIM update takes 1 or 7s.
But it should not run in a timeout ...
Please keep it flexible ... this fact is an argument for us not to update
at the moment.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum