Ad Schellevis

not sure, but it's always possible to open a PR for review. Personally, I'm not a fan of the automatic rules at all, but also understand translations can be difficult...

Unfortunately this is unlikely to mature as it will need a lot of time from our end to bring this to the finish line. In order to include an api...

> .. Could you please take a look in this PR? The "Assignment" UI is already in place,... It's not as there's no user interface using the exact same endpoints...

you can add `ice_ddp_load` to the tunables, `ice_load` shouldn't be needed if I'm not mistaken as the module is loaded by default (our default factory default config files only include...

it's an intel driver thing, firmware is only loaded when requested (the driver works without it, but **very** slow)

The block isn't intended to push xml tags, the trust store will be included automatically when properly configured

@kupferk thanks for the writeup, jumbo frames are indeed only limited supported on axgbe at the moment. Durinf most support cases we have seen sofar, customers who wanted to use...

it would be practical to be able to offer validations on mtu sizes, but unfortunately there's no standard defined to account for the maximum a driver supports. The current options...

does the upstream patch fit on our end? The openbsd patch looks nice, but as the reason for a state deny doesn't change, it will mark as pass where in...

just dumping this here for my own understanding, when max states is reached, reason should be set on our end to `PFRES_MAXSTATES` https://github.com/opnsense/src/blob/6e45a8db84e79e9aa730ef3eb3ffcf1b36044d05/sys/netpfil/pf/pf.c#L4852-L4855 But since the rule number `->nr` is...