Then I wouldn't worry about it.

@dutsnekcirf said in eMMC appears to have failed after only 5-6 months of use.:

I've suggested that she purchase an 1100 series router as a replacement

The 1100 also has eMMC memory and therefore the same issue can occur.

Install the SATA SSD only after your check with Netgate support if you still got warranty.

Mentioned in the Netgate doc: Optional M.2 SATA Installation:

"The 42mm standoff cannot be moved without disconnecting the thermal paste between the processor and the heat sink. This is not supported and may void the warranty."

@stephenw10
Interesting indeed:
pfSense can notify us: of expiring Certs, and after a reboot, but apparently not much more.
Packages like arpwatch, nut, add notifications for ARP changes and UPS status.
I just had a system with a failing disk send me an email about the reboot we performed, all the while it was logging fatal disk errors.
Not only should pfSense be aware of syslog severity, we should be able to get notifications for crit, alert, emerg level entries so long as notification is still functioning.
In response to above incident, I've been researching options:

remote syslog: every entry cleartext to an Internet host: nope smartd: so close: smartmontools already installed, but cannot run the smartd daemon. (only covers disk errors) zabbix-agent: package is not current. Zabbix svr on Internet: nope.

Could probably accept the risk of cleartext remote syslog, if we could also filter Remote Syslog Contents by severity, in which case virtually nothing would be sent until there is a serious problem.

