Disabled IPv6 and services doesn't start

Sure, that is what @miska stated earlier, but that requires the boot arg to be removed first or else the setup from medkit reset is no dice.

And it is not really answering the question about the decision logic to cease.

You can modify the medkit as it is ordinary tarball.

1 Like

The funny thing is looking into the conf of lighttpd

Use IPv6 if available

#include_shell “/usr/share/lighttpd/use-ipv6.pl”

Being a conditional directive the logic is apparently to continue with ipv4 and yet when the ipv6 sock is not available is does not work. Just a point in case about the twisted logic.

@miska @vcunat

Just discovered that dnsmasq seemed to have a similar issue in the past and which backs what I said earlier - application logic. See release history 1.3

I’m late here, but it should be noted that ipv6.disable will break various stuff, partially because IPv4+IPv6 binding logic in kernel.

As an example that it is not TO-specific problem see e.g.

It explicitly mentions that ipv6.disable breaks Samba and recommends to use sysctl net.ipv6.conf.all.disable_ipv6 = 1 instead.

I am not concerned about Samba since not utilizing it. The kernel has no issue with the ipv6 stack disabled and the linux boxes I am running with all kind of apps neither.

They just recommend it because Samba (conveniently) designed its stack logic that way, which most other apps do not, just to name a few are dnsmasq, ngix and and unbound.

Sure. I’m just trying to explain that fixing all apps is long run because it is widespread and would require changes in many apps to make it reliable for everyone instead if just make it work in your particular use-case.

(And of course, is questionable if it is worth the effort at all.)

Not asking to re-design your app (stack logic) as such design is your prerogative certainly. I have been sharing an observation.

I am using unbound anyway once through the TOS vanilla setup.

all the efforts to push ipv6 adoption taken in good faith, i also do not agree that silently requiring a specific (and essentially optional) protocol is the right way to go.

1 Like

Might as well embrace nftables which in comparison to iptables are less CPU expensive, faster, feature atomic reload, don’t need ipset and best of all do not require separate rule sets for ipv4 and ipv6 :wink: :mrs_claus:
Or skip that and jump straight to BPF

Then TOS should be ready for handling of both ip technologies since the world is not yet ready for ipv6 only


1 Like

@miska This whole force-feeding ipv6 does not add up. First netifd not being able to handle ds-lite and now

“DHCPv6 leases not supported now”

Apparently odhcpd settings are entirely neglected such as

option leasefile
option/list dns 
option/ list domain

cross reference Enable DHCP client in DNS - IPv6 addresses not included? - SW help - Turris forum

FW3 not supporting ipv6 port forwarding port forward does not support ipv6 · Issue #925 · openwrt/luci · GitHub

On top of this the maintenance with pkgupdate requires the DNS server listening on the ipv4 loopback stack. With just ipv6 the updater fails to resolve the repo address.