The Raspbian Jessie Wait for Network setting does not reliably detect network availability which complicates mounting remote drives during boot etc. Current remedies either add similarly unreliable/wasteful delays to the boot process, or do nothing useful. By using Jessie's systemd init system, this solution extends Wait for Network (i.e. it is still controlled by Wait for Network) to implement simple and reliable network availability detection.

Although this approach works well as it is, ideally it should be included in the standard distribution with raspi-config modified to control it directly through ‘systemctl en/disable’ instead of writing and deleting the current Wait for Network wait.conf.

Problem

When configured to Wait for Network, the Jessie systemd init process detects dhcpcd obtaining interface configurations before proceeding to network.target and network-online.target. At that exact point, however, interface address/es are not yet configured, and name resolution comes later still.

When not configured to Wait for Network (or when dhcpcd reaches its timeout while waiting), dhcpcd forks to a background daemon and the init process proceeds immediately. This means network.target and network-online.target are reached even without the availability of interface configurations.

Compounding the problem is the fact that - as standard - network.target and network-online.target call for no further checking. network-online.target is therefore often reached before interface configurations have been applied, and in cases even before they have been obtained.

1. Create a network auto-mount
On a standard system (i.e. without network-wait-online.service installed), add a line similar to the following to /etc/fstab. Dummy names can be used through-out with the exception of the host which must be a reachable hostname:

This means that for the mount to be attempted, both the network-online and network targets must have been reached (i.e. dhcpcd must have initialised successfully). The two targets have no predecessors that can indicate network availability other than dhcpcd. Therefore network availability detection solely relies upon dhcpcd in the standard installation.

2. Induce a delay to prevent DHCP & interface initialisation normally from completing before mount
a. Configure the Pi for Wi-Fi networking
b. Ensure its dhcpcd is configured to obtain its configuration from the DHCP server (the default)
c. Configure the Wi-Fi access point to hide its SSID (“hidden network”)
d. In /etc/wpa_supplicant/wpa_supplicant.conf, disable scanning (disable or remove ‘ap_scan’ and ‘scan_ssid’ entries)

3. Standard installation with Wait for Network disabled
Ensure Wait for Network is disabled and reboot

The modified network-wait-online service will start tracing IP address availability as soon as dhcpcd initialises (=network.target), and will satisfy network-online.target by completing successfully once an IP address has been configured.

This time the mount is only attempted after an IP address is obtained, but name resolution still fails:

As expected by now, Wait for Network makes no difference other than delaying dhcpcd forking to the background. The mount is only attempted after an IP address is obtained, but name resolution still fails:

The modified network-wait-online service will start tracing IP address and DNS resolver availability as soon as dhcpcd initialises (=network.target), and will satisfy network-online.target by completing successfully once an IP address has been configured and DNS resolution operates.

This log shows that by the time the interface IP address has been configured, availability of DNS resolution and general network access cannot be assumed (network-wait-online: addresses=192.168.1.204 , hostnames=). However, because network-wait-online now assures DNS resolver availability by the time it completes, network availability is also assured (because the resolver was reached and responded). Name resolution of the remote server for the mount command therefore succeeds (although the mount still fails due to the dummy share name):

Thanks for this code. While it works properly in Raspbian Jessie 20170705 image with desktop environment. However, when i try it on Raspbian Jessie Lite 20170705 image, script always enter failed state. Refer to below for systemctl status message:

If empty 'hostname' output were the only issue, the ExecStart script should still start up successfully and remain in the 'while [ -z $(hostname --all-fqdns) ]' loop (while the output remains empty). The start operation timing out indicates something going wrong before that point.

I'm not in a position to investigate Jessie Lite issues, but you seem headed in the right direction.

Look in the 'journalctl' output around the script's "Wait for Network: enabled" or "Wait for Network: disabled" message for any further useful information.

Run the ExecStart script manually and compare results.

Lengthen the start timeout to say 10 minutes, compare what happens and work backwards from there.

Compare everything else: does Jessie Lite have dhcpcd, is it enabled, does it behave the same, does the Jessie Lite systemd process support the required targets and keywords, does raspi-config create the 'wait.conf' file, etc.

-A, --all-fqdns
Displays all FQDNs of the machine. This option enumerates all configured network addresses on all configured
network interfaces, and translates them to DNS domain names. Addresses that cannot be translated (i.e. because
they do not have an appropriate reverse IP entry) are skipped. Note that different addresses may resolve to the
same name, therefore the output may contain duplicate entries. Do not make any assumptions about the order
of the output.

1. It was declaring success when I had an IP and a fully qualified host name. For some reason my wifi link is coming up with a 169 address, then going down again, then coming up properly with a 192 address. I extended to include a ping test for a known server (my DNS server), which makes it more reliable