Note that I am not the maintainer but simply another user. Gerald Turner wrote: > I have a Linux router running jessie that has four ethernet ports and a > pair of ath9k radios. > > Three of the ethernet interfaces (eth0, eth1, eth2) are statically > configured LAN ports. The fourth ethernet interface (eth3) is connected > to an ISP via cable modem and uses DHCP¹. The two wlan interfaces are > also configured statically and have hostapd running.
It sounds like you and I have very similar environments. Therefore I decided I would share what I am doing here. Since I am doing things completely differently and it is working great for me. YMMV. > See attached /etc/network/interfaces and syslog files. One (trivial) comment is that you can simplify your config file by using the more compact CIDR /23 netmask syntax rather than the full line stating netmask 255.255.254.0 as needed many moons ago. auto eth0 iface eth0 inet static address 192.168.242.1/23 Secondly I don't see where you are starting hostapd. Therefore I assume you are starting it through systemd. In my case I am not using systemd but am starting hostapd in an 'up' section of the interfaces file. Here is a representative interfaces section. allow-hotplug wlan0 iface wlan0 inet static address 192.168.93.1/24 hostapd /etc/hostapd/hostapd-wlan0.conf up service isc-dhcp-server restart This way everything flows correctly in the correct order. The interface is detected and the allow-hotplug invokes the event driven flow. (As opposed to the init drive flow of auto.) The hostapd is started via the hostapd configuration line. I have multiple radio interfaces and therefore multiple configuration files. (I could probably use /etc/hostapd/hostapd-$IFACE.conf using $IFACE but I rather like the plain version.) This is the ifupdown method described in the /usr/share/doc/hostapd/README.Debian file. The interface being UP the dhcp server is restarted so that it binds to the now available interface. I am not sure that is needed these days, likely isn't, but at one time it was needed and not yet having had any reason to change the configuration I haven't tested not having it there. You might consider something like this type of control flow. Reading through your trials and tribulations of chasing through the systemd dependencies makes me happy that I did not pursue that path. Bob