Canadian Broadband → "Timeout waiting for PADO packet" in router's log

Hi all,

When my internet service was down (PPPoE disconnected and failed to connect again), I checked the router status and log, I found this message in the log "Timeout waiting for PADO packet". I have no idea what this means, but when I reboot the modem and router, PPPoE connected successfully again.

My concern is, what's cause of this problem? It's on my side or my ISP's? My configuration is as following if this matters:
Modem: TP-Link 8816,
Router: Linksys WRT54GS running Tomato/MLPPP
ISP: Velcom

Rebooting your router and modem did not fix this.

Bell's PPPoE routers are programmed to ignore your PADI requests for a period of time that doubles with each invalid PPPoE login request up to a maximum of 15 minutes.

So if your ISP was down or you had bad password, none of your attempst at connecting would work and you would be waiting for the PADO packets that never come since Bell is ignoring you. The only way to get around this is to stop sending PPPoE login requests for a period of time after which Bell will let 1 request through.

I think it's a maximum of 5 minutes, but the lockout completely resets if you don't try connecting for 15 minutes.

EDIT: Here's the thread with info on the PPPoE lockout process. »Documentation on the PPPoE lockout process

not exactly.
1. the login can be valid. They only allow x-connection attempts per set time.
2. I have been only blocked for exactly 5 minutes on the dot no matter how many times i tried to connect. Bell, who sent techs to my home because they didn't believe me, timed it. Then when the tech contacted everyone he could at Bell to try and find what type of "line problem" causes this, he gave up and left.

I kept telling Bell it was a 5-minute lock out that kicks in after 2 or 3 connection attempts, even if valid. But they brushed me off and insisted it was a line problem that they could not fix.

Redfox, just stop all connection attempts for 5 minutes. No less. "should" work after that. Try and let us know.

I have no clue if they changed this since then. This lock out started in 2007 that I noticed.

Thanks for all the replies! But I am still confused what's the exact cause of this issue, my ISP or Bell?

I experienced this problem twice in the last week. The first time when I got this timeout error, I didn't reboot modem/router, I just let the router keep trying login. I even tried test@test account and couldn't login either. Then on the next morning it's still not connected, so I rebooted modem/router and everything was back. Then it's last night, I found the problem as soon as it occurred because I was in a telnet session. I checked router's log and found the same message, so I rebooted modem/router immediately and I have the connection back right after they rebooted. I believe maybe it's less 5 minutes but definitely less than 15 minutes. Last night I was downloading with BT with MLPPP single link enabled.

I'd have to reread the specs. It is possible that it is 5 minutes max but it remains at 5 minutes for 15 miunutes and then drops back to 2 seconds or whatever the penalty is for the first bad login.

