Messages

I'm not in the office next week. Let's try to pick it up when I'm back.


Cheers,
Franco

Thank god for AI.  In the past someone would have simply asked

a) to include "Fixed upstream in commit 463ec13", or
b) to ask why version 2.3.11 wasn't in OPNsense yet.

Since a) is new we could have done that but since b) makes more sense the answer was already mentioned here:

https://forum.opnsense.org/index.php?topic=52419.msg275754#msg275754

Don't take this wrong way. I just think walls of text get in the way of human communication and effectiveness.


Cheers,
Franco

https://github.com/opnsense/ports/commit/fbd7569d4e15b

Hi Alan,

It's possible to support the setting for consistency. However, we were discussing pulling PPTP and L2TP support for 27.1 to prepare for the MVC/API migration.

We'll have to discuss internally if L2TP can stay. Ideally, I'd like to hear from other people who still use it.


Cheers,
Franco

I'll try to sync the ports tree tomorrow.

Locally you can use this in the port directory:

# make makesum


Cheers,
Franco

Just wait for 26.7.7_7 hotfix ;)

J/k, I think we can do without a hotfix in .7. Happy to hear the issue hasn't returned.


Cheers,
Franco

@fbantgat7 Your issue is likely not related to PPPoE since that part is fine, but on top negotiation changed in DHCPv6 as it seems.  This could be a provider change.  I'm not aware of regressions in DHCPv6 connectivity in 26.7.x.


Cheers,
Franco

wizardtemp... I haven't heard this name in a long time ;)

You can review and remove the left-over configuration via

# pluginctl -f wizardtemp

The old wizard this belongs to was removed in 25.7.


Cheers,
Franco

Hi Phil,

There's a high influx of sizeable commits to stable/15 regarding Intel drivers at the moment (100+ commits) which makes it very difficult for us to navigate as people already report regressions and we need to slow down to sort this out.  I'm doubting a bit that FreeBSD really has a hand on this so we will perhaps see all these regressions in 15.2 either way if we can't pin them down.

If the particular patch is on stable/15 I will see it during review, but I'm not sure which driver batch we're going to tackle for 26.7.8. igc is still pending in all of this and meanwhile e1000/igb receive more commits lately still. We want to separate the driver updates in batches to make it a bit easier to do triage/bisect afterwards.


Cheers,
Franco

Nope, that's great news.

I've worked today on enabling the upgrade path to 26.1.11 -> 26.7.7. It looks good from my perspective so expecting this to be live later today.


Cheers,
Franco

@paoba yeah this seems like a slightly different issue from the pressing DDP load failed and driver doesn't work at all.


Cheers,
Franco

Sounds like a kernel panic that caused a boot loop, but without looking at the stack trace it's not easy to tell. There were little kernel patches in 26.7.7 compared to 26.7.6 and nobody else reported something so far so it's unclear what the cause was/is.


Cheers,
Franco

miniupnpd 2.3.11 has been released, is it not possible to update the plugin to this version?

Netgate seems to be working on it...  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=298991

Unfortunately FreeBSD ports is notoriously slow with such things, too, but we try not to make it our problem anymore.


Cheers,
Franco

Keeka is mostly correct, although the subject is a bit muddy for historic reasons. The "associated" rule was rendered into config.xml as a separate rule and could change with the edit of the NAT rule it belongs to, but it could not be easily changed on an update in bulk (during a firmware update for example) if it needed an improvement. With "registered" rules the code to generate the rule can be adjusted to modify it later if needed. In that sense it's no longer a config.xml bound rule and more of an automatic rule. Visibility wise both approaches are the same nowadays, but in the past the rule render into config.xml was likely preferred because there was no visibility for automatic rules around.


Cheers,
Franco

Someone from the community worked bit on miniupnpd fixes, but in the grand scheme of things it's not a very fast moving project and if they are not aware of the issue it's very unlikely to be fixed ever.

https://github.com/miniupnp/miniupnp/issues


Cheers,
Franco