Pppd killed on signal 15 after reconnect, repeatedly

Thanks a lot.
The package ds-lite is installed:

root@turris:~# opkg list ds-lite
ds-lite - 7-4.0 - Provides support for Dual-Stack Lite in /etc/config/network.
 Refer to http://wiki.openwrt.org/doc/uci/network for
 configuration details.

Today in the evening I will remove it.

`opkg remove ds-lite` will be the correct cmd?

If remove the package whats happened with the Dual-Stack functionality?
How I can cover this w/o the package?

Ive read more than one times in the net about the DS-Lite failure. Its a general thing an not specific to TO router/OpenWRT?

How can I manage the " `"? Related to my german keyboard?

That’s only a temporary solution. See Turris Documentation for the official way how to remove packages from Turris OS. After you create the file with the uninstall command, just run pkgupdate.

I’ m confused now.
The cmd opkg remove ds-lite is only an temporary solution and comes back with the update process, correct?
What is the target?
To delete (different to remove) complete, or to replace through a newer or repaired version?
Sorry for my incompetence.

yes, whenever pkgupdate is invoked, either from the ssh sli or the update supervisor from re/Foris.


The purpose is explained through the linked document

If the updater concludes that the package is needed for another reason, it brings it back.

These reasons can be any of the following:

  • The package is part of the basis of TurrisOS. In this case the updater will require it, as Turris OS cannot exist in an infinite number of alterations and something has to be considered the basis.

You would have to dig through the TOS repository to discover that ds-lite is part of https://repo.turris.cz/hbt/omnia/lists/base.lua


It will work, removing the package just removes the lite component (IPv4 in IPv6 tunnel) and instead utilises the full dual-stack.

OK, now it`s clear.
I remove the package ds-lite and to ensure it will not come back I must do the following entry in

/etc/updater/conf.d:

`Uninstall("ds-lite", { priority = 60 })`

But there can be a risk when I do this:

`Be warned, this can lead to the removing of other packages, for example if they depend on that package.` 

For a first test can be enough for my opinion.
It works stable w/o any conflict than I can add the rule in the config file.

This is the only chance what I have, or?
The other way can be to remove only by opkg remove ds-lite and if I have any changes on the system by the updater … than I must repeat it again. It is also a way how I can proceed?
This way has only the risk that the conflict with the IPv6 will come back and this is for the moment only related for tunneling when I need the IPv6 addressees, or I am on the wrong way?
The conflict there I have in the moment is not really a big problem. It is more a shitty situation and not 100% correct.
Nothing what I need to life!

In addition: How can I manage the " `"? Related to my German keyboard?

I have remove the package by opkg remove ds-lite and I have check it is removed.
The result after the restart of the router is the same like before I have remove the package.

grafik

For my opinion it was not successful!
What does it means “IPv6-connectivity” not available/successful (red !)?
The IPv6 connectivity to the Gateway" is available/successful means what?

In addition there was a warning during/after the removal of the ds-lite package regarding it can be needed for other packages but this was written under the FAQs.

For me is this temporary solution not the successful way, or is there something wrong what I have done now?

… and in addition why I have in the morning e.g. both for IPv6 available?

run from ssh cli check_connection, it will provide a more verbose output.

Also

  • ip a sh dev pppoe-wan
  • wget -6 -O /dev/null http://speedtest.wtnet.de/files/100mb.bin
oot@turris:~# check_connection
Pinging 84.46.104.216 ... OK
IPv4 Gateway: OK
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
IPv6 Gateway: UNKNOWN
Pinging 2001:1488:0:3::2 ... FAILED
Pinging 2001:500:3::42 ... FAILED
Pinging 2001:500:2d::d ... FAILED
Pinging 2606:2800:220:6d:26bf:1447:1097:aa7 ... FAILED
IPv6: FAILED
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

oot@turris:~# ip a sh dev pppoe-wan

18: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
link/ppp
inet 46.59.203.85 peer 84.46.104.216/32 scope global pppoe-wan
valid_lft forever preferred_lft forever
inet6 2a02:2028:6ff::b02e/128 scope global dynamic noprefixroute
valid_lft 170106sec preferred_lft 83706sec
inet6 2a02:2028:6ff::6a58/128 scope global dynamic noprefixroute
valid_lft 170106sec preferred_lft 83706sec
inet6 fe80::9432:ab68:30ea:8597/10 scope link
valid_lft forever preferred_lft forever

