Messages

Haha, I saw that "workaround" when reading about the I225's. I don't think the I225's are any sort of problem, nor is any of my customer-owned equipment.

Yeah... I know... but it is what it is...

Thought I mention it just in case you haven't read about it elsewhere :)


Hope the "truck roll" is your solution eventually!

Truck roll was the solution, well kinda. They came and told me they were replacing the PON card at the CO. I guess other subscribers on my splitter had service calls earlier in the day, and they replaced some ONTs, but that obviously didn't fix the issues, so they realized it was all the same PON card and just replaced that. Seems to be fine now! It's weird how this showed up like a DHCP/ARP issue though!

You could also just insert a Switch between the ONT and the Router to check if it's not some weird conflict between the two because of the NIC Chipsets :)

Haha, I saw that "workaround" when reading about the I225's. I don't think the I225's are any sort of problem, nor is any of my customer-owned equipment.

Anyways, quick update, I got the ISP router for testing, and it disconnected twice in under an hour when trying to renew DHCP leases.

So this is probably not an opnsense issue, it sounds like my ONT is going bad (or possibly the PON card on the ISP side).

For anyone who cares to follow, this is the messages I was getting on the ISP router (note this IP is my ISP gateway):

2026 May 27 17:34:34 wan_detection info [WAN.6][WDHCP] eth1 arping to x.y.z.1 fail.

followed by a very delayed DHCP lease renewal AFTER the issue/disconnect occurs

2026 May 27 17:55:43 dhcpc.sh info  "[WAN.6][WDHCP] bound IP: x.y.z.113"

Based on a similar thread, it sounds like it's indeed a bad ONT/OLT/LineCard. Truck roll scheduled later this week.

https://community.verizon.com/discussion/1564866/cr1000a-losing-connection-dhcpc-sh-and-wan-detection

