Page 1 of 2

PPPoE RFC4638

Posted: 03 Apr 2016, 23:48
by zash
Hello,

Does accel-ppp support RFC4638 (1500 PPPoE MTU?)

Thank you.

Re: PPPoE RFC4638

Posted: 04 Apr 2016, 05:11
by Dmitry
hi,
no, it doesn't

Re: PPPoE RFC4638

Posted: 04 Apr 2016, 07:55
by Dmitry
you can test this commit b29c9326c2630a0375a9d92b0c553b6e60c8cdaa

Re: PPPoE RFC4638

Posted: 04 Apr 2016, 15:01
by zash
Wow, this was quick didn't expect it.

Tested it against a Mikrotik pppoe client that supports rfc4638:

== Before ==

mikrotik pppoe-client settings:
max mtu = 1480
max mru = 1480

accel-ppp server settings:
eth0 mtu = 1500
eth0.10 mtu = 1500
pppoe interface = eth0.10

[2012-04-30 09:50:36]: info: recv [PPPoE PADI e4:8d:8c:13:a4:99 => ff:ff:ff:ff:ff:ff sid=0000 <Host-Uniq 009b0058> <Service-Name > <PPP-Max-Payload 1480> <Vendor-Specific de9>]
[2012-04-30 09:50:36]: info: send [PPPoE PADO 00:21:91:8b:41:fe => e4:8d:8c:13:a4:99 sid=0000 <AC-Name accel-ppp> <Service-Name > <AC-Cookie 5b6492177be550ee5805a96917a1ad402f8ad31b5021b311> <Host-Uniq 009b0058> <PPP-Max-Payload 1492>]


$ ifconfig

ppp0 Link encap:Point-to-Point Protocol
inet addr:10.10.10.1 P-t-P:10.10.10.100 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1480 Metric:1
RX packets:22 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1847 (1.8 KiB) TX bytes:1759 (1.7 KiB)


$ ping -M do -s 1472 10.10.10.100
PING 10.10.10.100 (10.10.10.100) 1472(1500) bytes of data.
ping: local error: Message too long, mtu=1480
ping: local error: Message too long, mtu=1480


== After ==

mikrotik pppoe-client settings:
max mtu = 1500
max mru = 1500

accel-ppp server settings:
eth0 mtu = 1508
eth0.10 mtu = 1508
pppoe interface = eth0.10


[2012-04-30 10:06:29]: info: recv [PPPoE PADI e4:8d:8c:13:a4:99 => ff:ff:ff:ff:ff:ff sid=0000 <Host-Uniq 009b0022> <Service-Name > <PPP-Max-Payload 1500> <Vendor-Specific de9>]
[2012-04-30 10:06:29]: info: send [PPPoE PADO 00:21:91:8b:41:fe => e4:8d:8c:13:a4:99 sid=0000 <AC-Name accel-ppp> <Service-Name > <AC-Cookie 5e75ac1b26dcbab9fa8df3598013ec5c53e3d84d5e577453> <Host-Uniq 009b0022> <PPP-Max-Payload 1500>]

$ ifconfig

ppp0 Link encap:Point-to-Point Protocol
inet addr:10.10.10.1 P-t-P:10.10.10.100 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:32 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1544 (1.2 KiB) TX bytes:1259 (2.7 KiB)

$ ping -M do -s 1472 10.10.10.100
PING 10.10.10.100 (10.10.10.100) 1472(1500) bytes of data.
1480 bytes from 10.10.10.100: icmp_seq=1 ttl=64 time=1.75 ms
1480 bytes from 10.10.10.100: icmp_seq=2 ttl=64 time=1.70 ms

$ ping -M do -s 1473 10.10.10.100
PING 10.10.10.100 (10.10.10.100) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500

Everything seems to work!

Thank you.

Re: PPPoE RFC4638

Posted: 10 Apr 2016, 02:06
by zash
Hi,

Now that I had an opportunity to test it more fully I noticed a problem on the Mikrotik client that I missed earlier.

