The devices / drivers are named after whatever first supports them and they are named that upstream. It would be confusing if we changed that. Hence x86-64 architecture is known as amd64. Steve

diff radvd.conf radvd_ng.conf 59c59 < RDNSS 2620:fe::fe 2620:fe::9 2a00:1098:2c::1 { }; --- > RDNSS 2620:fe::fe 2620:fe::9 2a00:1098:2c::1 2a00:1098:2b::1 { };

It's more of a slush at the moment. We are only committing things there which are regression fixes or fixes for other showstoppers we find when testing. There are still a couple things hanging out there, mostly on our internal Redmine for the hardware we sell. For example there is still an issue we're working on with crypto on the SG-3100.

@skogs It got a shot of pfSense steroid!

@Gertjan yes

The -latest files are a link to whatever the most recent timestamp is. It's a convenience link to get the most recent at that time. I would not use those, as you won't necessarily know from looking at the name if what you downloaded before is the most recent at a later date. So while it may be true that the ones you asked about were the same when you looked at that moment, that would not necessarily be true by the time someone else looked.

Extended offline Completed without error shrug i apologize i posted this under Dev. but this truely happened after a 2.4.5 dev update appreciate your teams work on Pfsense

Follow the output [2.4.5-RC][root@pfSense.local.lan]/root: ping raspsrv.local.lan ping: cannot resolve raspsrv.local.lan: Unknown host [2.4.5-RC][root@pfSense.local.lan]/root: ping 192.168.255.251 PING 192.168.255.251 (192.168.255.251): 56 data bytes 64 bytes from 192.168.255.251: icmp_seq=0 ttl=64 time=0.623 ms ^C --- 192.168.255.251 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.623/0.623/0.623/0.000 ms [2.4.5-RC][root@pfSense.local.lan]/root: host -v raspsrv.local.lan. 127.0.0.1 Trying "raspsrv.local.lan" Trying "raspsrv.local.lan.local.lan" Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: Host raspsrv.local.lan not found: 3(NXDOMAIN) Received 120 bytes from 127.0.0.1#53 in 0 ms [2.4.5-RC][root@pfSense.local.lan]/root: drill raspsrv.local.lan. @127.0.0.1 ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 36661 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;; raspsrv.local.lan. IN A ;; ANSWER SECTION: ;; AUTHORITY SECTION: . 3463 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020013003 1800 900 604800 86400 ;; ADDITIONAL SECTION: ;; Query time: 0 msec ;; SERVER: 127.0.0.1 ;; WHEN: Thu Jan 30 17:14:01 2020 ;; MSG SIZE rcvd: 110 [image: 1580415310424-7146798c-fc58-421a-be6b-ac7dc398ef8b-image.png]

There is no individual changelog between snapshots. You'd have to look at the commit logs for each repo on that branch. Otherwise the closest you'd find is looking at Redmine to see what issues were updated during that timeframe.

@ErnestoRey perhaps you could use the 'cron' package instead of manually editting the config?

You'll be needing a compatible device with at least two NICs (network interfaces). This could be a VM, this or an ordinary PC. The SG1100 will get to you preloaded with pfSense. Or visit https://www.pfsense.org/download/ and download a copy - and burn it to a USB key. Then as usual, read the notice first https://docs.netgate.com/pfsense/en/latest/install/index.html and do what's explained. Basically, installing pfSense is like installing, for example, Windows 10. The hardware requirement are not the same : you do not need the latest graphics card to run it - just a second internet card (do not choose build-in wifi as a second LAN interface ....).

When I read the notes I wasn't sure what was wrong. I had thought it was just a ruleset issue or something similar. Not a code base change... My bad. Thank you guys for all the work you put into pfSense and FreeBSD. Tyler.

@jimp 2.5.x dev builds. I am in the exact same scenario - using 2.5.x to be able to run AES-GCM and it was working flawlessly for months and months until I updated around Christmas, and then it choked out 2-3 times since, prompting this post. I switched to non-AES-NI on both IKEv2 setups and it is solid for 24hrs plus right now. I will update both machines on Friday and re-instate the AES-NI ike v2 and see how it goes. box 1: 2.5.0-DEVELOPMENT(amd64) built on Fri Jan 03 22:01:28 EST 2020 box 2: 2.5.0-DEVELOPMENT(amd64) built on Fri Jan 03 22:01:28 EST 2020