So (if I'm reading that right) we know that ping was already not working at 11:46:22, which was 46 seconds before the DHCP lease renewal was attempted, but it could have started up to 136 seconds before. Somewhat inconclusive, but if there's a pattern where the pings start failing right before the lease renewal, it might suggest that the ISP is doing something (very) overly aggressive with lease reclamation...

Agreed, and also I just switched to a spare ERLite-3 I had laying around, fully updated it, and I got disconnected within a few minutes...

So this is now really looking like one of two things I would guess: CPE (ONT), or ISP-side configuration with DHCP.

I'm trying to find useful logs on the ERLite-3, but not having much luck. Also, my ISP won't troubleshoot/escalate further without me testing with one of their routers, so cue the long dragged out troubleshooting process on this one.

But again, it feels EXTREMELY SUSPICIOUS that at 10:47:08 it did a RENEW, then at 11:47:08 host down messages started.

You won't see any messages from dhclient before that, because it's not trying to send anything! You didn't answer my question... you said you have separate monitoring that tells you when things are down. Did your independent monitoring detect a problem at exactly 11:47? I'm trying to determine if problem has already started happening beforehand, and dhclient is just a victim, or if something to do with lease renewal is actually triggering the problem...

I'm pinging Google DNS (8.8.8.8) every 90 seconds. Uptime Kuma detected a failure very close to the same time:

2026-05-27 11:47:09    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. --- 8.8.8.8 ping statistics --- 47 packets transmitted, 0 received, 100% packet loss, time 47131ms

So I don't know if that fully answers the question, given the 90 second interval, and ~47 seconds of ping attempts.

but do these ping failures start happening at exactly the same time as the DHCP lease renewal failures?

Just a few minutes ago I had this happen:

<13>1 2026-05-27T10:47:08-04:00 router.home.lab dhclient 25229 - [meta sequenceId="1"] dhclient-script: Reason RENEW on igc1 executing
<13>1 2026-05-27T10:47:08-04:00 router.home.lab dhclient 27148 - [meta sequenceId="2"] dhclient-script: Creating resolv.conf
<27>1 2026-05-27T11:47:08-04:00 router.home.lab dhclient 40635 - [meta sequenceId="1"] send_packet: Host is down
<27>1 2026-05-27T11:47:10-04:00 router.home.lab dhclient 40635 - [meta sequenceId="2"] send_packet: Host is down
<27>1 2026-05-27T11:47:14-04:00 router.home.lab dhclient 40635 - [meta sequenceId="3"] send_packet: Host is down
<27>1 2026-05-27T11:47:25-04:00 router.home.lab dhclient 40635 - [meta sequenceId="4"] send_packet: Host is down
<27>1 2026-05-27T11:47:57-04:00 router.home.lab dhclient 40635 - [meta sequenceId="5"] send_packet: Host is down
<27>1 2026-05-27T11:48:12-04:00 router.home.lab dhclient 40635 - [meta sequenceId="6"] send_packet: Host is down
<27>1 2026-05-27T11:48:30-04:00 router.home.lab dhclient 40635 - [meta sequenceId="7"] send_packet: Host is down
<27>1 2026-05-27T11:48:45-04:00 router.home.lab dhclient 40635 - [meta sequenceId="8"] send_packet: Host is down

I rebooted the router after that and made my EEE changes. But again, it feels EXTREMELY SUSPICIOUS that at 10:47:08 it did a RENEW, then at 11:47:08 host down messages started.

Unfortunately I didn't get a snapshot of the leases BEFORE the reboot, but here's what I see right now:

Lease #1

renew 3 2026/5/27 15:47:08;
  rebind 3 2026/5/27 16:32:08;
  expire 3 2026/5/27 16:47:08;

Lease #2

renew 3 2026/5/27 17:02:16;
  rebind 3 2026/5/27 17:47:16;
  expire 3 2026/5/27 18:02:16;

Again, I rebooted before the second (new) lease got assigned, hence the slight discrepancy in time shift there.

Just for clarification, the ISP is pushing 7200 for lease time, so opnsense tries to renew it at 3600 it seems, but then I think it's failing to truly renew or something weird?

How did you observe that disconnect happened at that time? Were you actively using the internet, and it stopped working at that exact time, or are you just basing it on the log messages?

I have monitoring set up in different networking tools, including Uptime Kuma and some others. I also verified via SSH on the opnsense router that I was unable to ping my first hop at the ISP, but I was able to ping my "locally assigned WAN IP"

What type of network interface is in your mini-PC?

This mini PC is a dual NIC setup with both interfaces being Intel I225-V's. I have a USB-C 2.5GbE NICs available for testing if needed, not sure which chipset off the top of my head for that.

I don't see anything unusual in dmesg. It seems like the watchdog on the interface is what is causing it to try to bring it back up after it "goes down", and it renews the lease at that time.

Kind of agreed. So this is weird.

I would check a few things:

* `dmesg` for link up/down events around the exact timestamps
* Interface statistics for errors or resets
* Different ethernet cable and switch/ONT port
* Disable hardware offloading temporarily in OPNsense
* Force interface speed instead of auto negotiation as a test

Also interesting that recovery happened only after several failed renewal attempts. That almost sounds like the interface temporarily lost carrier or stopped transmitting properly rather than DHCP itself being broken.

This very well could be ONT wonkiness - and if so, I'm thinking that will show up when I test with another router. I've already tried swapping out the ethernet cable on the WAN side. and moved the LAN side to a different switch (in case my 2.5Gb PoE+ switch was causing issues).

I already had all of the offloading stuff disabled. I read up a little on the I225V issues, and the already had the Flow Control set to disabled, but I also added the tunable for turning Energy Efficient Ethernet off. Not sure why I would have to do this now though, as this hasn't been an issue in the past. Again, this setup has been reliably working for almost 2 years now and just started this issue this week, so I kinda feel like the I225V wonkiness is probably less likely of a factor, but who knows. I also have power set to specific profiles in the UEFI/BIOS for this mini PC. I can set the interface speeds manually also as part of my testing.


Here's some interface stats from just a bit ago, had several disconnects overnight, including an immediate one within 10 minutes of changing the WAN ethernet cable.

Driver   igc1
Index   2
Promiscuous Listeners   1
Send Queue Length   0
Send Queue Max Length   50
Send Queue Drops   0
Type   Ethernet
Address Length   6
Header Length   18
Link State   2
vhid   0
Data Length   152
Metric   0
Line Rate   1.00 Gbit/s
Packets Received   11596180
Input Errors   0
Packets Transmitted   39824259
Output Errors   0
Collisions   0
Bytes Received   5305135568
Bytes Transmitted   55151120462
Multicasts Received   69
Multicasts Transmitted   0
Input Queue Drops   0
Packets for Unknown Protocol   0
Hardware Offload Capabilities   0x0
Uptime at Attach or Statistics Reset   1

[OPNsense 26.1.8_5-amd64]

Hi all,


Running OPNsense 26.1.8_5-amd64 on a physical x86-64 mini PC here...

Recently I started seeing issues with my ISP where connections started dropping randomly and my WAN gateway was not responding.

I have a sneaking suspicion, based on some recent logs, that this might be due to some strange DHCP Lease behavior - possibly a change on the ISP side, as it started occurring in part with no change on my end.

Here's an example of a recent "disconnect" from my system logs that I wanted to see if someone agrees this might look like a DHCP issue, or tell me to go fish elsewhere:

# tail -n 2 /var/log/system/system_20260526.log
<13>1 2026-05-26T23:04:53-04:00 router.home.lab dhclient 36272 - [meta sequenceId="1"] dhclient-script: Reason RENEW on igc1 executing
<13>1 2026-05-26T23:04:53-04:00 router.home.lab dhclient 38216 - [meta sequenceId="2"] dhclient-script: Creating resolv.conf


# cat /var/log/system/system_20260527.log
<27>1 2026-05-27T00:04:53-04:00 router.home.lab dhclient 84348 - [meta sequenceId="1"] send_packet: Host is down
<27>1 2026-05-27T00:04:55-04:00 router.home.lab dhclient 84348 - [meta sequenceId="2"] send_packet: Host is down
<27>1 2026-05-27T00:05:00-04:00 router.home.lab dhclient 84348 - [meta sequenceId="3"] send_packet: Host is down
<27>1 2026-05-27T00:05:11-04:00 router.home.lab dhclient 84348 - [meta sequenceId="4"] send_packet: Host is down
<27>1 2026-05-27T00:05:32-04:00 router.home.lab dhclient 84348 - [meta sequenceId="5"] send_packet: Host is down
<27>1 2026-05-27T00:05:53-04:00 router.home.lab dhclient 84348 - [meta sequenceId="6"] send_packet: Host is down
<27>1 2026-05-27T00:06:32-04:00 router.home.lab dhclient 84348 - [meta sequenceId="7"] send_packet: Host is down
<27>1 2026-05-27T00:07:14-04:00 router.home.lab dhclient 84348 - [meta sequenceId="8"] send_packet: Host is down
<27>1 2026-05-27T00:07:51-04:00 router.home.lab dhclient 84348 - [meta sequenceId="9"] send_packet: Host is down
<27>1 2026-05-27T00:08:14-04:00 router.home.lab dhclient 84348 - [meta sequenceId="10"] send_packet: Host is down
<13>1 2026-05-27T00:08:40-04:00 router.home.lab dhclient 66066 - [meta sequenceId="11"] dhclient-script: Reason RENEW on igc1 executing
<13>1 2026-05-27T00:08:40-04:00 router.home.lab dhclient 68252 - [meta sequenceId="12"] dhclient-script: Creating resolv.conf

When I looked at my DHCP leases, I saw 2 old IPs, and 4 leases for the current IP I have (I'm on Dynamic IP to be clear):

The 3 leases for my current IP look like:

Lease #1
<quote>
  renew 3 2026/5/27 03:04:54;
  rebind 3 2026/5/27 03:49:54;
  expire 3 2026/5/27 04:04:54;
</quote>
 
Lease #2
<quote>
  renew 3 2026/5/27 04:04:53;
  rebind 3 2026/5/27 04:49:53;
  expire 3 2026/5/27 05:04:53;
</quote>

Lease #3 - after the disconnect/gap
<quote>
  renew 3 2026/5/27 05:08:40;
  rebind 3 2026/5/27 05:53:40;
  expire 3 2026/5/27 06:08:40;
</quote>

Lease #4 - after the disconnect/gap
<quote>
  renew 3 2026/5/27 06:08:40;
  rebind 3 2026/5/27 06:53:40;
  expire 3 2026/5/27 07:08:40;
</quote>

 
The suspicious part to me here is the disconnect occurred right around that 00:04:xx DHCP lease expiration time.


Anyone have some thoughts or guidance? My ISP says everything looks fine and dandy on their side, including us testing DHCP lease resetting and all my network equipment powered off and cycled after my ONT reboot.