Hmm, hard to know what would cause this without more data of some sort. Unclear why if_pppoe doesn't disconnect and retry with those logs. But also why that would cause services to bog down since that implies the interface is not bouncing.

To clarify on what's happening with the pending gateway, in your instances IPV6CP negotiation establishes the IPv6 endpoints on the PPP session, and the link local peer address is intended to be the gateway for your DHCPv6 assigned address, with no RAs to nominate a gateway. The interface gateway is correctly set to the address of the peer endpoint by the driver, but the existing LL address on the interface is not updated with the remote destination address, and that destination address is expected to be present in order to identify the PPP gateway when the gateway monitoring setup is triggered. The patch intuits the PPP gateway from the routing table instead of the interface address in the IPv6 case. I'm working on a correction to the driver that should eliminate the need for this special case handling.

@stephenw10 The Ultra Ethernet Consortium

@stephenw10 Aye that's right

Hi guys,
I create simple shell script reports for AbuseIPDB from filter.log file. Maybe it will be helpful to someone.
It was tested over a one-week period and works as expected.
Here is the link: ttps://github.com/whoami-0x44/abuseipdb-reporting-pfsense

Yes you can choose 2.8.0-beta from the installer menu.

Edit: Now 2.8.0-RC

Nope, none of those are a big concern. Some of that could be cleaned up but they are just ugly.

@w0w

Seems so or possibly an interaction with if_pppoe and something else within the new beta.

Regressing to 24.11 again and symptoms vanish. Reverting to the old backend on the beta seems fine too (albeit with the old pppoe issues).

I had to work back again and re-test as I had the test diff patch applied with the revised beta, which drew some doubts on my results for a while. Fat-fingering in a config error when testing is something I try to avoid but you have to admit your mistakes.

I'm waiting for the next beta drop really, to see if the changes also impact the issues I see. Opening up all the cores may just be peeling back something that was already latent and just masked by the old backend process.

I did do a couple of tests that suggests the upload fq_codel settings may need adjusting against a different workload for if_pppoe; but too early to be sure.

I'm also being nudged to try Kea again, as apparently it has matured a bit since its launch.

☕️

Hmm, it does seem kinda shady!

There's no FreeBSD port as far as I can see, though there is one for v2ray which this was forked from.

You are asking about adding it as a client to connect to the xrayvpn service only?

I'm not really seeing any advantages over existing VPN options TBH.

@matthijs

I had an issue with a static arp entry, but it was a wrong configuration on my side (an old wrong static arp entry/Mac address) The IP adres with this static ARP entry was in use by another host (with another MAC address) an that was an issue. I did not experience this in 2.7.2 So in fact 2.8.0 is behaving correctly

@jimp oh cool, it never even occurred to me that ppl would carry around a universal cert

@patient0 Worked! thanks!

The rule order in the configuration file is supposed to reflect both the rule processing and rule position (i.e. what's shown in the GUI) order. Ultimately, the processing itself is determined by what gets put into /tmp/rules.debug. As for the rule position in the GUI, there are multiple factors involved. With the latest fixes (referenced in the thread linked above), what does happen should finally match what is supposed to happen.

@techpro2004 FFS.