PPPoE doesn't work

Hello!

I have a problem with starting pppoe.


Distribution: CentOS

Packages installed in system:

ppp-2.4.4-1.el5
rp-pppoe-3.5-32.1



File /etc/options:

debug
auth
-pap
+chap

refuse-pap
require-chap

ms-dns xx.xx.xx.xx



File /etc/pppoe-server-options:


# PPP options for the PPPoE server
# LIC: GPL
lock
local
require-chap
default-mru
default-asyncmap
proxyarp
ktune
login
lcp-echo-interval 20
lcp-echo-failure 2
nobsdcomp
noccp
noendpoint
noipdefault
noipx
novj
receive-all
proxyarp



And now... PPPoE server is starting:

pppoe-server -I eth1 -L xx.xx.xx.xx -T 40 -C xxx -S xxx -N 1024



Trying to connect... Logs:


using channel 37
Using interface ppp0
Connect: ppp0 <--> /dev/pts/7
sent [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xae7423f9>]
sent [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xae7423f9>]
rcvd [LCP ConfReq id=0x1 <mru 1492> <magic 0xdbb91a91>]
sent [LCP ConfRej id=0x1 <mru 1492>]
sent [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xae7423f9>]
sent [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xae7423f9>]
rcvd [LCP ConfReq id=0x1 <mru 1492> <magic 0xdbb91a91>]
sent [LCP ConfRej id=0x1 <mru 1492>]
sent [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xae7423f9>]
sent [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xae7423f9>]
rcvd [LCP ConfReq id=0x1 <mru 1492> <magic 0xdbb91a91>]
sent [LCP ConfRej id=0x1 <mru 1492>]
sent [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xae7423f9>]
sent [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xae7423f9>]
rcvd [LCP ConfReq id=0x1 <mru 1492> <magic 0xdbb91a91>]
sent [LCP ConfRej id=0x1 <mru 1492>]
sent [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xae7423f9>]
sent [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xae7423f9>]
Terminating on signal 15
sent [LCP TermReq id=0x2 "User request"]
sent [LCP TermReq id=0x3 "User request"]
Connection terminated.
Modem hangup
Waiting for 1 child processes...
script /usr/sbin/pppoe -n -I eth1 -e 6:00:19:e3:42:3e:60 -S ' -T 40',
pid 24274
sending SIGTERM to process 24274


And nothing happened. Session hangs:


root 15564 0.0 0.1 1644 448 ? S 00:33 0:00
/usr/sbin/pppoe -n -I eth1 -e 1:00:0f:3d:de:84:c6xxx -S -T 40



What should I do to start it correct?


Pozdrawiam,
Uncle Bart
--
* Bart³omiej F. Tajchman +48 781 871 861 *
* http://www.bart.merigold.krakow.pl GG #162270 *
* http://www.bykom-stop.avx.pl skype: wuj_bart_27 *
* Niebo gwia¼dziste nade mn±, o¶lizg³e flaki we mnie. *

Hello,

Bartlomiej F. Tajchman a écrit :
>
> I have a problem with starting pppoe.
[...]

> File /etc/pppoe-server-options:
[...]
> default-mru
[...]

> Trying to connect... Logs:
[...]
> rcvd [LCP ConfReq id=0x1 <mru 1492> <magic 0xdbb91a91>]
> sent [LCP ConfRej id=0x1 <mru 1492>]

The local pppd rejects the MRU negotiation.

Quoted from pppd manpage :
================================================== =====================
default-mru
Disable MRU [Maximum Receive Unit] negotiation. With this
option, pppd will use the default MRU value of 1500 bytes for
both the transmit and receive direction.
================================================== =====================

Remove default-mru from your options file.

> script /usr/sbin/pppoe -n -I eth1 -e 6:00:19:e3:42:3e:60 -S ' -T 40',
> pid 24274

Note that the -S parameter seems to be incorrectly passed by
pppoe-server to the pppoe child process.
Cf. <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313476>

