# [SOLVED] [PPPoE] PADO timeout dead end

## gdc-t

Hi all,

Two days ago one of those "this is not possible" problems just hit me, being related to PPPoE. Perhaps someone with additional experience could assist me with a hint on what too look for/change in pppd.

Short story:

In one location, my ISP has put a new PPPoE concentrator with some 'magical' results:

Windows (can i say this here?!) works just fine

My Gentoo laptop fails to login to this, i receive timeout every time

If i move the Gentoo laptop to a second geographic location, with the same ISP and same configuration, it works.

Some info on the system, config and traces.

system: http://pastebin.com/2MPDwCLA

PPP version: 2.4.5-r1

PPP config: http://pastebin.com/BFSGKz2u

logs with error: http://pastebin.com/uxD008bx

tcpdump: http://pastebin.com/3UbEG03w

strace on pppd: http://pastebin.com/yK7tAp83

From what i understand using the above details is that pppd does not seem to recognize/decode the PADO responses that are being received (tcpdump).

By looking at the packets received on Gentoo vs Windows again i do not see any differences, so not sure on what is going on here.

Thanks for your time.

PS: if you plan to tell me on raising a case to ISP, don't, already tried this game and 'Linux is not supported'. Hehe ... 2011 but stone age mentality it's still here.

[m\.g]Last edited by gdc-t on Mon Jul 11, 2011 8:15 am; edited 1 time in total

----------

## mbar

This may be a long shot, but maybe try those "holdoff/interval" options?

```
config_ppp0="ppp"

#link_ppp0="eth0"

link_ppp0='0.35'

#plugins_ppp0="pppoe"

plugins_ppp0=("pppoa")

pppoa_ppp0=("0.35")

username_ppp0='ddddd@neostrada.pl'

password_ppp0='ddddddd'

pppd_ppp0="lock

           defaultroute

       noipdefault

       noauth

       persist

       updetach

       holdoff 5

       lcp-echo-interval 30

       lcp-echo-failure 4

       asyncmap 0"

```

----------

## gdc-t

Hi mbar,

Passed now quick over man page and see that holdoff is related to link control, but the errors that i put happen way before link control.

As i've noticed before link control there are 2 requests initialized by the client PADI, PADR and two responses by server PADO and PADS.

My Linux box stops after first response... bump

A more detailed paste from the location where this works shows the steps:

http://pastebin.com/cxLJTRSr

Thanks for the suggestion.

[m\.g]

----------

## krinn

ioctl(7, SIOCGIFMTU, {ifr_name="eth1", ifr_mtu=1500}) = 0

check your mtu this can cause the no answer/drop packet

1500 is standard mtu for ethernet, but you're using pppoe so your speaking directly with the isp barebone and your mtu might be little too high (if just a bit too high, some datas works and then fail, as your packets are too big, they are just ignore by the interface)

- you may try to lower your mtu and guess (dunno how) the valid value, my previous isp was using 1496, i know just 4 bytes diff, but it could make a big diff. try that.

- i think if you lower it, you "should" only get bad effect of slowing the connection, so you might just try lowered values (don't goes down bellow 1400 i don't think bellow should be good)

- you may also just check your network card under windows and (sorry dunno how/if it's possible) grab the mtu the ethernet card is configure from that working env.

- this might also explain why it work as-is at some place and never at some other. Some icmp protect... can make the mtu discovery fail, a stronger way to discover the mtu value can be use, it might be use in windows and not in ppp so windows can guess right the mtu.

good reading there http://en.wikipedia.org/wiki/Point-to-Point_Protocol_over_Ethernet and http://en.wikipedia.org/wiki/Maximum_transmission_unit and also failure explain http://en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD

Well, all this blahblah maybe for nothing, best for you is to find a way to see mtu on windows when the connection is working to see its value. But mtu trouble was what comes to my mind when i read your problem.

----------

## gdc-t

Thanks for your explanation krinn.

Will try to give this mtu guessing game a go, perhaps will break the deadlock i'm in  :Very Happy: 

----------

## mbar

 *gdc-t wrote:*   

> Passed now quick over man page and see that holdoff is related to link control, but the errors that i put happen way before link control.
> 
> 

 

But did you or did you not try those lcp-echo-interval, lcp-echo-failure options? Or did you only read man page?

----------

## gdc-t

Hi mbar, guys

First of all thanks for the help.

This w/e had some time to reanalyze the behavior and made a breakthrough by observing that the ISP was actually sending a VLAN tagged packet response (PADO).

It was very peculiar as i did initially take Wireshark traces on the Windows system and the tagging is not visible there, not sure why this difference as i tested both systems on same link ?!

So i decided to set the network interface on the Gentoo box to the same VLAN address as my ISP and this did the trick.

So yeah .. a very curious resolution to a strange problem.

[m\.g]

----------

