DSLite Issues after upgrade to 4.0.1

Benjamin · November 15, 2019, 7:58am

Hello,

after upgrading to 4.0.1 IPv4 connectivity via DS-Lite isn‘t working anymore.

My config:

config interface ‘loopback’
option ifname ‘lo’
option proto ‘static’
option ipaddr ‘127.0.0.1’
option netmask ‘255.0.0.0’

config globals ‘globals’

config interface ‘lan’
option type ‘bridge’
option proto ‘static’
option ipaddr ‘192.168.1.1’
option netmask ‘255.255.255.0’
option ip6assign ‘60’
option bridge_empty ‘1’
list ifname ‘lan0’
list ifname ‘lan1’
list ifname ‘lan2’
list ifname ‘lan3’
list ifname ‘lan4’

config interface ‘wan’
option proto ‘pppoe’
option username ‘user’
option password ‘pw’
option keepalive ‘0’
option ipv6 ‘auto’
option ifname 'eth2.40

config interface ‘VLAN’
option ifname ‘eth2.40’
option proto ‘dhcpv6’
option reqprefix ‘auto’
option reqaddress ‘force’

config interface ‘DSLite’
option proto ‘dslite’
option peeraddr ‘2001:a60:0:3::ffff’
option force_link ‘1’

I’m getting the IPv4 address via the AFTR-Server but something is still wrong.

ds-DSLite Link encap:UNSPEC HWaddr 20-01-0A-61-0B-3C-C8-00-00-00-00-00-00-00-00-00
inet addr:192.0.0.2 P-t-P:192.0.0.1 Mask:255.255.255.255
inet6 addr: fe80::100f:9bff:fe86:3102/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:5547 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:363422 (354.9 KiB)

Has somebody any idea?

Thanks,
Ben

anon50890781 · November 15, 2019, 10:58am

Works for me, but that is without upstream VLAN tagging

config interface 'wan'
	option ifname 'eth2'
	option proto 'pppoe'
	option username 'user name'
	option password 'password'
	option peerdns '0'
	option ipv6 'auto'
	option keepalive '6 10'

In your case you probably want to change the ifname to eth2.40 and remove the config interface ‘VLAN’ section and also the config interface ‘DSLite’ section. Restart the network (I usually reboot the node).

Benjamin · November 15, 2019, 11:47am

Hi,

I don‘t understand how the removal of the DS-Lite config should fix the DS-Lite issue. The PPPoE connection via eth2.40 is working well together with IPv6.

Regards,
Benjamin

anon50890781 · November 15, 2019, 12:43pm

If you use the above the

section becomes redundant since netifd will automatically create the interface.

Benjamin · November 15, 2019, 1:05pm

I have removed VLAN and DSLite but nothing changed. I still have only the PPPoE on eth2.40 with IPv6 Address. No IPv4. I think without configuring Ds-Lite with the AFTR-Server the IPv4 will not work?

config interface ‘loopback’
option ifname ‘lo’
option proto ‘static’
option ipaddr ‘127.0.0.1’
option netmask ‘255.0.0.0’

config globals ‘globals’

config interface ‘lan’
option type ‘bridge’
option proto ‘static’
option ipaddr ‘192.168.1.1’
option netmask ‘255.255.255.0’
option ip6assign ‘60’
option bridge_empty ‘1’
list ifname ‘lan0’
list ifname ‘lan1’
list ifname ‘lan2’
list ifname ‘lan3’
list ifname ‘lan4’

config interface ‘wan’
option proto ‘pppoe’
option username ‘User’
option password ‘Pw’
option ipv6 ‘auto’
option ifname ‘eth2.40’
option keepalive ‘6 10’

Regards,
Ben

anon50890781 · November 15, 2019, 1:43pm

What is the output running from cli check_connection?

For comparison on my node it reads:

IPv4 Gateway: UNKNOWN
Pinging 217.31.205.50 … OK
Pinging 198.41.0.4 … OK
Pinging 199.7.83.42 … OK
Pinging 8.8.8.8 … OK
IPv4: OK
Pinging fe80::e2ac:f1ff:fe65:51ba%pppoe-wan … OK
IPv6 Gateway: OK
Pinging 2001:1488:0:3::2 … OK
Pinging 2001:500:3::42 … OK
Pinging 2001:500:2d::d … OK
Pinging 2606:2800:220:6d:26bf:1447:1097:aa7 … OK
IPv6: OK
Resolving api.turris.cz … OK
Resolving www.nic.cz … OK
Resolving c.root-servers.net … OK
DNS: OK
Resolving www.rhybar.cz … OK
DNSSEC: OK

Benjamin · November 15, 2019, 1:58pm