Code: Select all

/interface ethernet
set [ find default-name=ether1 ] mtu=1508
/interface pppoe-client
add add-default-route=yes allow=chap disabled=no interface=ether1\
    max-mru=1500 max-mtu=1500 name=pppoe-out1 password=user use-peer-dns=yes \
    user=user
With these settings above I get MRU 1500 but only MTU 1480 with accel-ppp (If I set max-mtu=1492 on Mikrotik client I get MTU 1492 but never more with accel-ppp)

Code: Select all

          status: connected
          uptime: 2m3s
    active-links: 1
        encoding: 
    service-name: 
         ac-name: accel-ppp
          ac-mac: 00:21:91:8b:41:fe
             mtu: 1480
             mru: 1500
   local-address: 10.10.10.100
  remote-address: 172.16.16.1
With the same settings I get full 1500 MRU and 1500 MTU with mikrotik pppoe server:

Code: Select all

          status: connected
          uptime: 4m33s
    active-links: 1
        encoding: 
    service-name: 
         ac-name: MikroTik
          ac-mac: e4:8d:8c:13:a4:9b
             mtu: 1500
             mru: 1500
   local-address: 10.10.10.100
  remote-address: 172.16.16.1
I performed a pcap tcpdump of (PADI+PADO+PADR+PADS+LCP+IPCP+CHAP) session:

Mikrotik client to Mikrotik pppoe server: https://drive.google.com/file/d/0Byh7EQ ... sp=sharing

Mikrotik client to Accel-ppp server: https://drive.google.com/file/d/0Byh7EQ ... sp=sharing

There are some differences, like:
- Accel-ppp sends AC-Cookie in PADO, Mikrotik server doesn't.
- Accel-ppp sends MRU in LCP Config request, Mikrotik server doesn't
but I don't see really much difference, except maybe that the order of PPP packets is different but I don't know if it's relevant.

the code in pppoe.c is pretty simple for PPP-Max-Payload and I don't see any errors, if there's any then I think it would be in the LCP code, but I have no idea what would cause the Mikrotik client not negotiate 1500 MTU with accel-ppp (when it negotiates to 1500 MTU against a Mikrotik server correctly).

Here's full accel-ppp debug log:

Code: Select all

