It might. I can't comment on those devices specifically but many mesh wifi devices only support those features when the main device is in router mode.

@johnpoz said in Analyze / solve "erros in" on interface and "errors out" on vlan: @sysadminfromhell while I personally wouldn't be too concerned with such minor amount of errors - unless there was something actually not working how it should and tracked it down to these sorts of errors. But I would be interested in what you find, etc. Sometimes such little minor things can be fun to track down, but they can also be huge time sucks - hehehe I can not tell you the amount of time I spent trying to figure out why plex will send out ssdp every freaking 10 seconds, when all the things are disabled for why it might or could have use for doing such a thing. Posted over on the plex forums - got back crickets.. Couple of users posted that they noticed it too.. But no solution, in the long run I just ended blocking such traffic at the switch port.. Plex can send them out every 10 seconds, it goes no farther than switch port at the end of its wire... Stupid shit!! hehehe So yeah would be very interested in what you find.. You never know might run into such a thing sometime down the road and what you find could be the solution there.. So good luck! Hope you track it down.. I recall something sim as well, on some cheap smart switch.. It would mark RxBadPkt, and the counter would constantly go up - even though everything was working fine.. It was just a cosmetic error, any packets marked with tags got marked as RxBadPkt, So native untagged wouldn't trigger the stat, but all tags coming in would.. All the vlans actually worked, etc. but they would just increase that counter.. That was a time suck for sure.. Finally just had to let it go ;) So i reduced the errors with disabling flow control completly, now we still jave errors but a lot less then before: Uptime 7 Days 03 Hours 18 Minutes 15 Seconds [image: 1716901787950-4e0aabd5-909a-4b66-8438-342142fbec3e-image.png] So I guess this was one source of the problem even I cannot find all of them this looked at least like a good start even the VLAN Interfaces still have errors out. (a minor few packets)

You would need to reinstall to move from Plus to CE as the versioning sees it as a downgrade.

Add the line: debug.acpi.disabled="thermal" to the file /boot/loader.conf.local That disables the full ACPI thermal system though. My advise would be, just ignore it!

@JKnott Thanks so much for the insight!!

@PnetG To fact check this : @stephenw10 said in PFBlockerng Filtering Issues: pfBlocker-ng by itself does not do anything. do this : [image: 1716823175064-fea78bd9-9465-4d14-96c1-9c9489dafffa-image.png] and Save. The goto pfSense package de install, and remove it. Just for the fun, reboot pfSense. First check : no more issues ? Right ? If wrong, the issue wasn't pfBlockerng, as it isn't there. Now, install pfBlockerng. Just install - do not activate it. ( I can't remember if it is activated by default, though ) But test now again : no issues what so ever, right ? Now, start adding changes, add a feed (one at the time / one per day !) to pfBlockerng. As soon as you have issues, you'll know what to undo : your last step.

@matthewgcampbell I have never experienced a scenario where it passes traffic for a short amount of time then stops, at least not in the context of eapol auth related. It either passes or it doesn't. Then again I've never done any proxy bypasses either, can't really comment on odd behavior as a result. I assume you're following this - https://docs.netgate.com/pfsense/en/latest/recipes/authbridge.html ? You might want to give a try to one of the proxy scripts here - https://github.com/MonkWho/pfatt/tree/master . This is what we used before vlan0 compliant wpa_supplicant and dhclient. Edit, one other idea to try is the old dumb switch bypass method. I can't find a good write up but in essence you connect ethernet from ont and gateway to a dumb switch (preferably not netgear). Wait until the lights on the modem are all green and stop flashing. Disconnect gateway cable while leaving ONT/switch connected. Connect cable from the modem to your pfsense wan port (again, you're not touching the ONT/switch cable). Pfsense should be configured for dhcp on wan. See if you experience the same disconnect issues after x amount of time. If you do, try a release /renew on the wan. If it doesn't pull an ip, try rebooting pfsense only. This whole time, the link between the ONT and switch should remain connect and as far as ONT concerned, remain authenticated.

If that happened I'd expect a bunch of 'xxxx is using my IP address' logs in pfSense. It's possible they have simply been rotated out though.

@michmoor It’s a package bug from a few pfSense versions ago so no real release notes. Anyone who saved (or changed and saved) the default settings is ok. But it was quite confusing. We changed several things but not that one page. Upgrading the package triggers it also as I recall.

Ah, well that's a much better solution. Adding NAT in there is always a workaround. That NAT looks like it should match and be applied though.

https://redmine.pfsense.org/issues/15516

@stephenw10 thanks. Using the rest button worked. Somehow I missed that in the reset instructions. I appreciate the help.

@SteveITS And a simple solution without asking 10 questions in return and being told your doing things wrong. Thanks !

@Cabledude said in SG-1100, outages, no DHCP, 10 days log missing: So do you uncheck this one on your clients' devices? We rarely use DNSBL at a client. I use it at home and it causes enough issues there because my wife works in search so "needs" the add links on her devices. :) My thought is, turn on the logging if we are troubleshooting a problem that needs logging. Otherwise it's a few years of disk writes that no one looks at. (At clients we have a few layers of protection... DNS forwarding, advanced a/v, etc.)

If you add that as a patch in the System Patches package that will be retained in the config and you can just reapply it.

@stephenw10 Thanks, that should be doable for me.

Yup, just looking for confirmation. Though this test setup was hitting it that doesn't mean it's fixed for all cases necessarily. There was a bunch of work went into the gateway/WAN handling in 24.03 though. If we can confirm the fix we know that will work in CE.

Doesn't really matter what you have locally it's what you're connecting to. What is supported at the remote side?

Yes, run a test that's showing limited download speeds. Look at the traffic graphs and check if it's using the VPN.

About Plus specifically? https://docs.netgate.com/pfsense/en/latest/general/plus.html