delaying dnsmasq startup until guest Wifi initialized

[bengalih]

I setup separate dhcp servers for my guest wifi networks similar to the process described here:

https://github.com/RMerl/asuswrt-me...dicated-DHCP-options-bind-to-a-specific-SSID?

The dnsmasq.postconf in that link doesn't work for me exactly, I needed quite a few differences in my iptables/ebtables rules, but for sake of simplicity this is the idea behind what I'm doing. That article also states that you should create a services-start script to do a service restart_dnsmasq to "to ensure the DHCP service is restarted after the WiFi interface have been mounted."

I have set that up, however it appears that it isn't delaying appropriately, as everytime I reboot my system I am not able to get IP addresses on the guest Wifi until I go and manually issue a service restart_dnsmasq on my server.

Is there a better way to configure this so that I don't need to do this manual step each reboot?

 

[bengalih]

So this might be a bit more complex then just delaying, here is what I have found out so far:
I modified services-start to check for the interface being up and if not, loop for up to 90 seconds before moving on

#!/bin/sh
x=0

int_check="wl0.1"

# Custom - required to ensure the DHCP service is restarted after the WiFi interface has been initialized
while [ $x -lt 90 ]; do
    cat /sys/class/net/$int_check/carrier > /dev/null 2>&1
    if [ $? -ne 0 ]; then
        sleep 10  # network not yet up
        x=$(( $x + 1 ))
        logger -t jffs/scripts/services-start $int_check interface down
    else
        logger -t jffs/scripts/services-start $int_check interface up
        service restart_dnsmasq
        break
    fi
done

But this still didn't work and I needed to manually restart dnsmasq after the router was up. I went through the log and it appears to me that the interface is up and therefore I can't understand why I am needing this additional restart. I have commented the syslog entries in this pastebin:

https://pastebin.com/tmBkeMcg

Any idea why this is requiring the second manual restart?
And is there a better place for me to put this restart to ensure it takes?

thanks

 

[bengalih]

Ok - so I found that if instead of waiting/checking for the interface I just use a sleep delay (regardless), I can get it to work.

2 seconds is what is needed. 1 second doesn't work, but 2 seconds does.

I've logged here what is happening within those 2 seconds:

https://pastebin.com/BZMRsviD

I'm not sure if it is something in the first grouping where a bunch of interface drivers are being initialized or if it is a race condition in the second grouping after I issue the dnsmasq restart where it appears the USB drive is coming online.

I'm hoping someone who is more familiar with these startup logs can tell me what is happening in this several second time frame that will allow me to more cleanly put in a proper check rather than just place a delay.

I realize 2 seconds isn't a huge delay, and even if I put it in for 5 to be sure - it just isn't a very clean way to deal with dependencies, I'd rather know what I need to wait for before issuing the restart.

 

[bengalih]

Alright, solved the issue when I noticed the firewall entries in the log.
Turned out it wasn't dnsmasq starting at the wrong time, it was the fact that I had put all the firewall rules necessary for dhcp into the dnsmasq.postconf file and they were getting applied before the firewall was running. The extra start of dnsmasq was simply needed to reload those firewall rules.
I moved all the firewall rules into the firewall-start script and, in fact, the dnsmasq restart I had in services-start was actually not needed at all.

 

[Jack Yaz]

Alright, solved the issue when I noticed the firewall entries in the log.
Turned out it wasn't dnsmasq starting at the wrong time, it was the fact that I had put all the firewall rules necessary for dhcp into the dnsmasq.postconf file and they were getting applied before the firewall was running. The extra start of dnsmasq was simply needed to reload those firewall rules.
I moved all the firewall rules into the firewall-start script and, in fact, the dnsmasq restart I had in services-start was actually not needed at all.

You'll need to watch out for any quick devices that nab an IP before the firewall rules are loaded - otherwise they'll get an IP from the wrong pool. iOS devices seem pretty quick/prone to do this

 

[bengalih]

You'll need to watch out for any quick devices that nab an IP before the firewall rules are loaded - otherwise they'll get an IP from the wrong pool. iOS devices seem pretty quick/prone to do this

I haven't seen an issue with that. In playing with the firewall rules, I did experience some instances where the guest WiFi clients received IPs from my external DHCP server on my LAN, but since they were on a different subnet AND there would be no firewall rules to allow them, they were unable to access anything.

I only saw this when implementing some of the required iptables/ebtables rules and not others, and only because I was experimenting with a minimal configuration to determine which rules were really needed.

Without any of the firewall rules they won't get any DHCP traffic, and with all of them they will get the right ones.

IOW, without the firewall rules loaded they don't seem to get anything and with (all) the firewall rules loaded they will get the right one, so I don't see this as happening. Perhaps in another configuration? Don't think it can apply to me.

 

[Jack Yaz]

I haven't seen an issue with that. In playing with the firewall rules, I did experience some instances where the guest WiFi clients received IPs from my external DHCP server on my LAN, but since they were on a different subnet AND there would be no firewall rules to allow them, they were unable to access anything.

I only saw this when implementing some of the required iptables/ebtables rules and not others, and only because I was experimenting with a minimal configuration to determine which rules were really needed.

Without any of the firewall rules they won't get any DHCP traffic, and with all of them they will get the right ones.

IOW, without the firewall rules loaded they don't seem to get anything and with (all) the firewall rules loaded they will get the right one, so I don't see this as happening. Perhaps in another configuration? Don't think it can apply to me.

Probably works OK if you're using an external dhcp server and not dnsmasq