Pascal Hambourg pisze:

> Hello,
>
> Bartlomiej F. Tajchman a écrit :
>>
>> I have a problem with starting pppoe.
> [...]
>
>> File /etc/pppoe-server-options:
> [...]
>> default-mru
> [...]
>
>> Trying to connect... Logs:
> [...]
>> rcvd [LCP ConfReq id=0x1 <mru 1492> <magic 0xdbb91a91>]
>> sent [LCP ConfRej id=0x1 <mru 1492>]
>
> The local pppd rejects the MRU negotiation.
>
> Quoted from pppd manpage :
> ================================================== =====================
> default-mru
> Disable MRU [Maximum Receive Unit] negotiation. With this
> option, pppd will use the default MRU value of 1500 bytes for
> both the transmit and receive direction.
> ================================================== =====================
>
> Remove default-mru from your options file.

I removed it and started pppoe with minimal configuration:

options:

debug
plugin rp-pppoe.so
asyncmap 0
login
lock
+pap
+chap

pppoe-server-options



require-pap
require-chap
require-mschap-v2
login
lcp-echo-interval 20
lcp-echo-failure 2
ms-dns xx.xx.xx.xx


Connection still doesn't work:

Connect: ppp0 <--> /dev/pts/3
sent [LCP ConfReq id=0x1 <mru 1492> <auth chap MS-v2> <magic 0xd512cef1>]
rcvd [LCP ConfReq id=0x1 <mru 1480> <magic 0x12614217> <callback CBCP>]
sent [LCP ConfRej id=0x1 <callback CBCP>]
sent [LCP ConfReq id=0x1 <mru 1492> <auth chap MS-v2> <magic 0xd512cef1>]

etc.

I haven't ConfAck and it doesn't try to send password/user. I tried it
with PAP/CHAP/MS-CHAP-v2 - the same (no) effect.


Pozdrawiam,
Uncle Bart
--
* Bart?omiej F. Tajchman +48 781 871 861 *
* http://www.bart.merigold.krakow.pl GG #162270 *
* http://www.bykom-stop.avx.pl skype: wuj_bart_27 *
* Niebo gwiaz'dziste nade mna;, os'lizg?e flaki we mnie. *

Bartlomiej F. Tajchman a écrit :
>
> options:
>
> debug
> plugin rp-pppoe.so
> asyncmap 0
> login
> lock
> +pap
> +chap

Not sure that "plugin rp-pppoe.so" is required for a server
configuration. Not sure about how pppd will handle multiple
authentication protocol requirements too.

> pppoe-server-options
>
> require-pap
> require-chap
> require-mschap-v2
> login
> lcp-echo-interval 20
> lcp-echo-failure 2
> ms-dns xx.xx.xx.xx
>
>
> Connection still doesn't work:
>
> Connect: ppp0 <--> /dev/pts/3
> sent [LCP ConfReq id=0x1 <mru 1492> <auth chap MS-v2> <magic 0xd512cef1>]
> rcvd [LCP ConfReq id=0x1 <mru 1480> <magic 0x12614217> <callback CBCP>]

MRU 1480, callback control protocol... you tried to connect from a
Windows machine, didn't you ?

> sent [LCP ConfRej id=0x1 <callback CBCP>]

Nothing wrong here, I have the same when I connect from a Windows
station to my Linux PPTP server.

> sent [LCP ConfReq id=0x1 <mru 1492> <auth chap MS-v2> <magic 0xd512cef1>]
>
> etc.

