[SOLVED] [PPPoE] PADO timeout dead end

gdc-t · n00b Joined: 05 Jul 2011 Posts: 4

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]

mbar · Veteran Joined: 19 Jan 2005 Posts: 1991 Location: Poland

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

gdc-t · n00b Joined: 05 Jul 2011 Posts: 4

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 · Watchman Joined: 02 May 2003 Posts: 7470

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 · n00b Joined: 05 Jul 2011 Posts: 4

Thanks for your explanation krinn.
Will try to give this mtu guessing game a go, perhaps will break the deadlock i'm in

mbar · Veteran Joined: 19 Jan 2005 Posts: 1991 Location: Poland

gdc-t · n00b Joined: 05 Jul 2011 Posts: 4

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]