IPv4 Gateway: UNKNOWN
Pinging 217.31.205.50 … FAILED
Pinging 198.41.0.4 … FAILED
Pinging 199.7.83.42 … FAILED
Pinging 8.8.8.8 … FAILED
IPv4: FAILED
Pinging fe80::46ec:ceff:fef1:7043%pppoe-wan … OK
IPv6 Gateway: OK
Pinging 2001:1488:0:3::2 … OK
Pinging 2001:500:3::42 … OK
Pinging 2001:500:2d::d … OK
Pinging 2606:2800:220:6d:26bf:1447:1097:aa7 … OK
IPv6: OK
Resolving api.turris.cz … OK
Resolving www.nic.cz … OK
Resolving c.root-servers.net … OK
DNS: OK
Resolving www.rhybar.cz … OK
DNSSEC: OK

anon50890781 · November 15, 2019, 2:09pm

right, so no ipv4 at all indeed, strange - it should work either way - with the automatic setting or the additional iface entry. Assuming the network is restarted (or the node rebooted) after changes committed to the network settings.

What is the output from cli of ip -d -h -s a s dev pppoe-wan?

And could check the log about netifdentries of this sort - potential errors?

netifd: Network device ‘pppoe-wan’ link is up
netifd: Interface ‘wan’ is now up
netifd: Network alias ‘pppoe-wan’ link is up
netifd: Interface ‘wan_6’ is enabled
netifd: Interface ‘wan_6’ has link connectivity
netifd: Interface ‘wan_6’ is setting up now

Benjamin · November 15, 2019, 2:30pm

This is the output from ip

20: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
link/ppp promiscuity 0
ppp numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
inet6 fe80::434:6b3b:c82:5445/10 scope link
valid_lft forever preferred_lft forever
RX: bytes packets errors dropped overrun mcast
4.83M 6.55k 0 0 0 0
TX: bytes packets errors dropped carrier collsns
1.64M 5.84k 0 0 0 0

I will not get any IPv4 adress via pppoe-wan since I do not have dual stack. Only dslite.

Benjamin · November 15, 2019, 2:37pm

Nov 15 14:35:04 turris pppd[6742]: Plugin rp-pppoe.so loaded.
Nov 15 14:35:04 turris pppd[6742]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Nov 15 14:35:04 turris pppd[6742]: pppd 2.4.7 started by root, uid 0
Nov 15 14:35:05 turris kresd[3162]: [priming] cannot resolve ‘.’ NS, next priming query in 10 seconds
Nov 15 14:35:05 turris kernel: [ 62.884839] mvneta f1034000.ethernet eth2: Link is Down
Nov 15 14:35:06 turris netifd: Network device ‘eth2’ link is down
Nov 15 14:35:06 turris netifd: VLAN ‘eth2.40’ link is down
Nov 15 14:35:06 turris netifd: Interface ‘wan’ has link connectivity loss
Nov 15 14:35:08 turris netifd: Network device ‘eth2’ link is up
Nov 15 14:35:08 turris kernel: [ 64.951736] mvneta f1034000.ethernet eth2: Link is Up - 100Mbps/Full - flow control off
Nov 15 14:35:08 turris netifd: VLAN ‘eth2.40’ link is up
Nov 15 14:35:08 turris netifd: Interface ‘wan’ has link connectivity
Nov 15 14:35:08 turris netifd: Interface ‘wan’ is setting up now

anon50890781 · November 15, 2019, 3:33pm

This is a bit strange since being a local prefix. Does the ISP provide dynamic or static public/private IPs (v4 / v6)?

I got ds-lite too

Benjamin · November 15, 2019, 4:23pm

ISP is providing dynamic IPv6 and IPv4 via DS-Lite.

What I don‘t understand -> How can it possible that your IPv4/DS-Lite is working without specifiyng the AFTR Server from the ISP which is used for tunneling IPv4?

Thanks,
Ben

anon50890781 · November 15, 2019, 5:22pm

Afaik this is being achieved via RFC6334 ^{[1] [2]}

^[1] https://www.isc.org/blogs/ds-lite-architecture-overview-and-automatic-configuration/
^[2] RFC 6334 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite

Suppose that requires the ISP having it implemented (and correctly) in the first place. However, reading

To inform the B4 of the Address Family Transition Router’s (AFTR) location, a DNS [RFC1035] hostname may be used. Once this information is conveyed, the presence of the configuration indicating the AFTR’s location also informs a host to initiate Dual-Stack Lite (DS-Lite) service and become a softwire initiator.

wondering whether this being a DNS issue at your node somehow.

From the topic

Issues after upgrade to 4.0.1

I would infer that ds-lite worked as expected in the TOS3.x branch with the config stated in the initial post?

I had tried a similar config earlier but that caused some grievance in TOS3.x

https://gitlab.labs.nic.cz/turris/openwrt/issues/252

Benjamin · November 15, 2019, 6:23pm