[2012-04-30 07:11:41]:   msg: accel-ppp version 1.10.0
[2012-04-30 07:11:41]: debug: shaper: time_range_begin_timer: id=2
[2012-04-30 07:11:41]:  info: eth0: recv [PPPoE PADI e4:8d:8c:13:a4:5d => ff:ff:ff:ff:ff:ff sid=0000 <Host-Uniq 0181008c> <Service-Name > <PPP-Max-Payload 1500>]
[2012-04-30 07:11:41]:  info: eth0: send [PPPoE PADO 00:21:91:8b:41:fe => e4:8d:8c:13:a4:5d sid=0000 <AC-Name  accel-ppp> <Service-Name > <AC-Cookie f5535576800e1b53c57a09f6beeaa4f75206c3a19aa1f7f0> <Host-Uniq 0181008c> <PPP-Max-Payload 1500>]
[2012-04-30 07:11:41]:  info: eth0: recv [PPPoE PADR e4:8d:8c:13:a4:5d => 00:21:91:8b:41:fe sid=0000 <Host-Uniq 0181008d> <Service-Name > <PPP-Max-Payload 1500> <AC-Cookie f5535576800e1b53c57a09f6beeaa4f75206c3a19aa1f7f0>]
[2012-04-30 07:11:41]:  info: eth0: send [PPPoE PADS 00:21:91:8b:41:fe => e4:8d:8c:13:a4:5d sid=0001 <AC-Name accel-ppp> <Service-Name > <Host-Uniq 0181008d> <PPP-Max-Payload 56325>]
[2012-04-30 07:11:41]: debug: eth0: lcp_layer_init
[2012-04-30 07:11:41]: debug: eth0: auth_layer_init
[2012-04-30 07:11:41]: debug: eth0: ccp_layer_init
[2012-04-30 07:11:41]: debug: eth0: ipcp_layer_init
[2012-04-30 07:11:41]: debug: eth0: ipv6cp_layer_init
[2012-04-30 07:11:41]: debug: eth0: ppp establishing
[2012-04-30 07:11:41]: debug: eth0: lcp_layer_start
[2012-04-30 07:11:41]:  info: eth0: send [LCP ConfReq id=1 <auth CHAP-md5> <magic 6b8b4567>]
[2012-04-30 07:11:41]:  info: eth0: recv [LCP ConfReq id=32 <magic 7641ac61> < 11 4 6 40 >]
[2012-04-30 07:11:41]:  info: eth0: send [LCP ConfRej id=32  < 11 4 6 40 >]
[2012-04-30 07:11:41]:  info: eth0: recv [LCP ConfReq id=33 <magic 7641ac61>]
[2012-04-30 07:11:41]:  info: eth0: send [LCP ConfAck id=33 ]
[2012-04-30 07:11:42]:  info: eth0: recv [LCP ConfReq id=34 <magic 7641ac61>]
[2012-04-30 07:11:42]:  info: eth0: send [LCP ConfAck id=34 ]
[2012-04-30 07:11:44]:  info: eth0: recv [LCP ConfReq id=35 <magic 7641ac61>]
[2012-04-30 07:11:44]:  info: eth0: send [LCP ConfAck id=35 ]
[2012-04-30 07:11:44]: debug: eth0: fsm timeout 9
[2012-04-30 07:11:44]:  info: eth0: send [LCP ConfReq id=1 <auth CHAP-md5> <magic 6b8b4567>]
[2012-04-30 07:11:44]:  info: eth0: recv [LCP ConfAck id=1 <auth CHAP-md5> <magic 6b8b4567>]
[2012-04-30 07:11:44]: debug: eth0: lcp_layer_started
[2012-04-30 07:11:44]: debug: eth0: auth_layer_start
[2012-04-30 07:11:44]:  info: eth0: send [CHAP Challenge id=1 <96d1158c9d1a818b1aa8cd5ee8cecd79>]
[2012-04-30 07:11:44]:  info: eth0: recv [CHAP Response id=1 <a5fbd49c752c37a12e3c53680ad265e>, name="user"]
[2012-04-30 07:11:44]: debug: eth0: radius(1): req_enter 1
[2012-04-30 07:11:44]:  info: eth0: send [RADIUS(1) Access-Request id=1 <User-Name "user"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 127.0.0.1> <NAS-Port 4294967295> <NAS-Port-Id ""> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "e4:8d:8c:13:a4:5d"> <Called-Station-Id "00:21:91:8b:41:fe"> <CHAP-Challenge > <CHAP-Password >]
[2012-04-30 07:11:44]: debug: eth0: radius(1): req_exit 0
[2012-04-30 07:11:44]:  info: eth0: recv [RADIUS(1) Access-Accept id=1 <Filter-Id "1,8192/2048"> <Filter-Id "2,10240/2048"><Microsoft MS-Secondary-DNS-Server 8.8.4.4><Microsoft MS-Primary-DNS-Server 8.8.8.8> <Framed-IP-Address 10.10.10.100>]
[2012-04-30 07:11:44]:  info: ppp0: connect: ppp0 <--> pppoe(e4:8d:8c:13:a4:5d)
[2012-04-30 07:11:44]: debug: ppp0: ppp connected
[2012-04-30 07:11:44]:  info: ppp0: send [CHAP Success id=1 "Authentication succeeded"]
[2012-04-30 07:11:44]: debug: ppp0: auth_layer_started
[2012-04-30 07:11:44]: debug: ppp0: ccp_layer_start
[2012-04-30 07:11:44]: debug: ppp0: ipcp_layer_start
[2012-04-30 07:11:44]:  info: ppp0: send [IPCP ConfReq id=1 <addr 172.16.1.1>]
[2012-04-30 07:11:44]: debug: ppp0: ipv6cp_layer_start
[2012-04-30 07:11:44]:  info: ppp0: user: authentication succeeded
[2012-04-30 07:11:44]:  info: ppp0: recv [IPCP ConfReq id=f <addr 0.0.0.0> <dns1 0.0.0.0> <dns2 0.0.0.0>]
[2012-04-30 07:11:44]:  info: ppp0: send [IPCP ConfNak id=f <addr 10.10.10.100> <dns1 8.8.8.8> <dns2 8.8.4.4>]
[2012-04-30 07:11:44]:  info: ppp0: recv [IPCP ConfAck id=1 <addr 172.16.1.1>]
[2012-04-30 07:11:44]: error: ppp0: ppp_chan_read: Value too large for defined data type
[2012-04-30 07:11:44]:  info: ppp0: recv [IPCP ConfReq id=10 <addr 10.10.10.100> <dns1 8.8.8.8> <dns2 8.8.4.4>]
[2012-04-30 07:11:44]:  info: ppp0: send [IPCP ConfAck id=10]
[2012-04-30 07:11:44]: debug: ppp0: ipcp_layer_started
[2012-04-30 07:11:44]: debug: ppp0: radius(1): req_enter 1
[2012-04-30 07:11:44]:  info: ppp0: send [RADIUS(1) Accounting-Request id=1 <User-Name "user"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 127.0.0.1> <NAS-Port 0> <NAS-Port-Id "ppp0"> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "e4:8d:8c:13:a4:5d"> <Called-Station-Id "00:21:91:8b:41:fe"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "ebec891e85f517b1"> <Acct-Session-Time 0> <Acct-Input-Octets 0> <Acct-Output-Octets 0> <Acct-Input-Packets 0> <Acct-Output-Packets 0> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 10.10.10.100>]
[2012-04-30 07:11:44]: debug: ppp0: radius(1): req_exit 0
[2012-04-30 07:11:44]:  info: ppp0: recv [RADIUS(1) Accounting-Response id=1]
[2012-04-30 07:11:44]:  info: ppp0: shaper: installed shaper 10240/2048 (Kbit)
[2012-04-30 07:11:44]: debug: ppp0: pppoe: ppp started
[2012-04-30 07:11:45]: error: ppp0: ppp_chan_read: Value too large for defined data type
[2012-04-30 07:11:46]: error: ppp0: ppp_chan_read: Value too large for defined data type
[2012-04-30 07:11:47]: debug: ppp0: recv [LCP EchoReq id=3 <magic 7641ac61>]
[2012-04-30 07:11:47]: debug: ppp0: send [LCP EchoRep id=3 <magic 6b8b4567>]
accel-ppp settings I use:

