Messages

# opnsense-revert opnsense && opnsense-patch 90f1d1d766 && service configd restart

After a week without issue, I can confirm the fix as well.

@patman From the log I can see the new "force" doesn't go through, likely because the backend wasn't restarted (no reboot). small oversight on my end in instructions provided. Run this:
# service configd restart

Thanks, done, checking over the weekend.

PS: It's really annoying routers give out 192.168.x.x addresses temporarily as it can mess up the system state.

Yeah, ask me ... I asked my provider to even set the router into "bridge mode". I wonder how this behavior conforms to bridge according to IEEE 802.1 ...  :-X

Good? Morning!

I think the fix still applies, feel free to try it now:
# opnsense-revert opnsense && opnsense-patch 90f1d1d766

So I tested this patch, but it does not work for me. Default route was gone again this morning. Here is the log (with the patch applied):

Code Select Expand

2023-02-24T06:20:32 Notice dhclient Creating resolv.conf
2023-02-24T06:20:32 Notice dhclient New Routers (vtnet2): 81.xxx.xx.1
2023-02-24T06:20:32 Notice dhclient New Broadcast Address (vtnet2): 81.xxx.xx.255
2023-02-24T06:20:32 Notice dhclient New Subnet Mask (vtnet2): 255.255.255.0
2023-02-24T06:20:32 Notice dhclient New IP Address (vtnet2): 81.xxx.xx.x29
2023-02-24T06:19:39 Notice dhclient Creating resolv.conf
2023-02-24T06:19:39 Notice dhclient New Routers (vtnet2): 192.168.100.1
2023-02-24T06:19:39 Notice dhclient New Broadcast Address (vtnet2): 192.168.100.255
2023-02-24T06:19:39 Notice dhclient New Subnet Mask (vtnet2): 255.255.255.0
2023-02-24T06:19:39 Notice dhclient New IP Address (vtnet2): 192.168.100.10
2023-02-24T05:24:03 Error dhclient send_packet: No route to host
2023-02-24T05:17:44 Error dhclient send_packet: No route to host
2023-02-24T05:11:04 Error dhclient send_packet: No route to host
If interesting, you can find the leases in the attached file. Interestingly, this time my modem first provided a local address and a minute later a correct (external) one.

You're welcome, thanks for the help, the error was pretty annoying as it needed admin rights to fix the Internet. ;)
New patch applied, I will report back in a few days.

Hi!

Thanks, I'd love to see the debug output from the patch here to confirm,

Ok, sorry, here is the log from this morning with patch 26d26e2054:

Code Select Expand


2023-02-23T06:24:26 Notice opnsense /usr/local/etc/rc.newwanip: plugins_configure monitor (execute task : dpinger_configure_do(,WAN_DHCP))
2023-02-23T06:24:26 Notice opnsense /usr/local/etc/rc.newwanip: plugins_configure monitor (,WAN_DHCP)
2023-02-23T06:24:26 Notice opnsense /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 81.xxx.xx.1
2023-02-23T06:24:26 Notice opnsense /usr/local/etc/rc.newwanip: ROUTING: IPv4 default gateway set to wan
2023-02-23T06:24:26 Notice opnsense /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'wan'
2023-02-23T06:24:26 Notice opnsense /usr/local/etc/rc.newwanip: No IP change detected for WAN[wan]
2023-02-23T06:24:26 Notice dhclient Creating resolv.conf
2023-02-23T06:24:26 Notice dhclient New Routers (vtnet2): 81.xxx.xx.1
2023-02-23T06:24:26 Notice dhclient New Broadcast Address (vtnet2): 81.xxx.xx.255
2023-02-23T06:24:26 Notice dhclient New Subnet Mask (vtnet2): 255.255.255.0
2023-02-23T06:24:26 Notice dhclient New IP Address (vtnet2): 81.xxx.xx.x29
2023-02-23T06:24:26 Notice dhclient DEBUG calling add_new_address/add_new_routes
2023-02-23T06:24:26 Notice dhclient DEBUG alias_ip_address:
2023-02-23T06:24:26 Notice dhclient DEBUG new_ip_address: 81.xxx.xx.x29
2023-02-23T06:24:26 Notice dhclient DEBUG new_ip_address: 81.xxx.xx.x29
2023-02-23T06:24:26 Notice dhclient DEBUG old_ip_address: 81.xxx.xx.x29
2023-02-23T06:24:26 Notice dhclient DEBUG entering with BOUND
2023-02-23T05:24:07 Error dhclient send_packet: No route to host
2023-02-23T05:23:27 Error dhclient send_packet: No route to host
2023-02-23T05:22:49 Error dhclient send_packet: No route to host


