dnsmasq: failed to create listening socket for 192.168.1.1: Address already in use

[bibikalka]

Alright, my router: RT-AC86U. A few addons, rebooted nightly on schedule by cru.

5 4 * * * /sbin/service 'reboot' #ScheduledReboot#

Since about version RT-AC86U_386.12_6, give or take, in certain configurations I get this particular error upon auto-reboot once every few days:

Sep 25 04:06:56 RT-AC86U-9988 dnsmasq[4888]: failed to create listening socket for 192.168.1.1: Address already in use

This particular address [192.168.1.1] is the router itself.

At this point the router stops assigning DHCP IP addresses. A cure is to reboot with the button, in a few really severe cases I had to unplug the power supply for ~10 seconds, replug.

I'd say the issue sort of appeared when ~ dnsmasq was updated to version 2.90.

In random configurations this happens intermittently, in other random configurations it does not.

Once I tried to wipe/restore /jffs from the backup - did not cure the issue while it was happening.

For example, router is issue free for ~ a month, running RT-AC86U_386.13_2. At the end of August 2024 I update Entware packages, and nothing else. I start getting this error every few days. A few days later I turned on Samba sharing, the issue is gone, no issue for a couple of weeks.

3 days ago I updated to RT-AC86U_386.14, some reboots are fine, but I got this issue today again. Downgraded back to 386.13_2 just now, hopefully things are back to stable.

Something residual in memory upon warm reboot creates the issue, but not always.

Thoughts?

 

[sfx2000]

Are you running any third party scripts?

If so, remove them, reset to factory defaults, and configure from there...

 

[bibikalka]

Are you running any third party scripts?

If so, remove them, reset to factory defaults, and configure from there...

While it's a sound advice, there is no guarantee I would not end up in the same place after everything else is configured again ...

I am thinking if I'd take br0 interface down before restart, and perhaps dnsmasq, it's possible things would start up in a cleaner state.

 

[dave14305]

A lot of your older posts show you were also running Unbound Manager. If you still are, you should uninstall it and test for a week without it.

 

[bibikalka]

A lot of your older posts show you were also running Unbound Manager. If you still are, you should uninstall it and test for a week without it.

Thanks! It appears now that several things call for "service restart_dnsmasq", and that may end up clashing during boot if it happens simultaneously.

Subtle differences in boot sequence cause a few things try to trigger dnsmasq restart, and when that happens simultaneously, problems emerge. Otherwise unbound&diversion seem reasonably compatible, since on many boots unbound&diversion run OK together.

I think I got some more insight after the boot this morning, see this post:

Entware - Where is Entware started upon reboot?

Alright, I was chasing the mysterious error I was getting from dnsmasq - link. And it took me down this rabbit hole below. I've taken this out of the post in the Diversion thread, for better visibility. The story is below. But the key question is where are different Entware related things are...

www.snbforums.com

 

[dave14305]

Otherwise unbound&diversion seem reasonably compatible, since on many boots unbound&diversion run OK together.

I think (speculate) the variable is the timing of when the USB is detected and when Unbound tries to start versus the firmware starting dnsmasq multiple times during boot.

I doubt Unbound Manager was written to be aware of multiple dnsmasq instances when it’s trying to determine its own status and listening ports.

Start cleanly with just Diversion and see how it goes.

 

[bibikalka]

I think (speculate) the variable is the timing of when the USB is detected and when Unbound tries to start versus the firmware starting dnsmasq multiple times during boot.

I doubt Unbound Manager was written to be aware of multiple dnsmasq instances when it’s trying to determine its own status and listening ports.

Start cleanly with just Diversion and see how it goes.

Yep, correct. Let me monitor this and will report back on how it goes.

Also, it seems that once Entware drive is mounted, any dnsmasq restart will launch Diversion too since it'll have the working path in the dnsmasq config file for it.

This appears to be similar to that 'cru' issue where jobs were getting lost due to simultaneous invocations in different scripts. But that was far more noticeable given the number of cru entries that were getting created.

 

[Ripshod]

Have to ask - what version of Diversion are you running? I know you said you updated Entware Packages, but what about the add-on scripts?