Code: Select all

[ppp]
verbose=1
min-mtu=1280
max-mtu=1500
#accomp=deny
#pcomp=deny
#check-ip=0
ccp=0
mppe=deny
ipv4=require
ipv6=deny
ipv6-intf-id=0:0:0:1
ipv6-peer-intf-id=0:0:0:2
ipv6-accept-peer-intf-id=1
lcp-echo-interval=12
#lcp-echo-failure=3
lcp-echo-timeout=60
unit-cache=1

[pppoe]
verbose=1
#ac-name=xxx
#service-name=yyy
#pado-delay=0
#pado-delay=0,100:100,200:200,-1:500
called-sid=mac
#tr101=1
#padi-limit=0
#ip-pool=pppoe
#sid-uppercase=0
#vlan-mon=eth0,10-200
#vlan-timeout=60
#vlan-name=%I.%N
#interface=eth1,padi-limit=1000
interface=eth0

I will see if I can get hold of some OpenWRT PPPoE client to test it against accel-ppp as well.

Thank you.

Re: PPPoE RFC4638

Posted: 10 Apr 2016, 07:56
by Dmitry
try this commit fc098b3062badfd802f91241533069cad4886b6f

Re: PPPoE RFC4638

Posted: 10 Apr 2016, 17:55
by zash
Hello,