Default route is still here, but I'm not 100% sure as the issue did not occur everyday on my setup. Do you want me to apply patch 90f1d1d766 or should I wait still for some days to be more sure?

Thanks!

Hi!

Can you guys apply and see if it behaves better? I still need the log output produced by "dhclient" from the general log.

Thanks for the patch, I have applied it this morning. It will take a few days till I can be sure that it had effect. I'll report back.

Here is the log you requested:

Code Select Expand


2023-02-22T06:24:22 Notice opnsense /usr/local/etc/rc.newwanip: No IP change detected for WAN[wan]
2023-02-22T06:24:22 Notice dhclient Creating resolv.conf
2023-02-22T06:24:22 Notice dhclient New Routers (vtnet2): 81.xxx.xx.1
2023-02-22T06:24:22 Notice dhclient New Broadcast Address (vtnet2): 81.xxx.xx.255
2023-02-22T06:24:22 Notice dhclient New Subnet Mask (vtnet2): 255.255.255.0
2023-02-22T06:24:22 Notice dhclient New IP Address (vtnet2): 81.xxx.xx.x29
2023-02-22T05:19:49 Error dhclient send_packet: No route to host
2023-02-22T04:57:12 Error dhclient send_packet: No route to host
2023-02-22T04:33:03 Error dhclient send_packet: No route to host

I do not know if relevant, but I'm running in a virtualized environment, so the WAN interface does not go down when my cable modem is off.

Hi!
I still have the issue with OPNsense 23.1.1_2-amd64 in strange intervals.  It always happens after several hours (probably 4 since the lease time is 28800?) of my cable modem being off. For some reason the default route is lost. Probably I know, why it is not reestablished:

Code Select Expand

<13>1 2023-02-21T06:23:10+01:00 OPNsense.lan opnsense 33755 - [meta sequenceId="6"] /usr/local/etc/rc.newwanip: No IP change detected for WAN[wan]

Code Select Expand

/usr/local/etc/rc.routing_configure fixes the issue also for me.

Please see https://forum.opnsense.org/index.php?topic=32347.0 as this is a duplicate!

Hmm, that sounds similar to my issue https://forum.opnsense.org/index.php?topic=32439.0. Is there a way to trigger the issue?

I have the same problem but only on the IPv6 gateway : https://forum.opnsense.org/index.php?topic=32263.0

Thanks for the hint, but I'm not sure my issue is the same. For me everything is working fine until the WAN (IPv4) connection goes down (cable modem is powered off) for more than a few minutes. (Need to figure out how long it takes roughly) Then my default route is removed and does not come back until I disable/enable the gateway.

Hi!

After upgrading form 22.7.11 to OPNsense 23.1_6-amd64 I run into the issue that (almost) each morning after turning off my cable internet modem over night my default route is gone and not reestablished. Restarting the gateway service does not help, deactivating and reactivating the default gateway does.
I verified that the configuration did not change and it is consistent with the previous. If I turn of the link just for a short time, it works.
Has anyone ideas, that would be very kind!

Thanks!

Hi!

As you can read see from the previous question here https://forum.opnsense.org/index.php?topic=11742.0 there is no ARM support, which is required for this device. It does not seem to really progress, see here https://forum.opnsense.org/index.php?topic=22262.0

Yes, please, let us know, as I have a similar issue with suricata running permanently at ~35% WCPU (2 core Intel Atom)
I can see in my long-time logs, that the CPU usage went up around 27th of September where I most probably upgraded to 21.7.3 which introduced Suricata 6.0.3.

[update]
just found this https://forum.opnsense.org/index.php?topic=24895.msg120705#msg120705 which seems to be the issue.

Thanks, had the same issue with dns-root.de

Code Select Expand


2021-08-27T00:36:15 ntpd[70683] daemon child exited with code 1
2021-08-27T00:36:15 ntpd[91311] unable to bind to wildcard address :: - another process may be running - EXITING


I have the same issue happening. Unfortunately, I do not know how to permanently fix it, as this happens everytime the WAN goes down. The issue is that a second process is running but it is not seen by the GUI. You can check by using

Code Select Expand

ps ax | grep ntp on the shell.
If you kill that process

Code Select Expand

killall ntpd then you are able to start the ntp from the GUI again and it is recognized as running (icon goes green). There is no reboot required.