@stephenw10 yeah. It's a FreeBSD issue. Amdtemp only supports families up to 17h. The 5700G is 19h.

ECC RAM is a nice to have thing and or but for a 24/7 running device it makes sense. The TPM module I am using in the PC Engines APU6B4 I was able to buy one from Dasharo, I was soldering a 10 Pin header on the bard and then I connect the TPM module there, together with the latest BIOS version (19.01) the BIOS recognizes the TPM module but pfSense itselfs is not taking any advantage of the TPM module. Perhaps with the next BIOS it could be something is on change at this point.

@stephenw10 Hi Stephen, Just to say after so much trouble with this, I learnt that a work colleague of mine had the FS BOX which I just borrowed to recode the SFPs to Intel. As soon as I had done that and plugged them in, they came to life immediately without any need for tunables or other tweaks to get the link working. It's working on autoselect / autodetect with a fresh install of pfSense. Thank you so much for helping me out with this, but I hope this thread is of use to others: any recent FreeBSD install or security appliance designed on top of FreeBSD using Intel SFPs, you really need Intel-coded SFPs otherwise it just won't work!

@coxhaus Only floating rules have a direction. WAN/LAN/etc are only for inbound packets on that interface. Unbound can forward, but if you do that uncheck the DNSSEC option which is on by default.

Yes, I only found one system here that reports that sysctl. And it probably shouldn't!

On most of those devices (except the 1100) the LEDs are closest to the PCB. In the 6100 and 8200 (and 4100) the PCB is above the ports to allow for a larger heatsink below it.

Well still no but I don't think that's that's same thing. They appear to be available only for Cortex-M CPUs and it's not clear to me if they can be updated after build.

Hmm, so it only fails to reconnect when coming out of standby? The system could be holding the NIC powered to allow WoL etc. There may be some BIOS settings to disable that.

@stephenw10 Ahhh. I didn't realize this was solved. Thought OP was still having issues.

OK, turns out I couldn't ping because my ISP had to provision my router. I had to go through port by port until they could finally see my MAC address. Turns out port 6 is igb1. What a huge pain in the neck... Anyway, now I can ping. Next, I just left the ethernet cable from my PC in one port and just changed the interface assignment for the LAN port until I found the assignment that lets me access the web gui. So port 7 is igb2 and I can access the web gui using a static IP - but I can also pull an IP via DHCP. I guess I'll repeat that until I've mapped all the ports. Thanks for the help, everyone!

Not on Netgate hardware, pfSense Plus is included.

@Finger79 And a big thanks from me who forgot to put JPME2 back again after flashing with the same results…

Is that actually the same server you're testing against? The ping time looks different. The default queue doesn't seem to present any restriction from what information you have given us. It wouldn't affect downloads at all since the only queue it can hit is outbound on the WAN. So you should be seeing much better than that from the firewall itself.

Right because it now is the default so you don't need to set it. You can try setting it to something different as a test if you want but I don't believe it will make any difference.

@Gertjan hi! I don't have any these packages installed. I have many open-vpn site-to-site and ipsec site-to-site connections (50) . Outputs: systat -iostat systat -iostat /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average || /0% /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 cpu user| nice| system| interrupt|X idle|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX /0% /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 ada0 MB/s tps|XXXXXXX da0 MB/s tps| da1 MB/s tps| da2 MB/s tps| da3 MB/s tps| pass0 MB/s tps| pass1 MB/s tps| pass2 MB/s tps| pass3 MB/s tps| pass4 MB/s tps| pass5 MB/s tps| iostat -c 10 tty ada0 da0 da1 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 0 11.0 12 0.1 0.0 0 0.0 0.0 0 0.0 2 0 2 3 93 0 234 0.0 0 0.0 0.0 0 0.0 0.0 0 0.0 1 0 0 3 96 0 78 0.0 0 0.0 0.0 0 0.0 0.0 0 0.0 2 0 1 3 94 0 78 0.0 0 0.0 0.0 0 0.0 0.0 0 0.0 1 0 1 2 96 0 78 15.2 66 1.0 0.0 0 0.0 0.0 0 0.0 2 0 0 2 95 0 78 0.0 0 0.0 0.0 0 0.0 0.0 0 0.0 2 0 0 3 94 0 78 0.0 0 0.0 0.0 0 0.0 0.0 0 0.0 1 0 1 2 96 0 78 0.0 0 0.0 0.0 0 0.0 0.0 0 0.0 1 0 1 4 94 0 78 0.0 0 0.0 0.0 0 0.0 0.0 0 0.0 1 0 1 4 94 0 78 10.8 55 0.6 0.0 0 0.0 0.0 0 0.0 2 0 2 5 92

@DaddyGo, actually instead of using a custom made cable for 12V supply out of PWS-203-1H psu, one can use the connected 8 pin 12v line into the 4 pin onboard connector, keeping the yellow lines at the left. One just need to use the bottom four pins of the connector. To insert the cable align the pins of the connector to pin 1 and 3 side of onboard header and just push till the point it goes in. It will not go till the bottom due to obstruction from adjacent USB header but a stable connection can be achived. Now just the PS_On of the ATX connector to be grounded using a jumper for continous 12v supply. This is also done on the custom connector as shown by you.

Yes it's a harmless notice. It's not something we would address directly. If it gets fixed upstream in FreeBSD we will pull that in. The 4200 shows the same thing: uart2: <16750 or compatible> iomem 0xfe03e000-0xfe03e007 irq 16 on acpi0 ns8250: UART FCR is broken uart2: console (115200,n,8,1) It doesn't affect the console. Steve

@Dobby_ Yeah I just have 200mbit WAN, but pfsense runs behind another router, so that won't even be a problem, it's more the lan side where 2.5 gb will become handy later.

@sarrasine Pretty sure they offer a free trial so you can try it out. App also does SSH, Telnet and probably a few other protocols.