Little cosmetic issue after upgrade to 25.1.1

[IsaacFL]

I did the update to 25.1.3 and still seeing the ipv4 log entries.

[gpb]

Same, I posted a message on reddit here.

[franco]

Are we sure we are not looking into depleted states? Just double-checking as promised on Reddit.


Cheers,
Franco

[gpb]

Not sure who you're asking.  Here's my take...it seems like while these thousands of log messages are showing up (I have all logging disabled) I should still have connectivity and trying to hit a web page fails.  My VLANs can't talk to my LAN.  While some could be invalid states, as soon as we hit a certain elapsed time post-boot, suddenly all of them work and the logging stops (for the most part).  It's more like the interfaces in opnsense are failing to initialize or something in the core functionality (log messages aside).  So to be clear, I see two different symptoms.  Much delayed connectivity (2 to 3 minutes) and log messaging that is unwanted/unselected.  I haven't the first clue how to even try to debug this.  This is a home network, so the thousands of messages seem excessive even if they were non-valid states...?

[IsaacFL]

Are we sure we are not looking into depleted states? Just double-checking as promised on Reddit.


Cheers,
Franco

It may be, but it shouldn't be showing in the logs as I don't have any of the default logging enabled.

This started after the update from 25.1 to 25.1.1.  With no changes on my side. I don't log blocks normally just a few pass rules on local traffic so my logs usually have only a few entries per day until whatever changes.

[IsaacFL]

Not sure who you're asking.  Here's my take...it seems like while these thousands of log messages are showing up (I have all logging disabled) I should still have connectivity and trying to hit a web page fails.  My VLANs can't talk to my LAN.  While some could be invalid states, as soon as we hit a certain elapsed time post-boot, suddenly all of them work and the logging stops (for the most part).  It's more like the interfaces in opnsense are failing to initialize or something in the core functionality (log messages aside).  So to be clear, I see two different symptoms.  Much delayed connectivity (2 to 3 minutes) and log messaging that is unwanted/unselected.  I haven't the first clue how to even try to debug this.  This is a home network, so the thousands of messages seem excessive even if they were non-valid states...?

My functionality has not been impacted, just items in the logs that should not be showing.

[gpb]

My functionality has not been impacted, just items in the logs that should not be showing.

OK, maybe I'm being impatient or my memory is bad here, but as I remember it, once I could log back in I had full network functionality.

[franco]

If it was introduced in 25.1.1 it's most likely https://github.com/opnsense/src/commit/1a2a481ca

I can build a 25.1.3 kernel with that commit reverted, but going forward revert is not an option, because that commit is required for certification to pass, otherwise these packets actually being dropped are only logged as "pass", which is a general issue with the pf(4) code.


Cheers,
Franco

[pfry]

Are we sure we are not looking into depleted states? Just double-checking as promised on Reddit.

Perhaps something similar/same (following update to 25.1.3 and reboot):

Code Select Expand

Int    Dir    Proto    Source            Nat            Destination        State            Rule
all    ->    tcp    47.190.83.191:42238                47.190.83.194:110    ESTABLISHED:ESTABLISHED    EDGE: Block any from any to EDGE address
all    <-    tcp    47.190.83.191:42238                47.190.83.194:110    ESTABLISHED:ESTABLISHED    block all targeting port 0
all    ->    tcp    47.190.83.194:49188                47.190.83.191:110    ESTABLISHED:ESTABLISHED    EDGE: Block any from any to EDGE address
all    <-    tcp    47.190.83.194:49188                47.190.83.191:110    ESTABLISHED:ESTABLISHED    block all targeting port 0
all    ->    tcp    10.101.11.160:58500                20.10.31.115:443    ESTABLISHED:ESTABLISHED    TRUST: Pass any from TRUST net to any
all    <-    tcp    47.190.83.202:4330    10.101.11.160:58500    20.10.31.115:443    ESTABLISHED:ESTABLISHED    let out anything from firewall hos

Looks like the first few states were a bit confused as to the allow-out rule.

Edit: Preceding message explains it. Aside: Prior reboots must have gone by with short-lived states. Interesting.

[franco]

@pfry technically this is about the log producing spurious messages, not about actual state handling

Here is a test kernel with the reverted patch:

# opnsense-patch -zkr 25.1.3-nolog
(reboot)

Also, I think I know what's wrong here.  Will tinker with it.


Cheers,
Franco

[franco]

I don't want to interrupt the hot discussion but I think https://github.com/opnsense/src/commit/2a564b0b652 should address this. You can try this kernel now:

# opnsense-update -zkr 25.1.3-fixlog
(reboot)

It would be *really* nice to get feedback on this.


Cheers,
Franco

[gpb]

I don't want to interrupt the hot discussion but I think https://github.com/opnsense/src/commit/2a564b0b652 should address this. You can try this kernel now:

# opnsense-update -zkr 25.1.3-fixlog
(reboot)

It would be *really* nice to get feedback on this.


Cheers,
Franco

Perfect timing, I was logged in ready to apply the first patch when my browser alerted you replied.  I applied the latest patch and that looks to resolve the issue.  That odd delay I mentioned remains but ultimately not a problem, just an observation.  My logs are completely empty post boot and tested to make sure normal logging from my geoip rules works and it does.  Thanks for the fast turn-around!  :)

[IsaacFL]

I just applied the # opnsense-update -zkr 25.1.3-fixlog with reboot and so far seems like it has fixed it.

[franco]

Nice, thanks. I'll pass this on to FreeBSD then and it should land in 25.1.4.


Cheers,
Franco