Yes, under TOS 3.X my first config was working. Can I check somehow if my ISP is providing the AFTR_NAME via DHCPv6? If not, I guess there must be a way to configure it manually like I did it on TOS 3.X?

I just found one hint in the openWRT documentation.
https://openwrt.org/docs/guide-user/network/ipv6/start

Note: To automatically configure ds-lite from dhcpv6 you need to create an interface with option auto 0 and put its name as the ‘iface_dslite’ parameter. In addition you also need to add its name to a suitable firewall zone in /etc/config/firewall

Do you have any additonal interfaces than wan configured?

anon50890781 · November 15, 2019, 8:32pm

Nothing WAN related, just the one WAN iface. netifd spawns WAN_6 (Virtual dynamic interface (DHCPv6 client)) and WAN_6_4 (Virtual dynamic interface (Dual-Stack Lite (RFC6333))) automatically on this node.

That is another way to go about it. In any case the firewall of course needs to be configured correctly to allow the necessary exchange of information with the ISP. Which might be the issue in your case.

Probably only by contacting the ISP support. I would know of a way to check it over the wire from the router.

Benjamin · November 16, 2019, 7:17am

I switched now back to 3.X since I was also not able configure it manually on 4.X.
If anyone has a running DS-Lite configuration with a manual setup of the interfaces it would be nice if could be posted here.

Thanks,
Ben

anon50890781 · November 16, 2019, 11:25am

Since your ISP apprently furnished you with an IPv6 address (2001:a60:0:3::ffff) for their AFTR infrastructure, instead of a hostname on a FQDN, I would suspect that the ISP has not implemented RFC6334. My ISP furnished a hostname on a FQDN.

Perhaps you could try (play around) with this conf

config interface 'wan'
  option ifname 'eth2.40'
  option proto 'pppoe'
  option username 'user name'
  option password 'password'
  option ipv6 'auto'

config interface ‘DSLite’
  option proto ‘dslite’
  option peeraddr ‘2001:a60:0:3::ffff’
  option auto '0'
  option iface_dslite '1'
  option zone_dslite 'wan'

Just a few things to make sure nothing else is amiss:

check that the ds-lite package is installed indeed
turn off any IPv4 NAT feature(s) in the firewall (e.g. option masq)
make sure that the firewall rules in place to permit information exchange with ISP

Firewall rules on this node (zone is named `wan`)

config defaults
	option input 'DROP'
	option output 'ACCEPT'
	option forward 'DROP'
	option syn_flood '1'
	option synflood_protect '1'
	option drop_invalid '1'
	option synflood_rate '150/s'
	option synflood_burst '50'
	option tcp_ecn '1'
	option tcp_syncookies '1'
	option tcp_window_scaling '1'

config zone
	option name 'wan'
	option input 'DROP'
	option output 'ACCEPT'
	option forward 'DROP'
	option network 'wan'
	option log '1'
	option log_limit '5/second'
	option mtu_fix '1'
	option conntrack '1'

config rule
	option name 'wan dhcp ipv4'
	option family 'ipv4'
	option proto 'udp'
	option src 'wan'
	option dest_port '68'
	option target 'ACCEPT'

config rule
	option name 'wan ping ipv4'
	option family 'ipv4'
	option proto 'icmp'
	option src 'wan'
	option icmp_type 'echo-request'
	option limit '1/sec'
	option target 'ACCEPT'

config rule
	option name 'wan dhcp ipv6'
	option family 'ipv6'
	option proto 'udp'
	option src 'wan'
	option src_ip 'fc00::/6'
	option src_port '547'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option target 'ACCEPT'

config rule
	option name 'wan icmp ipv6'
	option family 'ipv6'
	option proto 'icmp'
	option src 'wan'
	list icmp_type 'echo-request'
	list icmp_type 'router-advertisement'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-advertisement'
	list icmp_type 'neighbour-solicitation'
	option limit '50/sec'
	option limit_burst '10'
	option target 'ACCEPT'

Benjamin · November 21, 2019, 9:08am

I have tried this configuration but it didn’t change anything. IPv6 working, IPv4 not.

ds-lite 7.0.4 is installed
all IPv4 NAT Features are disabled
I have opened the firewall outbound/inbound to avoid any firewall issues

anon50890781 · November 22, 2019, 9:53am

Without any pointer from the node’s log it is sort of difficult to get to the bottom of it…

What happens when you disable ds-lite -> option ipv6 '0'?

Else (with *ds-lite) active, it might require some effort to debug the issue:

make sure the ISP’s AFTR node (2001:a60:0:3::ffff) is reachable/accessible
run a tcp/udp dump on the router, download the dump to a node with an app (e.g. wireshark) suitable for packet inspection (latest wireshark version comes also with remote ssh dump option)
use Foris Diagnostics and see whether the dumped information contains anything useful pertinent to the issue