O Canada! > Canadian > Canadian Broadband > Ebox MLPPP testing time

reply to grunze510

Re: Ebox MLPPP testing time

reply to Angelo

reply to CanerisErik

said by CanerisErik:

said by Angelo:

or you can write a script to disconnect and reconnect until you land on the proper gateway on the consumer end.

Or you can develop a proper MLPPP CPE

reply to hmm
Yes, multiple connection attempts will result in the BAS becoming unresponsive to further attempts for up to 5 minutes and then allow just one more before another 5 minutes of silence.

The timeouts are a power of two. After first failed attempot, there is a 1 second timeout, then 2, 4 , 8, 16, 32, 64, 128, 256 and finally 300.

In the early tests of the .14 ebox had special usernames which caused the tunnel to be created to the .14 (similar to what another ISP (whose name I am not allowed to mention) had done to fix their MLPPP issues.)

The .14 is behind other routers, it doesn't have its own AHSSPI feed.

So we must wait Mr Diskace's information on what login nomenclature is needed to reach .14 so we can test the MLPPP.

Shock ! Horror ! I might have to send him an email ! (He's had enough trauma today, as I already spoke to him on the phone !)

reply to jfmezei

Re: Ebox MLPPP testing time

for now we don't have the nomenclatures but we will re-enable something like: mlppp.username@dsl.net just like what we tried with the Autonomous System this autumn.

Right now, you have to force sessions on the same gateway .14

Anyone here can test and report ?
--
Electronic Box Inc.

if you guys are going to connect and disconnect in your scripts add a sleep timer between conecting to avoid bells timeout.

reply to diskace
Mr Diskace, when you say "force session on the same gateway .14", how do we do that ?

Friday morning, I did end up on .14 twice. Is it part of the standard pool of routers which handle any user on 3men ? Or do the AHSSPI facing routers only give .14 to users which radius qualifies as "ebox" ?

Angelo, unless you wait 15 minutes between login attempts (which resets the lock out to 0), you still get hit by it by the lock out.

What is not sure is whether a PADI request during a lock out will increase the lock out period (even though it is ignored) or whether it is only a PADI request that arrives after a lock out as ended.

For instance, if you are currently locked out for 4 seconds, if you send a PADI after 5 seconds, you will get a PADO, but if the login fails, the lock out increases to 8 seconds.

But if you send a PADI after 3 seconds, you will not get a response since it is during the lock out period, and it is not sure if this action results in the lock out increasing to 8 seconds or whether only the next PADI sent after the 4 second lock out ends will cause the increase to 8 seconds.

This will dictate whether it is worth coding delays in the scripts or not. If a PADI during a lock out period does not change the lockout period, then there is no point in having a script.

But if such a PADI does cause the lock out to increase, then there is a point in having a script since there is no point in sending a PADI during a lock out when you know that you won't get a response, while you also know it will extend the lock out.