Looking again at your logs, they show no received ConfAck or ConfRej
replies to the server ConfReq nor reactions to the server ConfRej, only
retries of the same ConfReq. It looks very much like the remote peer
does not see the server requests or replies. Now I remember an old bug
on Debian with pppoe-server and "recent" versions of pppd (2.4.1 worked
fine, 2.4.3 didn't) which caused packets sent by pppd not to be
transmitted on the ethernet wire when pppoe-server used the user-mode
pppoe. You can check this with a packet sniffer like tcpdump or
ethereal/wireshark. A workaround was to tell pppoe-server to use the
kernel-mode pppoe module with the -k option (which was disabled on
Debian at that time, duh).

Bartlomiej F. Tajchman <(E-Mail Removed)> wrote:
> Pascal Hambourg pisze:
>>
>> Remove default-mru from your options file.

> I removed it and started pppoe with minimal configuration:

Please DON'T change configurations unless someone suggested the change.
Restore the original options, sans the default-mru of course.

> options:

> debug
> plugin rp-pppoe.so

It's highly unlikely you are attempting kernel mode PPPoE, as desirable
as that might be.

<snip>

> Connection still doesn't work:

> Connect: ppp0 <--> /dev/pts/3
> sent [LCP ConfReq id=0x1 <mru 1492> <auth chap MS-v2> <magic 0xd512cef1>]
> rcvd [LCP ConfReq id=0x1 <mru 1480> <magic 0x12614217> <callback CBCP>]
> sent [LCP ConfRej id=0x1 <callback CBCP>]
> sent [LCP ConfReq id=0x1 <mru 1492> <auth chap MS-v2> <magic 0xd512cef1>]

> etc.

As PH has observed, the LCP messages sent to the peer are either corrupted
or lost in transit. Since they are sent through pppoe-server it seems
likely that pppoe-server is part of the problem.

> I haven't ConfAck and it doesn't try to send password/user. I tried it
> with PAP/CHAP/MS-CHAP-v2 - the same (no) effect.

You didn't mention the pppoe-server bug PH pointed out. That must
be fixed. Even if it's not part of the current problem it will cause
another problem later. A pristine rp-pppoe-3.8 doesn't have the bug.

--
Clifford Kite
/* 97.3% of all statistics are made up. */

Clifford Kite a écrit :
>
> As PH has observed, the LCP messages sent to the peer are either corrupted
> or lost in transit. Since they are sent through pppoe-server it seems
> likely that pppoe-server is part of the problem.

Actually, PPP packets are not sent through pppoe-server but through
pppoe which is invoked by pppd with a 'pty' option. pppoe-server handles
the PPPoE discovery phase, and pppoe handles the PPPoE session phase.
According to <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298582>
the bug seems to lie in pppd which invokes pppoe with file descriptor 0
closed. Dunno if it was fixed in later upstream pppd versions.

Pascal Hambourg a écrit :
> Clifford Kite a écrit :
>
>> As PH has observed, the LCP messages sent to the peer are either corrupted
>> or lost in transit. Since they are sent through pppoe-server it seems
>> likely that pppoe-server is part of the problem.
>
> Actually, PPP packets are not sent through pppoe-server but through
> pppoe which is invoked by pppd with a 'pty' option. pppoe-server handles
> the PPPoE discovery phase, and pppoe handles the PPPoE session phase.
> According to <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298582>
> the bug seems to lie in pppd which invokes pppoe with file descriptor 0
> closed. Dunno if it was fixed in later upstream pppd versions.

However you're right when you say that pppoe-server is part of the
problem : the bug in pppd is triggered because pppoe-server invokes pppd
with no file descriptors open.

Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
> Clifford Kite a écrit :
>>
>> As PH has observed, the LCP messages sent to the peer are either corrupted
>> or lost in transit. Since they are sent through pppoe-server it seems
>> likely that pppoe-server is part of the problem.

> Actually, PPP packets are not sent through pppoe-server but through
> pppoe which is invoked by pppd with a 'pty' option. pppoe-server handles
> the PPPoE discovery phase, and pppoe handles the PPPoE session phase.

Right. I realized that "through pppoe-server" wasn't really correct
after posting. But the bug in pppoe-server (from your first post)
might cause a session parameter the client uses to be different from
what pppoe expects it to use.

In particular from the OP's original post:

And nothing happened. Session hangs:


root 15564 0.0 0.1 1644 448 ? S 00:33 0:00
/usr/sbin/pppoe -n -I eth1 -e 1:00:0f:3d:de:84:c6xxx -S -T 40

This is consistent with xxx being the session service name that should
be added to the parameter list as "-S xxx" but which the bug causes to
be appended to the client Ethernet address.

> According to <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298582>
> the bug seems to lie in pppd which invokes pppoe with file descriptor 0
> closed. Dunno if it was fixed in later upstream pppd versions.

That bug appears to be fixed in pppd 2.4.4.

Regards-
--
Clifford Kite

Clifford Kite a écrit :
>
> I realized that "through pppoe-server" wasn't really correct
> after posting. But the bug in pppoe-server (from your first post)
> might cause a session parameter the client uses to be different from
> what pppoe expects it to use.
>
> In particular from the OP's original post:
>
> And nothing happened. Session hangs:
>
> root 15564 0.0 0.1 1644 448 ? S 00:33 0:00
> /usr/sbin/pppoe -n -I eth1 -e 1:00:0f:3d:de:84:c6xxx -S -T 40
>
> This is consistent with xxx being the session service name that should
> be added to the parameter list as "-S xxx" but which the bug causes to
> be appended to the client Ethernet address.

Yes, but I don't think it harms. Here is the code scanning the -e
command line option in pppoe.c :

/* Existing session: "sess:xx:yy:zz:aa:bb:cc" where "sess" is
session-ID, and xx:yy:zz:aa:bb:cc is MAC-address of peer */
n = sscanf(optarg, "%u:%2x:%2x:%2x:%2x:%2x:%2x",
&s, &m[0], &m[1], &m[2], &m[3], &m[4], &m[5]);

IIRC the sscanf() function should safely ignore extra characters after
the last hex digit of the MAC address. Also, after checking in RFC 2516,
it appears that the service name is not used during the PPPoE session
phase, so it does not matter if it has the wrong value. By the way I
wonder why the service name is even passed to pppoe. The fact that PPP
packets from the peer are received by pppd indicates that the MAC
address of the peer was correctly read from the command line.

Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
> Clifford Kite a écrit :
>>
>> root 15564 0.0 0.1 1644 448 ? S 00:33 0:00
>> /usr/sbin/pppoe -n -I eth1 -e 1:00:0f:3d:de:84:c6xxx -S -T 40
>>
>> This is consistent with xxx being the session service name that should
>> be added to the parameter list as "-S xxx" but which the bug causes to
>> be appended to the client Ethernet address.

> Yes, but I don't think it harms. Here is the code scanning the -e
> command line option in pppoe.c :

> /* Existing session: "sess:xx:yy:zz:aa:bb:cc" where "sess" is
> session-ID, and xx:yy:zz:aa:bb:cc is MAC-address of peer */
> n = sscanf(optarg, "%u:%2x:%2x:%2x:%2x:%2x:%2x",
> &s, &m[0], &m[1], &m[2], &m[3], &m[4], &m[5]);

> IIRC the sscanf() function should safely ignore extra characters after
> the last hex digit of the MAC address.

It does seem so, although I found the sscanf man pages weren't definitive
enough for me to say extra characters would be ignored. (And finding and
examining sscanf code is beyond my endurance limits.

> Also, after checking in RFC 2516,
> it appears that the service name is not used during the PPPoE session
> phase, so it does not matter if it has the wrong value. By the way I
> wonder why the service name is even passed to pppoe.

Good question!

> The fact that PPP
> packets from the peer are received by pppd indicates that the MAC
> address of the peer was correctly read from the command line.

So I guess pppoe must ignore session frames that don't contain the peer
MAC from the -e option as the AC MAC. I hadn't thought of that.

Regards-
--
Clifford Kite
/* 97.3% of all statistics are made up. */