Hi,
I have been trying to get IPv6 to work with PPPoE. While experimenting I set the following directive:
set interfaces ethernet eth1 pppoe 0 ipv6 address autoconf
While committing the configuration I got the following error:
cat: /proc/sys/net/ipv6/conf/pppoe0/forwarding: No such file or directory sh: line 7: [: =: unary operator expected
I think the problem is the interface name mapping - the Linux interface name is actually ppp0.
cpo@BR1# set interfaces ethernet eth1 pppoe 0 ipv6 address autoconf
[edit]
cpo@BR1# commit
[ interfaces ethernet eth1 pppoe 0 ipv6 address autoconf ]
cp: cannot create regular file ‘/etc/ppp/ipv6-up.d/50-vyos-pppoe0-autoconf’: No such file or directory
sed: can't read /etc/ppp/ipv6-up.d/50-vyos-pppoe0-autoconf: No such file or dire ctory
chmod: cannot access ‘/etc/ppp/ipv6-up.d/50-vyos-pppoe0-autoconf’: No such file or directory
Warning: IPv6 forwarding is currently enabled.
IPv6 address auto-configuration will not be performed
unless IPv6 forwarding is disabled.cpo@BR1# delete interfaces ethernet eth1 pppoe 0 ipv6 [edit] cpo@BR1# commit [ interfaces ethernet eth1 pppoe 0 ipv6 address autoconf ] rm: cannot remove ‘/etc/ppp/ipv6-up.d/50-vyos-pppoe0-autoconf’: No such file or directory [[interfaces ethernet eth1 pppoe 0]] failed Commit failed
confirmed/different error with EPA3
No errors appear when committing a second time
Interface name is ppp0 but will later be renamed to pppoe0
$ show system kernel-messages | grep pppoe0 [19839.855557] pppoe0: renamed from ppp0
I will have to re-test tonight (when nobody else is using the Internet) and get some log output.
But I think my interface must be stuck in a funny state. This is what I captured last night:
vyos@vyos:~$ show interfaces pppoe pppoe0: Coming up
However it was successfully routing IPv4 and IPv6 packets in that state.
I checked and $ show system kernel-messages | grep pppoe0 did not return any output.
Here is the pppd log:
Sun Feb 10 23:42:33 UTC 2019: PPP interface pppoe0 created Sun Feb 10 23:42:35 UTC 2019: Stopping PPP daemon for pppoe0 Sun Feb 10 23:42:35 UTC 2019: Starting PPP daemon for pppoe0 Send PPPOE Discovery V1T1 PADI session 0x0 length 12 dst ff:ff:ff:ff:ff:ff src 60:38:e0:e3:85:dc [service-name] [host-uniq 46 09 00 00] Recv PPPOE Discovery V1T1 PADO session 0x0 length 41 dst 60:38:e0:e3:85:dc src 00:30:88:1e:3f:81 [host-uniq 46 09 00 00] [AC-name npe001.slo-B2244460703440] [service-name] Send PPPOE Discovery V1T1 PADR session 0x0 length 12 dst 00:30:88:1e:3f:81 src 60:38:e0:e3:85:dc [service-name] [host-uniq 46 09 00 00] Recv PPPOE Discovery V1T1 PADS session 0x86 length 41 dst 60:38:e0:e3:85:dc src 00:30:88:1e:3f:81 [service-name] [host-uniq 46 09 00 00] [AC-name npe001.slo-B2244460703440] PADS: Service-Name: '' PPP session is 134 Connected to 00:30:88:1e:3f:81 via interface eth1 using channel 1 Using interface ppp0 Connect: ppp0 <--> eth1 sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xc9445e0>] rcvd [LCP ConfReq id=0xaf <mru 1492> <auth chap MD5> <magic 0x67b552a8>] sent [LCP ConfAck id=0xaf <mru 1492> <auth chap MD5> <magic 0x67b552a8>] rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xc9445e0>] sent [LCP EchoReq id=0x0 magic=0xc9445e0] rcvd [CHAP Challenge id=0x1 <71eefcfc2d0e14c0a58724b33b39c5e8>, name = "npe001.slo"] sent [CHAP Response id=0x1 <dcd3ef5ce6bf1becd89973f9918e1a17>, name = "[email protected]"] rcvd [LCP EchoRep id=0x0 magic=0x67b552a8] rcvd [CHAP Success id=0x1 "FTTC1234"] CHAP authentication succeeded: FTTC1234 CHAP authentication succeeded peer from calling number 00:30:88:1E:3F:81 authorized sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>] sent [IPV6CP ConfReq id=0x1 <addr fe80::856c:4c81:d343:c311>] rcvd [IPCP ConfReq id=0x0 <addr 81.187.81.187>] sent [IPCP ConfAck id=0x0 <addr 81.187.81.187>] rcvd [IPCP ConfReq id=0x1 <addr 81.187.81.187>] sent [IPCP ConfAck id=0x1 <addr 81.187.81.187>] rcvd [IPCP ConfReq id=0x2 <addr 81.187.81.187>] sent [IPCP ConfAck id=0x2 <addr 81.187.81.187>] sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>] sent [IPV6CP ConfReq id=0x1 <addr fe80::856c:4c81:d343:c311>] rcvd [IPCP ConfNak id=0x1 <addr 1.2.3.4> <ms-dns1 217.169.20.21> <ms-dns2 217.169.20.20>] sent [IPCP ConfReq id=0x2 <addr 1.2.3.4> <ms-dns1 217.169.20.21> <ms-dns2 217.169.20.20>] rcvd [IPV6CP ConfAck id=0x1 <addr fe80::856c:4c81:d343:c311>] rcvd [IPCP ConfAck id=0x2 <addr 1.2.3.4> <ms-dns1 217.169.20.21> <ms-dns2 217.169.20.20>] local IP address 1.2.3.4 remote IP address 81.187.81.187 primary DNS address 217.169.20.21 secondary DNS address 217.169.20.20 Script /etc/ppp/ip-up started (pid 2386) rcvd [IPV6CP ConfReq id=0x0 <addr fe80::0203:97ff:fe42:0000>] sent [IPV6CP ConfAck id=0x0 <addr fe80::0203:97ff:fe42:0000>] local LL address fe80::856c:4c81:d343:c311 remote LL address fe80::0203:97ff:fe42:0000 Script /etc/ppp/ipv6-up started (pid 2387) Script /etc/ppp/ipv6-up finished (pid 2387), status = 0x0 Script /etc/ppp/ip-up finished (pid 2386), status = 0x0
I can't see anything that looks like an error.
I can confirm that as soon as IPv6 is enabled on pppoe0 the interface is no longer renamed from ppp0 to pppoe0.
This is bad if someone enables IPv6 and uses e.g. zone based firewall => he will be locked out.
@hagbard does Accel-PPP also have those interface rename scripts (e.g. ifup/ifdown?)
@c-po, Accel-ppp support next option in [pppoe] section
[pppoe]
ifname=pppoe%d
If this option is given ppp interface will be renamed using ifname as a template, i.e pppoe%d => pppoe0.
@c-po accel-ppp is a server, the pppoe client in vyos is rp-pppoe, which causes the issue.
ppp works and Acks the IPv6 address:
rcvd [IPV6CP ConfReq id=0x0 <addr fe80::0203:97ff:fe42:0000>]
sent [IPV6CP ConfAck id=0x0 <addr fe80::0203:97ff:fe42:0000>]
local LL address fe80::856c:4c81:d343:c311
remote LL address fe80::0203:97ff:fe42:0000
Script /etc/ppp/ipv6-up started (pid 2387)
So I suppose it's an issue with the ppp scripts itself.
Please test with latest rolling image before VyOS 1.2.2 is released
Before as soon as IPv6 was enabled on the dialer interface the interface was no longer renamed from ppp0 to pppoe0 causing a deadlock on remote routers where pppoe0 was used for zone base firewall / NAT, hence the unbreak now priority.
Tested on Telekom FTTH (PPPoE via VLAN7)
Rename script imported from EdgeOS ER-e200.v2.0.1.5174691.tar
Fix applied in this commit:
https://github.com/vyos/vyatta-cfg-op-pppoe/commit/4330d41fcda30553ca1b3e2588d05eebdd59fc80