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

Reply via email to