That's a filesystem error.

Backtrace:

db:0:kdb.enter.default> bt Tracing pid 17 tid 100143 td 0xfffffe00513cc1e0 kdb_enter() at kdb_enter+0x32/frame 0xfffffe005187ca60 vpanic() at vpanic+0x163/frame 0xfffffe005187cb90 panic() at panic+0x43/frame 0xfffffe005187cbf0 ffs_blkfree_cg() at ffs_blkfree_cg+0x67b/frame 0xfffffe005187cca0 ffs_blkfree() at ffs_blkfree+0xa9/frame 0xfffffe005187cd00 freework_freeblock() at freework_freeblock+0x62d/frame 0xfffffe005187cd80 handle_workitem_freeblocks() at handle_workitem_freeblocks+0x168/frame 0xfffffe005187cde0 process_worklist_item() at process_worklist_item+0x24c/frame 0xfffffe005187ce60 softdep_process_worklist() at softdep_process_worklist+0xed/frame 0xfffffe005187ceb0 softdep_flush() at softdep_flush+0x11f/frame 0xfffffe005187cef0 fork_exit() at fork_exit+0x7f/frame 0xfffffe005187cf30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe005187cf30 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---

The first thing to do here is run a manual filesystem check:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/filesystem-check.html#manual-filesystem-check

@stephenw10
okay - thanks. I've updated the default gateway to be a new gateway group that prioritizes cable over cell phone but has the cell phone in tier 2. I'll see what that does the next time the cable connection fails.

Thanks for all the help!

So in the real setup the firewall would be at the client or in the 5G network?

@viragomann yes, thank you. assign separately .

@johnpoz Well Just figured it out. It was UNRAID SERVER Problem ..

So for people using UNRAID and having pfsense in VM and sharing a folder. PFSENSE has nothing to do with it you need to configure your unraid and then map your address where the sharing folder exists.

For instance in windows I had to map the drive for example: \200.200.1.30 (unraid server addy) (this is not my real address but you get the picture) and boom you get access to that folder you wanted to share. OMG 5 hrs later found easy solution but thanks for clearin up the pfblocker has nothing to do with it..

@stephenw10

It seems that it doesn't work. Probably I would have to cancel my contract.

@dennypage I tracked the issue down to Sony TV having a shitty AirPlay implementation. I have another LG branded TV which works with no issue.

You might be able to use the ix0/1 SFP ports with an appropriate module. Otherwise using an expansion card.

@dr21 said in PFsense Router Slow Web Interface Response - "swap_pager: indefinite wait buffer" Error in Logs:

I'm running PFsense version 2.7.2 on a mini PC with an Intel Core i3-7020U and 8GB of RAM. The dashboard widgets show 16% RAM usage and 3% SWAP usage, and these values remain stable. I also don’t have any additional packages installed.

With no extra packages installed, then I agree with others here who suspect a faulty disk. Odd that you are using any swap space, though. Typically that should show 0% swap usage.

There have been a number of updates in the monthly newsletter and also in the development section here.

But essentially, yes, the addition of significant new functionality required more time over the usual release schedule.

Can you ping that IP?

It feels like a server block on your public IP TBH.

@phoenixz2

You want to write your own script ?

Have a look at this file, the last lines : /etc/inc/notices.inc

So you can use

notify_via_telegram($msg);

in your own scripts (this is PHP btw) if you have set up Telegram.

Quite old but also still relevant as it hasnt changed from the cloud providers pint of view and the thread is misleading from a modern context.

The above thread has a misconception of routable vs link local. Routable means that the ip block is propagated via routing protocols or made reachable via the router itself to anything connected to it. ie a client on a lan segment being able to reach a 169.254.0.0/16 address via the router not its own broadcast discovery over its local interface/

This is not the same as having a 169.254.0.0 /30 subnet on a vti interface. Only the two routers in the tunnel could see these addresses so it is therefore arguably compatible with rfc3927 as it is entirely on link. After all a vti interface is just a NIC, its just a virtual one over a tunnel vs a physical one.

More still it is a better address space to use than the CGNAT netblocks as these can still clash on internal networks especially when multiple organizations are at play, where as rfc3927 addresses could not clash unless the same address spaces were used on the same router. This would obviously be trivial to fix and totally preventable

@SteveITS If hardcoded DNS is giving you issues needing more than expected/desired to be whitelisted, it may be worth checking out this blog on Labzilla. It was wrote with Pihole in mind alongside pfSense, so the term Pihole can be replaced with pfBlockerNG to make more sense. The trick for hardcoded is making DNS replies answer back looking like the answers come from the intended/hardcoded DNS server and not coming from an unknown source/pfSense/Pihole, using the few NAT rules described in the Labzilla blog goes another couple steps further than what Netgates documentation has for just redirecting DNS, these additional NAT rules will mask where DNS replies are answered back from:

administrator@desktop:~$ nslookup www.google.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Name: www.google.com Address: 10.10.10.69

@jrey Yes, thanks a lot.

@stephenw10

This is the only thing i see prior

Oct 11 20:16:00 nyc-fw1-inet sshguard[69504]: Exiting on signal. Oct 11 20:16:00 nyc-fw1-inet sshguard[77474]: Now monitoring attacks. Oct 11 20:35:30 nyc-fw1-inet check_reload_status[666]: Linkup starting $e6000sw0port3 Oct 11 20:35:30 nyc-fw1-inet kernel: e6000sw0port3: link state changed to DOWN Oct 11 20:35:31 nyc-fw1-inet php-fpm[20159]: /rc.linkup: Hotplug event detected for WAN(wan) dynamic IP address (4: dhcp) Oct 11 20:35:31 nyc-fw1-inet php-fpm[20159]: /rc.linkup: DEVD Ethernet detached event for wan Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down

I do see that the LAN side had a Hotplug event as well. Looking at the timestamps the LAN side event happened more or less at the same time as the WAN side.
To me this indicates either

As part of any link-status event, pfSense restarts the internal switch ports There was some weird failure on both LAN and WAN side which i honestly don't see happening. Other cause not yet known. ][admin@nyc-fw1-inet.moore.lan]/var/log: cat system.log | grep "Hotplug" Oct 11 20:35:31 nyc-fw1-inet php-fpm[20159]: /rc.linkup: Hotplug event detected for WAN(wan) dynamic IP address (4: dhcp) Oct 11 20:35:38 nyc-fw1-inet php-fpm[55571]: /rc.linkup: Hotplug event detected for LAN(lan) dynamic IP address (4: 192.168.70.254, 6: track6) Oct 11 20:35:39 nyc-fw1-inet php-fpm[17116]: /rc.linkup: Hotplug event detected for WAN(wan) dynamic IP address (4: dhcp) Oct 11 20:35:54 nyc-fw1-inet php-fpm[20159]: /rc.linkup: Hotplug event detected for LAN(lan) dynamic IP address (4: 192.168.70.254, 6: track6)

@frodet You don’t need to reinstall to revert the configuration, it’s on the Diagnostics menu somewhere.

Re: not save, there’s a path through interface reassignment where if you don’t click Save before you click Apply it doesn’t save…not sure if that applies here.

@Diggy then it’s out of beta apparently…!

https://docs.netgate.com/pfsense/en/latest/install/netinstaller.html

Yes you can certainly separate the ports by VLANs on the 2100. So you can have all traffic from the TP-Link on one interface and all other traffic on a different interface. You just can't separate wired and wireless traffic from the TP-Link or wireless traffic on different SSIDs unless it specifically supports that.