So I took some time, reread th RFC several times, took some more tcpdumps against Mikrotik and tried to follow accel-ppp code. I finally know the problem, and I propose these changes:

1. Revert commit fc098b3062badfd802f91241533069cad4886b6f
- justification: This applies to RFC4638 section 5.1.1.b which seems optional. MRU negotation can stay and it makes the code simpler for now. This is also not the reason why Mikrotik fails to negotiate. I will cover the reason in point 3) below.

2. Patch pppoe.c

Code: Select all

343c343
<       conn->ctrl.max_mtu = min(ETH_DATA_LEN, serv->mtu) - 8;
---
>       conn->ctrl.max_mtu = MAX_PPPOE_MTU;
810c810
< static void pppoe_send_PADS(struct pppoe_conn_t *conn)
---
> static void pppoe_send_PADS(struct pppoe_conn_t *conn, uint16_t ppp_max_payload)
827c827
<               uint16_t ppp_max_payload = htons(conn->ctrl.max_mtu);
---
>               uint16_t ppp_max_payload = htons(ppp_max_payload);
1007,1009d1006
<       if (ppp_max_payload > serv->mtu - 8)
<               ppp_max_payload = serv->mtu - 8;
<
1168c1165
<               pppoe_send_PADS(conn);
---
>               pppoe_send_PADS(conn, ppp_max_payload);
1179c1176
<               pppoe_send_PADS(conn);
---
>               pppoe_send_PADS(conn, ppp_max_payload);
Some changes include:
- send_PADO: just echo ppp_max_payload of client's PADI like RFC says
- send_PADS: just echo ppp_max_payload of client's PADR like RFC says (This also fixes a bug where htons(conn->ctrl.max_mtu) was used without a cast, that caused a signed -> unsigned conversion and as a result PPP-Max-Payload had invalid value in PADS packet). Potentially it would be good to store such values as unsigned in ap_session.h etc. so that it would not happen by accident.
- allocate_channel: Set the max_mtu to 1492 by default like RFC says

3. Finally the reason why Mikrotik fails to negotiate (or the correct word would be falls back to MTU lower than 1500) is section 5.2 of RFC4638.

Mikrotik pppoe-client and server does this:

Code: Select all

if session is opened with MRU > 1492:
  send up to 2 LCP echo with negotiated MRU size data length
  if no lcp reply received:
      set ppp interface MTU to default MTU
In the tcpdump of Mikrotik Client -> Mikrotik server these echo packets can be seen: https://drive.google.com/file/d/0Byh7EQ ... sp=sharing.

I tried to add it myself but it's too complex for me without being familiar much with the code.

According to rfc this testing (sending the echos) can be disabled, but should be enabled by default. (mikrotik fails to provide such option to disable it)

So for accel a new option coulld be added, 'test-mru' and it could be used like so:

Code: Select all

if conf_mru_test and  session is opened with MRU > 1492:
  send up to 2 LCP echo with negotiated MRU size data length
  if no lcp reply received:
      set ppp interface MTU to default MT


Thank you.

Re: PPPoE RFC4638

Posted: 12 Apr 2016, 21:52
by marekm
Congratulations, very good news to see progress on this! Both Mikrotik PPPoE server and accel-ppp have almost all features I need, with these exceptions: Mikrotik missing Delegated-IPv6-Prefix RADIUS attribute, accel-ppp missing RFC4638 support (OK, may still have issues but it's a start). So I was waiting (running Mikrotik for now) for about a year to see who gets there first, and now accel-ppp seems to be the winner :)
Thanks, and keep up the good work.

Re: PPPoE RFC4638

Posted: 13 Apr 2016, 08:11
by Dmitry
i'm trying to test this with mikrotik in qemu, but it doesn't send PPP-Max-Payload tag
do you know how to enable it ?

Re: PPPoE RFC4638

Posted: 13 Apr 2016, 10:27
by Dmitry
try this commit 2670a3b62dd7324c118a31ed9d8a952ef0c45ed8