Many services do not start properly with wi-fi as WAN

I moved and where I am now I have to use wi-fi as my WAN. The basics of this works fine, but I have noticed that a lot of network services start before the network has stabilized itself and then don't function correctly:

  • simple-adblock
  • ddns
  • nbd-server

There may be others I don't know yet. This is on recent snapshot. But I've noticed issues with ddns before on a wi-fi repeater bridge since about version 21, which leads me to believe this is a long-time issue.

What is the current trigger in OpenWrt for these to start?

You can change the sequence number for these services in /etc/rc.d , for example delete the symlink SXXsimple-adblock and make a new one ln -s ../init.d/S99simple-adblock . Also change in the file the START=XX into START=99.

1 Like

Is this the official OpenWrt Answer™? As in, a new user who is using OpenWrt for the first time with a Wi-Fi-as-wan topology, or a Wi-Fi client bridge, is expected to jiggle the service starting order for off-the-shelf packages to work?

This is the official TreNdy® answer. You are in the community forum of an open source project.
If you want to complain on behalf of the new users who cannot combine the wwan with ddns and adblock, you may raise a ticket to the maintainers of these applications which fail work correctly if there is no network.

The short answer is this:

  • services are started based on the sequencing in init.d
  • The service-up sequencing will typically be rougly related to the start sequence, but that will never be absolutely consistent as it depends on how many services are started in a given pat of the sqeuence and how long each takes from start-to-operational.
  • The availability of depenecies cannot always be guaranteed unless explicitly coded (good example: WG VPN start ofen requires NTP success to work, but if set to auto-start on boot, there is a chicken-or-egg situation. Scripts have been created to address this).
  • The failure handling of a service depends on how it is coded (quietly vs lots of log output; fail once and stop trying vs try again later, etc.).
  • Sometimes it is necessary for additional scripts or user intervention to resolve issues where dependencies were not met during initial bring-up.
1 Like

Yes, thank-you for the reminder. :slight_smile: I was curious if there was a generally accepted standard answer for this. I apologize for the tone, I'm not so much complaining (though I think this issue worthy of a ticket and will staff one up) as surprised a project this mature has this issue.

Looking at rc.d, the order is good. Other projects use stages where one triggers the next: kernel, filesystems, network-infrastructure, then dependent services. That's the way rc.d appears to be ordered. It just looks as if it moves on to later stages before earlier stages are complete and/or stable.

I'm thinking some logic in S20network to analyze: 1) Is there an upstream, 2) is it wi-fi, 3) should we wait for a bit for this to come available before we exit and let the next stage start.

Water under the bridge :slight_smile:
It's not about the maturity of the project. I've seen similar problems in other linux distributions, where docker didn't start because the ldap was not up yet and had not fetched the users and groups, so there was no user to run the docker service.
Personally I would expect from a service to restart or keep trying, in case network is not available. And this may happen not only during startup, but during normal operation as well.
It is more efficient than waiting for network to finally exit, without any guarantee than in the next second it may be offline.