In other words: Say you many many bad logins. Each bad login causes a 5 minute lock out. You wait 14 minutes, and the next bad login causes a 5 minute lock out. You wait 15 minutes and the lockout is rteset at a few seconds (which doubles with every subsequent bad login until it reaches 5 minutes or whatever Bell's limit is today)

I can't say with 100% certainty if this is the lock-out issue, but it sounds like it. If it is, the problem is with Bell.

It worked like this:

If you connected, then disconnected in under about 1 or 2 minutes then reconnect again, Bell's equipment will prevent you from logging in again for a penalty time of 5 minutes. Think of it like an FTP anti-hammer feature. It prevents you from ever re-connecting.

So now imagine this scenario:

Let's say you have a marginal DSL line and once in a while, due to line errors, your connection just craps out and disconnects.

You attempt to reconnect, but because you just connected and line errors knocked you off, your router is set to immediately reconnect. Bell's anti-hammer (ie Lock-out) mechanism will kick in. Each and eery valid login attempt will the be rejected.

Just like certain FTP anti-hammer features, you have to not generate any login attempts for exactly 5 minutes since your last login attempt, after-which this feature disables and allows you to login.

People who had/have line issues started encountering this back in 2007. It was like a punishment for Bell having bad lines that dropped the connection on you.

Now, going by your symptoms it is possible that this is the issue. I'll rehash your symptoms:

1. You left your router to reconnect the entire night. It never reconnected.

2. Your DSL line craps out on you for no reason (sign of a line problem). When the router auto-reconnects, you are locked out.

3. Stopping the reconnection attempts for X amount of time fixes it.

The only difference with you is that only maybe 2 minutes is required, and not 5 for the lock-out to stop on you. (ie. 2 minutes, enough time to reboot the router, modem and maybe PC).

So if this is the same issue I first encountered in 2007 and which Bell later (a year plus later) confirmed as having a lock-out feature, then maybe they dropped the lock-out time from 5 minutes to around 2 minutes. This is possible.

Also, they set this up different at each BAS at the time (like their throttle boxes). So what you are seeing may not happen to someone else.

Am I 100% certain it's this? Nope. All I can really say is that you have the symptoms of this, but with a lesser lock-out time. Bell could have lessened the time to piss of their customers less.

What you may want to address first is: Why is your connection crapping out on you forcing your router to reconnect. You should be looking at the line stats and checking if there is an issue. Try to see them exactly when the connection fails.

Another thing to try is: Go in your router and disable "reconnect on disconnect" when this happens. See if you can find the magic amount of time. When you disconnect next, don't reboot the router, instead wait 2 minutes with no login attempt, then login. See if you can do this to prove (at least to yourself) it's Bell's lock-out.

Or maybe your router is gone funny on you or something?

Yes, that is what the "spec's say. But that is not how bell deployed it. They did not deploy it per the spec sheet. At least this is not how they configured it at my BAS.

Bell set it for a global 5 minutes. You had to wait for exactly 5 minutes since your last valid login attempt, no matter how many failed valid login attempts you made. You could have had 4 million failed valid login attempts. What you had to do what stop the login attempt for exactly 5 minutes.

You shouldn't call it a "bad login" or "invalid login". This thing very much locks out good and valid logins.

At the time I published the stuff on DSLR, it had been confirmed to me by Bell that bell had implemented the default settings as per the Juniper documentation. and it behaved that way.

Since no login attempt can be made during a lockout (since you don't even get past the PADI/PADO stage), then continued automated login attempts will just fail and not increase the clock and you'll get one attempt allowed after the lockout period. If that one fails, the full amount of lockout restarts.

When you are fresh, then the lockout period is just a couple of second for yoru first invalid attempt. But with each subsequent attempt with 15 minutes of the previous invalid one, it doubles and quickly reaches the maxmimum set in the config,

yes I recall when you posted that PDF or link. It was a good two years (or more) after they actually implemented it. Deadpool had confirmed it with you.

However, deadpool wasn't even aware that this thing was in use at the time (nor the years prior). Even when Bell sent their techs to sit in my home with a stop watch to time the exact 5 minutes, their testing centre didn't know about it. When the tech was transferred to the test centre boss, he didn't even know about it. When the tech then contact one of Bell's engineers in another dept, he didn't even know about it. I had engineers and techs on both ends of my phone looking at login attempts and scratching their heads saying they never saw this before. What deadpool told you or the links he gave you was just the info he was finding out, 2 years or so later. Nothing more. Bell only confirmed it existed like 2 years after the fact. They told me about a year after the fact when I had enough of it and already figured it out on my own, which caused Bell to send the techs to my place to begin with to confirm it.

If you search this Bell forum around 2006 - 2007 or so, you will come across this lock-out. It was introduced over a year before the throttle and some BAS's had it configured some didn't. It's probably still like that or else we would have seen more of it.

The spec sheet is *not* how it was set-up. It was not in it's default settings. Or it wasn't set-up like that on all BAS's.

Don't believe everything they told you. Maybe some were set up like that, but not all, that is for sure.

It was set at a global 5 minutes (at my BAS). Even Bell confirmed this at my home as their techs were here seeing it for the first time ever.

And again, it is not an *"invalid attempt"*. The attempt is very much valid. Bell just locks you out. That's like saying bitTorrent protocol is invalid so you are now disconnect from the net for 5 minutes. heh.

Anyhow, don't believe what they told you. Maybe they had/have some area's set-up like that, but not all. And it's not like deadpool knew what he was talking about with you since he didn't even know about it till i was telling him about it, and he started looking into it almost 2 years later.

Anyhow, it doesn't matter. What matters is that this guy has the symptoms of this, and he should be looking at why his line is crapping out which only causes the lock-out problem to magnify and show itself. One affects the other.

And if all BAS's were set like this (ie all set the same) we would be seeing a lot more of it. So again this leads me to believe not all BAS's have this, or they are not all set the same. Contrary to whatever BS deadpool told you.

Thanks a lot um no! Now I have some rough ideas behind this. I will try to not reconnect next time to see if I can connect after 5 minutes. I checked Tomato's settings and found "Minimum Retry Delay" is set to 5 seconds, is this the time between two login retries? I am wondering if I tweak this so I can make it login automatically if I am away from home (to make home phone work)?

Change that to about 125 seconds.

yes, that would be the setting to putz with to determine if you have the lock-out affecting you. When it happened to me, I was stuck at exactly 5 minutes to the second.

It appears that yours is not at 5-minutes, but something else. This is what you will have to determine.

What you can do to try and make the lock-out kick in is this:

Go into your router (if your router has this feature): Constantly hit connect and disconnect as fast as your router allows you. Try this like 6 times or more till you are locked out (with me it only took one time).

If you are indeed locked-out, set router to connect manually, wait a bit and then hit connect. If it fails, wait a bit longer before you hit connect again till you find the magic number of minutes (or seconds) between login attempts. Keep note of this number and set it in your router so you don't have a repeat of your router trying to connect for 24-hrs again.

If this is the lock-out, you should see it. If you can't force the lock-out to show itself in this way, then maybe the lock-out isn't the problem you are having and something else is going on. I haven't bumped into too many people who actually had the lock-out as bad as my BAS was set up. Nor that many people who actually figured it out.

Let us know what you try and find out. Has me curious.

Sorry but your modem is dead, or somewhat faulty.
Get a new one.
PADO timeouts are usually hardware failure.
Ive experienced that before with my ST516.
Replaced it with a new one and it worked, synced perfect in usual time.
However if replacing it doesnt work, then its something on bells end that has changed.

Interesting. I will give it a try when I am not too busy. Thank you!

Are you sure it's modem's problem? But it's running normally after reboot. And it was synced when my connection dropped.

Not 100%, but it would be a good place to start.
When I has having PADO timeouts over and over, that was from my modem not sending the requested packet out fast enough.
I was explained that PADI was lockout, but continuous PADO timeouts is something wrong with your end, as they are out and not in.
If you are worried about wasting money on a new modem, keep the receipt, and buy it at a place you can return it, or borrow a friends.

I see, it's time to have another modem as a backup. Thanks!
The problem is it's hard to test because this problem occurs quite randomly.

I should clear that up, because what I was explained isnt exactly how it works, or even what it stands for.
A PADO (PPPoE Active Discovery Offer) is a packet that should be sent back to your computer after it sent a PADI.
If no PADO is received after sending a PADI, the message "Timed out waiting for PADO packet" is output to the log.
What that means is the modem didn't reply to a PADI as it should have.
This seems to be largely due to bugs in firmware updates, or physical hardware fault.

Makes sense. That would be the the next thing I would look at as well. It can only be a few things.

Bell's Lock-out, modem/router, or something with his ISP. I can't think of anything else that would cause this.

The lock-out is the fastest thing to check if a spare modem isn't handy yet.

Since he does have disconnection issues, it is possible that the modem is giving up, or it's line issues. I'd be interested in his line stats anyhow while there is no problem, and when the problem occurs to see what's gong on there causing the disconnect.

The PADO error means that your router did not receive a PPPoE "offer" from the BAS.

Technically, a fault in any compinent between BAS and your router could cause this, as would the BAS decising it doesn't like you (lock out).

Loss of sync on the DSL modem would also do this.

(You need to conside rthat the modem is architecturally separate frm the router which does the PPPoE negotiation as they operate at different layers)

The offer may come from the BAS, but if you dont send the reply to the PADI you wont get a PADO, this could be the fault of the modem.

It could, but not for the entire night straight as he experienced.

So i'm leaning towards the lock-out. I guess it is possible something is flukey with his modem/router though tat fixes itself with a reboot.

Up to him to test the lock-out today. It's a fast test to try.

Bets are open till 9 tonight.

I have 2$ on the lock out.

Note on the lock out:

If the ISP is functioning normally, and the router offers the right PPPoE credentials, then you should be able to get back in with the one attempt Bell lets through every 5 minutes.

At my previous ISP, I was locked out for about 4 or 5 hours after they announced service was restored. They still had one router down for maintenance and for some reason, the BAS I was connected to insisted on connecting me to that one router all the time (causing 1 failed login every 5 minutes). Everyone else was up. This was before I knew of the lock out.

The wholesalers welcomed this "feature" when it was found out they had it. I believe it was in this forum that a few of them said it was good for them. TSI, Velcom and i'm not sure if Acanac was also one of them.

This lock-out is f'n stupid. I don't see how they could have agreed it was good.

It is good because it stops users from slamming your infrastructure with login requests. Lets say someone edited their config or had a bug that caused a device to do dozens or hundreds of requests per minute. Now multiply by your subscriber base. Big problem.

I don't know what the max sessions/second limit is for an ERX or E320, but it could be an issue on top of the load to your radius servers.

This happened again early this morning. I was downloading by BT overnight and single line MLPPP was on.

1. Router's min retry delay is 125 sec, but that doesn't help.
2. I reset the modem only this time, and problem solved.
3. I tried connect/disconnect toggle, after about 7 times I got the timeout message again. But after about 1.5 min, it reconnected automatically again.

Any thoughts? From what I saw this morning, maybe it's more likely caused by modem failure?

I had similar symptoms recently. I replaced the modem and no longer have the problem.

Good to know. Mind telling me your old and new modem model and your ISP? Thanks!