root@turris:~# wget -6 -O /dev/null http://speedtest.wtnet.de/files/100mb.bin

Downloading ‘http://speedtest.wtnet.de/files/100mb.bin
Failed to establish connection

The WAN interface got an IPv6 from the ISP but seems that IPv6 traffic does not get routed.

What is the output of ip -6 r | grep default ?


In LuCI the WAN interface settings (advanced tab) should look like

All three options are acticated like you.

The output of cmd is nothing!

    root@turris:~# ip -6 r | grep default
root@turris:~#

The only different is the option for the force_link. This is what I need otherwise I lost the connection after the force separation from the ISP (reason for this thread).

The issue is the missing routing, however that is happening.

What is the output of ifstatus wan_6 ?

root@turris:~# ifstatus wan_6
{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": true,
	"uptime": 10422,
	"l3_device": "pppoe-wan",
	"proto": "dhcpv6",
	"device": "pppoe-wan",
	"updated": [
		"addresses",
		"routes",
		"prefixes",
		"data"
	],
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		{
			"address": "2a02:2028:6ff::6a58",
			"mask": 128,
			"preferred": 75976,
			"valid": 162376
		},
		{
			"address": "2a02:2028:6ff::b02e",
			"mask": 128,
			"preferred": 75976,
			"valid": 162376
		}
	],
	"ipv6-prefix": [
		{
			"address": "2a02:2028:624:4800::",
			"mask": 56,
			"preferred": 75976,
			"valid": 75976,
			"class": "wan_6",
			"assigned": {
				"lan": {
					"address": "2a02:2028:624:4800::",
					"mask": 60
				}
			}
		}
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		
	],
	"dns-server": [
		"2a02:2028:fd00::cafe",
		"2a02:2028:fd00::affe"
	],
	"dns-search": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		]
	},
	"data": {
		"passthru": "001700202a022028fd000000000000000000cafe2a022028fd000000000000000000affe",
		"zone": "wan"
	}
}

grafik

WAN6 is not really configured.
It`is a must to do and if yes why?
Only the WAN interface is configured.

delete WAN6 (that is probably some redundant leftover from setting up through Foris), if necessary thereafter from the cli ssh service network restart. Hopefully that gets it sorted.

WAN_6 is the interface is that matters and that gets automatically spawned by the network manager.

1 Like

I have delete WAN6 and now I can`t modify WAN_6. It is correct?

… but for the moment I get full availability for IPv6.

`root@turris:~# ip -6 r | grep default
default from 2a02:2028:505:5f00::/56 via fe80::aa9d:21ff:fee1:7f00 dev pppoe-wan proto static metric 512 pref medium
default from 2a02:2028:5ff::3576 via fe80::aa9d:21ff:fee1:7f00 dev pppoe-wan proto static metric 512 pref medium
root@turris:~#`

Maybe this was the fault it makes sense to install the package ds-lite again?

For the moment I don`t trust the situation :slight_smile: but I hope this is the end of the hunting.

Yes


No. The issue is that when you setup the router initially through Foris it created WAN6, which it should not really.


what is the output of

now?

root@turris:~# check_connection
Pinging 84.46.104.215 ... OK
IPv4 Gateway: OK
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::aa9d:21ff:fee1:7f00%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

Looks OK, or?

Regarding the ds-lite package makes no sense?

Yep, done and dusted.


It would only make sense for ds-lite upstream connectivity but your ISP provides ds-full upstream connectivity and as you can see it works now.

Maybe you are thinking I am crazy. No IPv6 availability w/o any changes.

Can not be!

I reboot the router and all IPv6 connections available.
I am sure the router will lost the connection again and I have no clue.

Maybe pkgupdate ran in the meantime (cron job from Foris automatic update enabled) and reinstalled ds-lite? If not reboot the router and see what happens, check the syslog for clues.


OpenWrt pulled the patch from the source development git.openwrt.org Git - openwrt/openwrt.git/commitdiff into their Master branch and which should be available in TOS HBD, least for Mox and Turris 1.x, if someone wants to venture there and test it (without force_link).

I have done a reboot again and I check is ds-lite installed again and no!
Now it is running for the moment.

It is up and down.
Complete unstable!
In one moment it works in the next moment dosen’ t work.

I will check tomorrow morning again whats happened.
For the moment I think we can`t do anything.
THX