Pointer on "Timeout waiting for PADO packets"

Hi *,

I used to have the following problem like many others in the community (source: No PPPoE connection) with my Telekom VDSL50 internet connection:

daemon.warn pppd[2652]: Timeout waiting for PADO packets
daemon.err pppd[2652]: Unable to complete PPPoE Discovery

And, I looked up every possible page, but couldn't find any problem with my "/etc/config/network" file on the TD-W8970 with LEDE 17.01.2 (r3435-65eec8bd5f):

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr ''
	option netmask ''

config globals 'globals'
	option ula_prefix 'fdfa:768b:94d9::/48'

config atm-bridge 'atm'
	option vpi '1'
	option vci '32'
	option encaps 'llc'
	option payload 'bridged'

config dsl 'dsl'
	option xfer_mode 'ptm'
	option annex 'b'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option netmask ''
	option ipaddr ''
	option ip6assign '64'

config interface 'wan'
	option proto 'pppoe'
	option ipv6 'auto'
	option _orig_ifname 'ptm0'
	option _orig_bridge 'false'
	option ifname 'ptm0.7'
	option username 'XXXXX'
	option password 'XXXXX'
	option keepalive '3 2'
	option persist '1'
	option holdoff '5'

config device 'wan_dev'
	option name 'ptm0'
	option macaddr 'XX:XX:XX:XX:XX:XX'

config interface 'wan6'
	option ifname 'pppoe-wan'
	option proto 'dhcpv6'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option vid '1'
	option ports '0 2 4 5 6t'

The Telekom technicians took care of the telephone cabling and setting up the telephone system "Octopus E". As we are now using only the mobile phone, I spent some time yesterday, turned off the telefone system, changed the telephone cabling and connected my TD-W8970 on ground floor directly with the splitter in the basement. The devices are connected now that way:

"First TAE-outlet" <---> splitter <---> TD-W8970

My DSL connection is now online for 18 hours. Previously, it disconnected with the log message "Timeout waiting for PADO packets" after every 2-3 hours and I had to reboot the router. AFAIK, It seems that my telephone system somehow interfered with my DSL connection. I am not quite sure.

If you are using a telephone system like the "Octopus E" and connecting the router to the first TAE-outlet doesn't help, my scripts that I have used previously might be helpful:

root@LEDE:~# cat /etc/hotplug.d/net/99-check_wan 
if [ "$ACTION" = "remove" ] && [ "$INTERFACE" = "pppoe-wan" ]; then
   (/root/check_wan.sh >/dev/null 2>&1) &

Above code is called by hotplug after your wan device, which holds the wan ip address, is turned off.

The code below checks the logs for five minutes for the message "Timeout waiting for PADO packets" once every second. If such a message exists and this message has been created within the last 5 minutes, the device is rebooted.

root@LEDE:~# ls -l /root/check_wan.sh 
-rwxr-xr-x    1 root     root           410 Sep 17 18:04 /root/check_wan.sh
root@LEDE:~# cat /root/check_wan.sh 
START_TIME="$(/bin/date +%s)"
while [ $(($(/bin/date +%s) - START_TIME)) -lt 300 ]; do
   PADO_LOG_TIME="$(/sbin/logread -t | /bin/grep "Timeout waiting for PADO packets" | /usr/bin/tail -n 1 | /usr/bin/awk -F"[" '{print $2}' | /usr/bin/awk -F"." '{print $1}')"
   if [ ! -z "$PADO_LOG_TIME" ] && [ $(($(/bin/date +%s) - PADO_LOG_TIME)) -lt 300 ]; then
   /bin/sleep 1s

Don't forget to make the 2nd script executable, change the wan device in the 1st script as needed and use them at your own risk.

Best regards,

Are you sure that you still need the splitter (obviously you do in case of PSTN or ISDN)? It's possible for older/ existing contracts, but DTAG is moving towards splitterless VoIP setups, often combined with vectoring (even for slower, sub-100-MBit/s contracts which wouldn't need it).

Thanks for the hint. The TD-W8970 works perfectly without the splitter using annex B. I'll keep an eye on the DSL connection stability.

Like slh said, DSL "splitters" are used to remove the DSL signal from the conventional PSTN or POTS analog phone service that may be provided on the same line. DSL activity sounds like loud high-frequency noise on phone calls if it is not filtered out. Since the intent of the filter is to block DSL frequencies, connecting the modem on the wrong side of the splitter will cause a poor or no connection.

If you don't have analog phone service, connect the DSL modem directly to the line using a straight run of cat3 or cat5 wiring. Have no branches at all is best.

If you do have analog phone service, branch off once through your splitter, then connect all the existing phone wiring and phones onto the downstream side of the splitter. This way there is no DSL signal on the old wires, which can load it down.

Just to be clear, what mk24 said applies to analogue phone and ISDN as well.

1 Like

Ive learnt PADO timeouts are usually caused by invalid vci/vpi values. In ontario its 0 and 35.

Well, VCI/VPI being wrong can be an issue with ATM/ADSL links, but with PTM/VDSL links these are immaterial. Anything that prohibits a connection between the two endpoints of the pppoe-tunnel will cause the PADO timeouts, so on adsl it certainly can be the wrong VCI/VPI, but I am not yet fully convinced yet that this is the most common root cause.

I don't think there is a common cause.

In some cases, ISP's will lock out a connection for a pre-determined period if you connect, then disconnect in less than say 1 to 2 minutes, then try to connect again.

Similar to an FTP anti-hammer feature.

Well, im not trying to convince anyone. Just puttin two cents in is all. If someone made the comment I did anywhere online it would have saved me about 4 hours troubleshooting. This is the second or third response in google for pado timeout and thought maybe i could save someone else time. Didnt mean to get your wires in a bunch.

^^^ This! So I usually disconnect the modem from the line for 5 minutes before changing gear on it.

But sometimes the ISP will stop responding to the PADI until they do something on their end; on Windstream they call it 'rebuild the cross-connects' for the line, and requires a ticket to Engineering (or a level 2/3 tech on the line). It starts working within minutes of them doing that.

Another common cause for this is to get the line quarantined by the ISP because the user miss-wired the modem (e.g. bridge DSL modem) to the LAN ports of the router, thus letting the household devices DHCP request hit the ISP DHCP server, which then freaks out about a line having so many DHCP devices, that it quarantines it. Takes a call to a second level tech to get that reset.
I know this because I have a couple of neighbors that have pulled that stunt :wink:

How about we turn this into a list of known causes which obviously includes your observed failure mode as well. I think a list of confirmed root causes for this commonly encountered error might help to show the breadth of potential causes while at the same time give a list of actionable items that an afflicted user might check? Since this is your post, I feel this should be your decision...

Good idea, should be put into the wiki.