[Workaround] GL-AR150: No DHCP if LAN cable is not plugged during boot

Installing and Using OpenWrt
50

For a workaround I am using in init.d/dnsmasq

reload_service() {
        procd_send_signal dnsmasq "$@"
	sleep 5
	rc_procd start_service "$@"
}
51

Well, this is also about timing inside the init script, so most probably, this is really a timing issue.

52

Okey but still what was

dhcp_check has to wait for ?

I don’t have my ar150 with me, but dying to know
what is waiting for ?

Don’t know even what devststus does

But on git I found it calls jshn.sh

You said before that with LAN cable unplugged but with IPv6 address or ipv4 address static given

So you are implying that br-lan set up is taking to long to complete before dhcp_check starts ?

And this is problem number one and then the second problem is that something is crippled by this first action and something else occour that prevent dhcp to work on successive attempts of connecting through lan or wlan ?

53

When cable is plugin procd sends a sigTERM instead of a sigHUB with takes longer to react to that saves it, I do not think that is what it suppose to happen. My guess it only does that because of bad timing again and I think that dhcp_check waits for the old dnsmasq to close down.

54

This is definitely not what should happen! But maybe, the different kinds of signals are the core problem … or the way they are handled. I'm pretty sure the problem is not located where I put my workaround. I think it's more a dirty hack to get it to work. But at least, waiting for that carrier makes it work at all …

1 Like
55

https://openwrt.org/docs/guide-user/base-system/dhcp_configuration#race_conditions_with_netifd

1 Like
56

Well, this will probably "mask" the problem by skipping the dhcp_check() test (making it another workaround), but shouldn't dhcp_check() return successfully instead of failing?

So the question is not how to ship around this issue but why does it happen at all, isn't it?

57

Okay, I can confirm that setting this option ships around the problem by skipping the check in question.

Don't get me wrong: This is definitely the best workaround until now, because one does not have to edit init files, but only set a config option!

But the question is: Should this work without the option (so that we have another problem to be solved) or is the problem that this option should be enabled by default?

The point is that imo, a fresh OpenWrt installation should simply work … so however, this needs to be tracked down!

1 Like
58

I would say "yes" to that -- that the underlying problem is likely that the test of interface "carrier" is failing unexpectedly.

Whether it's worth trying to resolve (and get the patches into master and 19.x), or just documenting the workaround is another question.

59

Because that check is:

  • redundant;
  • has negative effect on fault tolerance;
  • should not be enabled by default.
60

Well, for a router that is advertised as being delivered with OpenWrt preinstalled, I would say one should fix it so that one would not have to say "OpenWrt preinstalled, but with a recent version, you have to do some workaround to get it to work" :wink:

61

If the check is the problem and you're right that it's redundant, the problem really should be fixed upstream (by removing that check).

Hopefully, some dev will look at this thread and the corresponding bug and clarify what's right and wrong – and eventually fix the problem!

Maybe you want to comment on my bug?!

62

It's pretty clear now counting your last comment.
The only productive thing I can do is vote for it and add to the watchlist.
I've already done both, so what's left is developers opinion and action.
Alas, I don't have this bug and can only reproduce it synthetically putting interface down.

63

Want get rid of 28 €?! Then you can also have this bug :wink:

2 Likes
64

@l3u @vgaetera cant quite understand your bug joke one day maybe I will

Just pointing out that on my ar150 modded firmware with just eth0 over switch controlling both rj45 plugs and relayd using wwan on router radio I think I am getting same behaviour when the second radio (usb dongle through usb hub) member of the br-lan interface is missing (not attached to the router) dont have the hub and dongle with me to test what happens when they are connected to the router I'll try to get ahold of them to be sure that the behavior is different when both the pieces of the br-lan are in place at boot time.

65

Personally for me one more UCI-option doesn't change much, but this is definitely an issue for new users.
There're plenty of bugs on similar level, but it seems that we don't have enough developer resources to resolve them.

66

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).

67

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 …

68

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>
69

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.

2 Likes