May 2 14:40:07 kernel (ada0:ahcich1:0:0:0): RES: 71 04 00 00 00 40 00 00 00 00 00 May 2 14:40:07 kernel (ada0:ahcich1:0:0:0): ATA status: 71 (DRDY DF SERV ERR), error: 04 (ABRT ) May 2 14:40:07 kernel (ada0:ahcich1:0:0:0): CAM status: ATA Status Error May 2 14:40:07 kernel (ada0:ahcich1:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00 May 2 14:40:07 kernel (ada0:ahcich1:0:0:0): Retrying command, 0 more tries remain May 2 14:40:07 kernel (ada0:ahcich1:0:0:0): RES: 71 04 00 00 00 40 00 00 00 00 00 May 2 14:40:07 kernel (ada0:ahcich1:0:0:0): ATA status: 71 (DRDY DF SERV ERR), error: 04 (ABRT ) May 2 14:40:07 kernel (ada0:ahcich1:0:0:0): CAM status: ATA Status Error May 2 14:40:07 kernel (ada0:ahcich1:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00 May 2 14:40:07 kernel (ada0:ahcich1:0:0:0): Error 5, Retries exhausted

24.11 does compared with 2.7.2. But 2.8-beta is built on the same base as 25.03-beta.

https://docs.netgate.com/pfsense/en/latest/releases/versions.html

However I'd expect an X550 NIC to work fine in any of those.

@Djkáťo said in Can't change LAN IPv4, "Switch port is already in used by another interface":

can shorten to 10.0.0.3 to 10.3 for pings

I pointed this out elsewhere and was pointed to:
https://superuser.com/questions/486788/why-does-pinging-192-168-072-only-2-dots-return-a-response-from-192-168-0-58

"For example, you can ping google.com in the following ways:
google.com (domain name)
74.125.226.4 (dotted decimal)
1249763844 (flat decimal)
0112.0175.0342.0004 (dotted octal)
011237361004 (flat octal)
0x4A.0x7D.0xE2.0x04 (dotted hex)
0x4A7DE204 (flat hex)
74.0175.0xe2.4 (ಠ_ಠ) "

(the IP doesn't answer anymore, but it does try)

That's still in warranty, you should open a ticket: https://www.netgate.com/tac-support-request

@Patch said in What happens when the state table is full? <Solved>:

I'm not convinced crippling pfsense to a similar degree to your second router would help performance

I did not do it for performance, I did it to stop crashing the ATT router.

Removing the thing is great, slightly improved my latency as a bonus. I am super happy it worked in the 7100 with no problems.

@stephenw10 said in Modify Intel X540-T2 NIC To Work At 2.5GbE ?:

Yes, when you set it to autoselect it will try to negotiate a link with the other side but will advertise only 10G so it can't try to connect at any other speed.

It may still flap since it still runs negotiation. But many newer NICs/drivers actually require that to work correctly.

Thanks. I gave that a go, had to reboot for it work but autoselect now works :) However does not seem to be as reliable as just setting WAN to 10g manually. If I save a setting that causes WAN to restart, it will flop about again. I was not getting that when manually forcing 10g.

I will go back to manually setting it. Manually setting the link speed persisted through reboots anyway.

@netblues ......well it got to 24days and a bit I think...
and then:- ( see log below )
Now 24 days is a 'recent record' for me,.. but I will probably give the Draytek,.. in modem mode a whizz now... and see how that fairs...

May 9 14:20:00 sshguard 86378 Now monitoring attacks. May 9 14:20:00 sshguard 75904 Exiting on signal. May 9 14:19:14 php_pfb 73267 [pfBlockerNG] filterlog daemon started May 9 14:19:14 php 72417 [pfBlockerNG] DNSBL parser daemon started May 9 14:19:13 vnstatd 66864 Monitoring (11): pppoe0 (1000 Mbit) pfsync0 (1000 Mbit) pflog0 (1000 Mbit) igb3.30 (1000 Mbit) igb3.20 (1000 Mbit) igb3.10 (1000 Mbit) igb3 (1000 Mbit) igb2 (10 Mbit) igb1 (1000 Mbit) igb0 (1000 Mbit) enc0 (1000 Mbit) May 9 14:19:13 vnstatd 66864 Data retention: 48 5MinuteHours, 4 HourlyDays, 62 DailyDays, 25 MonthlyMonths, -1 YearlyYears, 20 TopDayEntries May 9 14:19:13 vnstatd 66864 vnStat daemon 2.11 (pid:66864 uid:0 gid:0, SQLite 3.43.1) May 9 14:19:13 tail_pfb 71755 [pfBlockerNG] Firewall Filter Service started May 9 14:19:13 vnstatd 70720 Error: pidfile "/var/run/vnstat/vnstat.pid" lock failed (Resource temporarily unavailable), exiting. May 9 14:19:13 lighttpd_pfb 69222 [pfBlockerNG] DNSBL Webserver started May 9 14:19:13 php_pfb 66824 [pfBlockerNG] filterlog daemon stopped May 9 14:19:13 tail_pfb 65555 [pfBlockerNG] Firewall Filter Service stopped May 9 14:19:13 lighttpd_pfb 65452 [pfBlockerNG] DNSBL Webserver stopped May 9 14:19:13 vnstatd 71246 SIGTERM received, exiting. May 9 14:19:03 vnstatd 48329 Error: pidfile "/var/run/vnstat/vnstat.pid" lock failed (Resource temporarily unavailable), exiting. May 9 14:19:03 bandwidthd 48054 Packet Encoding: Ethernet May 9 14:19:03 bandwidthd 48297 Packet Encoding: Ethernet May 9 14:19:03 bandwidthd 47899 Packet Encoding: Ethernet May 9 14:19:03 bandwidthd 48297 Opening igb1 May 9 14:19:03 bandwidthd 48232 Packet Encoding: Ethernet May 9 14:19:03 bandwidthd 48054 Opening igb1 May 9 14:19:03 bandwidthd 47899 Opening igb1 May 9 14:19:03 bandwidthd 48232 Opening igb1 May 9 14:19:03 bandwidthd 47044 Packet Encoding: Ethernet May 9 14:19:03 bandwidthd 47044 Opening igb1 May 9 14:19:03 bandwidthd 47391 Packet Encoding: Ethernet May 9 14:19:03 bandwidthd 47039 Packet Encoding: Ethernet May 9 14:19:03 bandwidthd 47039 Opening igb1 May 9 14:19:03 bandwidthd 46692 Packet Encoding: Ethernet May 9 14:19:03 bandwidthd 47391 Opening igb1 May 9 14:19:03 bandwidthd 46692 Opening igb1 May 9 14:19:03 bandwidthd 45743 Monitoring subnet 192.168.3.0 with netmask 255.255.255.0 May 9 14:19:03 bandwidthd 45500 Monitoring subnet 192.168.3.0 with netmask 255.255.255.0 May 9 14:19:03 php-fpm 30317 /rc.start_packages: The command '/usr/local/etc/rc.d/bandwidthd.sh stop' returned exit code '1', the output was 'killall: warning: kill -TERM 35725: No such process killall: warning: kill -TERM 35150: No such process killall: warning: kill -TERM 36240: No such process killall: warning: kill -TERM 35923: No such process' May 9 14:19:01 php-fpm 30317 /rc.start_packages: Restarting/Starting all packages. May 9 14:19:00 check_reload_status 430 Reloading filter May 9 14:19:00 check_reload_status 430 Starting packages May 9 14:19:00 php-fpm 7306 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 109.145.193.45 -> 109.145.193.45 - Restarting packages. May 9 14:18:59 php-fpm 33256 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. 'LAN1_DHCP6' May 9 14:18:59 php-fpm 33256 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. '1_WAN_PPPOE' May 9 14:18:58 php-fpm 7306 /rc.newwanip: Creating rrd update script May 9 14:18:58 php-fpm 7306 /rc.newwanip: Resyncing OpenVPN instances for interface 1_WAN. May 9 14:18:58 php-fpm 7306 /rc.newwanip: Gateway, none 'available' for inet6, use the first one configured. 'LAN1_DHCP6' May 9 14:18:58 check_reload_status 430 Reloading filter May 9 14:18:58 check_reload_status 430 Restarting OpenVPN tunnels/interfaces May 9 14:18:58 check_reload_status 430 Restarting IPsec tunnels May 9 14:18:58 check_reload_status 430 updating dyndns 1_WAN_PPPOE May 9 14:18:58 rc.gateway_alarm 46924 >>> Gateway alarm: 1_WAN_PPPOE (Addr:172.16.12.102 Alarm:1 RTT:0ms RTTsd:0ms Loss:100%) May 9 14:18:58 php-fpm 7306 /rc.newwanip: Default gateway setting Interface 1_WAN_PPPOE Gateway as default. May 9 14:18:58 php-fpm 7306 /rc.newwanip: Gateway, none 'available' for inet, use the first one configured. '1_WAN_PPPOE' May 9 14:18:53 php-fpm 7306 /rc.newwanip: rc.newwanip: on (IP address: 109.145.193.45) (interface: 1_WAN[wan]) (real interface: pppoe0). May 9 14:18:53 php-fpm 7306 /rc.newwanip: rc.newwanip: Info: starting on pppoe0. May 9 14:18:52 check_reload_status 430 rc.newwanip starting pppoe0 May 9 14:18:51 check_reload_status 430 Rewriting resolv.conf May 9 14:18:50 ppp 72354 [wan] IPCP: LayerUp May 9 14:18:50 ppp 72354 [wan] IPCP: state change Ack-Sent --> Opened May 9 14:18:50 ppp 72354 [wan] IPCP: rec'd Configure Ack #7 (Ack-Sent) May 9 14:18:50 ppp 72354 [wan] IPCP: SendConfigReq #7 May 9 14:18:50 ppp 72354 [wan] IPCP: rec'd Configure Nak #6 (Ack-Sent) May 9 14:18:50 ppp 72354 [wan] IPCP: SendConfigReq #6 May 9 14:18:50 ppp 72354 [wan] IPCP: rec'd Configure Reject #5 (Ack-Sent) May 9 14:18:50 ppp 72354 [wan] IPCP: state change Req-Sent --> Ack-Sent May 9 14:18:50 ppp 72354 [wan] IPCP: SendConfigAck #71 May 9 14:18:50 ppp 72354 [wan] IPCP: rec'd Configure Request #71 (Req-Sent) May 9 14:18:50 ppp 72354 [wan] IPCP: SendConfigReq #5 May 9 14:18:50 ppp 72354 [wan] IPCP: state change Starting --> Req-Sent May 9 14:18:50 ppp 72354 [wan] IPCP: Up event May 9 14:18:50 ppp 72354 [wan] IPCP: LayerStart May 9 14:18:50 ppp 72354 [wan] IPCP: state change Initial --> Starting May 9 14:18:50 ppp 72354 [wan] IPCP: Open event May 9 14:18:50 ppp 72354 [wan_link0] LCP: authorization successful May 9 14:18:50 ppp 72354 [wan_link0] MESG: CHAP authentication success May 9 14:18:50 ppp 72354 [wan_link0] CHAP: rec'd SUCCESS #1 len: 31 May 9 14:18:50 ppp 72354 [wan_link0] CHAP: sending RESPONSE #1 len: 45 May 9 14:18:50 ppp 72354 [wan_link0] CHAP: Using authname "N014097@hg70.btclick.com" May 9 14:18:50 ppp 72354 [wan_link0] Name: "acc-aln2.tbs" May 9 14:18:50 ppp 72354 [wan_link0] CHAP: rec'd CHALLENGE #1 len: 56 May 9 14:18:50 ppp 72354 [wan_link0] LCP: LayerUp May 9 14:18:50 ppp 72354 [wan_link0] LCP: auth: peer wants CHAP, I want nothing May 9 14:18:50 ppp 72354 [wan_link0] LCP: state change Ack-Rcvd --> Opened May 9 14:18:50 ppp 72354 [wan_link0] LCP: SendConfigAck #160 May 9 14:18:50 ppp 72354 [wan_link0] LCP: rec'd Configure Request #160 (Ack-Rcvd) May 9 14:18:50 ppp 72354 [wan_link0] LCP: state change Req-Sent --> Ack-Rcvd May 9 14:18:50 ppp 72354 [wan_link0] LCP: rec'd Configure Ack #7 (Req-Sent) May 9 14:18:50 ppp 72354 [wan_link0] LCP: SendConfigReq #7 May 9 14:18:50 ppp 72354 [wan_link0] LCP: rec'd Configure Reject #6 (Req-Sent) May 9 14:18:50 ppp 72354 [wan_link0] LCP: SendConfigReq #6 May 9 14:18:47 ppp 72354 [wan_link0] LCP: SendConfigReq #5 May 9 14:18:47 ppp 72354 [wan_link0] LCP: state change Starting --> Req-Sent May 9 14:18:47 ppp 72354 [wan_link0] LCP: Up event May 9 14:18:47 ppp 72354 [wan_link0] PPPoE: connection successful May 9 14:18:47 ppp 72354 PPPoE: rec'd ACNAME "acc-aln2.tbs" May 9 14:18:45 ppp 72354 [wan_link0] PPPoE: Connecting to '' May 9 14:18:42 ppp 72354 [wan_link0] LCP: LayerStart May 9 14:18:42 ppp 72354 [wan_link0] LCP: state change Stopped --> Starting May 9 14:18:42 ppp 72354 [wan_link0] LCP: Down event May 9 14:18:42 ppp 72354 [wan_link0] PPPoE: connection closed May 9 14:18:42 ppp 72354 [wan_link0] LCP: LayerFinish May 9 14:18:42 ppp 72354 [wan_link0] LCP: state change Stopping --> Stopped May 9 14:18:40 ppp 72354 [wan_link0] LCP: SendTerminateReq #4 May 9 14:18:38 ppp 72354 [wan_link0] LCP: LayerDown May 9 14:18:38 ppp 72354 [wan_link0] LCP: SendTerminateReq #3 May 9 14:18:38 ppp 72354 [wan] IPCP: state change Closing --> Initial May 9 14:18:38 ppp 72354 [wan] IPCP: LayerFinish May 9 14:18:38 ppp 72354 [wan] IPCP: Down event May 9 14:18:38 ppp 72354 [wan] IFACE: Removing IPv4 address from pppoe0 failed(IGNORING for now. This should be only for PPPoE friendly!): Can't assign requested address May 9 14:18:38 check_reload_status 430 Rewriting resolv.conf May 9 14:18:37 ppp 72354 [wan] IPCP: LayerDown May 9 14:18:37 ppp 72354 [wan] IPCP: SendTerminateReq #4 May 9 14:18:37 ppp 72354 [wan] IPCP: state change Opened --> Closing May 9 14:18:37 ppp 72354 [wan] IPCP: Close event May 9 14:18:37 ppp 72354 [wan_link0] LCP: state change Opened --> Stopping May 9 14:18:37 ppp 72354 [wan_link0] LCP: peer not responding to echo requests May 9 14:18:37 ppp 72354 [wan_link0] LCP: no reply to 5 echo request(s) May 9 14:18:17 ppp 72354 [wan_link0] LCP: no reply to 4 echo request(s) May 9 14:17:57 ppp 72354 [wan_link0] LCP: no reply to 3 echo request(s) May 9 14:17:37 ppp 72354 [wan_link0] LCP: no reply to 2 echo request(s) May 9 14:17:17 ppp 72354 [wan_link0] LCP: no reply to 1 echo request(s) May 9 14:15:11 php 24200 [pfBlockerNG] No changes to Firewall rules, skipping Filter Reload May 9 14:15:00 php 24200 [pfBlockerNG] Starting cron process.

@stephenw10
I've now been able to test 2.8.0-BETA
(build date Mon Apr 28 1:42:00 CEST 2025)

For now, this seems to have fixed the issue.

New Screenshot

The dotted line is the installation of 2.8.0.

1 - Data from the original post.
2- Data after uninstalling plugins
3 - 2.8.0 Beta

The different form of spikes comes from the pfBlocker update. There is a new cron job at 3pm fetching some data.

Well if anything changed there it's probably something low level that the OS updates could have addressed.

@stephenw10 thanks, I think I figured it out. I assigned a new interface, kept the default name of OPT3. I had to enable it though, when disabling I lost WAN immediately. I left the IP type as none and hard-coded the speed to 2500base-T. I guess I need to just wait another day or two and see what happens.

It should ask you to reassign the NICs before it reboots in the GUI.

But of you have laggs and VLANs I would just edit them in the config before restoring it.

@stephenw10

internet -- isp device - 10.100.102.0/24 -- .111 pfsense --- 192.168.1.0/24

That's what I think he means to say.

@Stef_R Can't help as I do not do VLAN and have avoided their deployment. I have so far found no good use for them.

Ted

I think I have now received enough cautionary feedback to convince me that it was an ill-conceived proposition. I will abandon the “shared” IP plan and follow better, if not good, practice. I like the alias suggestion and that will overcome my reservations about “redundancy” in rules. Thanks to all for your heads up.

I finally solved this problem - so thought I'd update this topic just in case it helps someone else !

The unstable WAN MTU problem persisted through a number of pfSense upgrades, and was still an issue on version 2.7.2-RELEASE.

The thing that fixed it was to install the Realtek drivers using -

pkg install -y realtek-re-kmod

which installed -

realtek-re-kmod-198.00_3 Kernel driver for Realtek PCIe Ethernet Controllers

and then setting the WAN MTU to 1508 (including +8 bytes for PPP overhead).

After a day of experimenting, the system seems stable, and the WAN interface MTU is 1500

It could just be the modem crapping out, yes.

Can you try a different port at the pfSense end?

Can you test putting a switch in between the pfSense WAN and the modem? That would prove which end is dropping the link.