Like I said before, if this is present on the default gl iNet firmware as well, then I would go and raise a thread on their forums with this information.
They have very responsive developers over there because they’re only interested in a smaller set of devices (the ones they sell).
I can't imagine that this issue exists in the original firmware, but it's surely worth checking. Afaik, they use an older version of OpenWrt, probably pretty much has been changed since …
Actually, GL.iNet keeps on top of updates, unlike most that I know of. Their repo is remarkably current -- based off 18.06.1:
jeff@deb-devel:~/devel/openwrt-glinet-develop$ git merge-base glinet/develop openwrt/openwrt-18.06
70255e3d624cd393612069aae0a859d1acbbeeae
jeff@deb-devel:~/devel/openwrt-glinet-develop$ git log -1 70255e3d624cd393612069aae0a859d1acbbeeae
commit 70255e3d624cd393612069aae0a859d1acbbeeae (tag: v18.06.1, v18.06.1)
Author: Jo-Philipp Wich <redacted>
Date: Thu Aug 16 18:36:48 2018 +0200
OpenWrt v18.06.1: adjust config defaults
Signed-off-by: Jo-Philipp Wich <redacted>
And if it doesn’t exist, why?
Did they do something specifically to mitigate it, or does being on an older firmware simply fix it?
The answers to those questions are just as important and would help any dev in finding/fixing the issue.
I filed a bug report: https://bugs.gl-inet.com/view.php?id=146
You're completely right, the GL-iNet devs are probably very interested in OpenWrt working flawlessly with their hardware 
@l3u, @lantis1008, @rezder, @Pippo
If you are interested in resolving this issue, you should at least vote for it:
https://bugs.openwrt.org/index.php?do=details&task_id=2145
Otherwise developers won't raise this task priority.
Need first to set up my router to try if behaves the same (or re flash to standard 18.02).
First thing first how I do make logread more verbose for dnsmasq ?
Second wasn’t able to figure out by reading wiki
Is ipv6 supported by dnsmasq-full or is odhcp taking care of ipv6 dhcp ?
Okey my relayd plus switch modded ar150 is too difficult to understand to me
Recovered the AP with switch on both rj45 plug
Unfortunately is meaningless to this example as per my DHCP server its off ? (dont't know if it is or not)
but my layout is
Router DHCP server ----> ar150 1st port lan ---> radio0 access point
so when I connect by wifi to radio0 I can try to mirror traffic from Lan to second ethernet port
What I figured out today is that without having swconfig properly set I still can get some ipv6 related (I believe) traffic whille scanning with wireshark for packets on the second ethernet port !!!!!
As soon as I disable dhcpv6 on Lan:
etc/config/dhcp option dhcpv6 'disabled'
I dont get any pèackets on my wireshark probe ??
Sorry I am new I don't no how things work yet. I voted
I wondering how close this is to bricking it, because if the there is no dhcp hosts in the generated
file /tmp/hosts/dhcp.cfg01411c why is the ipv6 dhcp running at all. That looks like a accident waiting to happen to me.
@rezder that’s why I was asking about odhcp
Think I’ll have to try to reflash my ar150 and see what I can guess ! Still need the most possible verbose output on dmesg / logread about dnsmasq / dhcp ! Any hint ??
@Pippo I don't know but I expect you could change the command in dnsmasq init script to launch dnsmasq in a more verbose mode. That should create more messages in the log. You could do the same for procd and maybe make your own init script that logs information from the bus at a interval so you could follow what happens to the br-lan.
Found
log level ’4’
In
etc/config/dhcp
dhcp config section
It’s like my config is different from wiki
https://openwrt.org/docs/guide-user/base-system/dhcp
But my build it’s kind of 5 months old from trunk/master repo no 18 fork
I’ll look into the dnsmasq init.d script
procd is still obscure to me I’ll Google about it
Not sure if my build is using it or the old initd scripts?
Does procd appear with is name in ls proc or it has a pid associated with it (in this case how do I find it?)
@Pippo Sorry my bad I think I misunderstood how you set debug levels on procd. It is the first process pid 1, ps should display it.
root@GL-AR150:/# ps
PID USER VSZ STAT COMMAND
1 root 1544 S /sbin/procd
You can see my configs on my bug
https://bugs.openwrt.org/index.php?do=details&task_id=2145
and dmesg and logread from with and without cable pluged in.
I could not find anything about log level in dhcp.
Ok still have to flash my ar150 with openwrt 18.06.2
my build has in etc/rc.d
...
S19dnsmasq
...
...
S35odhcpd
...
downloaded last openwrt image:
openwrt-18.06.2-ar71xx-generic-gl-ar150-squashfs-sysupgrade.bin
is exactly the same
while Gl.inet download pages shows
for
openwrt-ar150-2.264.bin
...
S35odhcpd
...
...
...
S60dnsmasq
...
I dont understand a lot about all this but since people where pointing towards timing issues
if I am not wrong maybe Gl.inet people know better ??!!
They start dnsmasq later during boot and after network and odhcpd. It is interesting because the dnsmasq script during boot does not configure dhcp it is only the second trigger run that tries, Maybe starting it later prevent carrier true from hanging.
I just tried it changing the boot order by renaming the link to dnsmasq in /etc/rc.d from S19dnsmasq to S60dnsmasq.
The problem with the missing dhcp-range option persists (most probably due to the check mentionned above still failing, if the "force" option is not set)
The only difference is: dnsmasq is only started once and is not restarted during boot (which may be a more desireable behavior).
Still not flashed 18.06.2 playing with the gl-inet
Firmware that is really cool by the way !!
Why you just didn’t edit the etc/init.d/dnsmasq script
Start=60 instead of 19 ?
I'm not so deep into OpenWrt yet … I think the order is simply defined by alphabetical order of the script links in /etc/rc.d? So if we want to see if a different startup order fixes the problem, is changing the name not the right way?
… apart from that: Does the gl-inet firmware set the "force" option in the dhcp config?!