pfSense Forum

Administrative => Messages from the pfSense Team => Topic started by: gonzopancho on February 25, 2015, 07:36:25 pm

Title: a pfSense roadmap
Post by: gonzopancho on February 25, 2015, 07:36:25 pm
https://blog.pfsense.org/?p=1588
Title: Re: a pfSense roadmap
Post by: NOYB on February 25, 2015, 08:11:33 pm
 
Thanks for sharing with us the road map.  It's nice to know where the chauffeur is taking us.
 
Any mile stone timeline goals, estimates, hopes, wishful thinking, anything?
 
Thanks
 
Title: Re: a pfSense roadmap
Post by: stan-qaz on February 25, 2015, 09:28:47 pm
Seeing all the coming changes is really exciting and I'm looking forward to playing them. I do have a couple questions after reading the blog entry though, about hardware.

What is going to be the minimum levels of hardware to support all the new features?

Are you or Netgate going to be able offer something in the $200.00 range for the low-end market, folks with small networks and not a lot of speed or traffic? The new SG-2440 looks really nice but the price is out of what I can justify for my needs.

I'd really love to move on to the new 3.0 if at all possible at my price point, sounds like a lot more fun than staying with the legacy 2.X releases.
Title: Re: a pfSense roadmap
Post by: phil.davis on February 26, 2015, 12:38:05 am
The PCengines APU is 64 bit, 2GB or 4GB real memory, 3 NICs and in that price range. That provides a suitable base system for me in the low-power-consumption, small office/home office niche and it should run pfSense 3.0 with no problem. And there are other low-end 64-bit systems out there also. With the ARM on FreeBSD things happening, I would guess there will be low-end 64-bit ARM hardware that will also meet the low-end needs.

Roadmap looks good. Separating the GUI presentation code from the input validation from the backend implementation is really needed. Then other bits like pfCenter can have well-defined interfaces to use to make multi-system config changes and get monitoring data...

If Python turns out to be the major selected language for a lot of the code, then thanks for the opportunity to learn another language ;)
What ever happened to good old that some of us know (and loved?) Cobol, Fortran  :-\
Title: Re: a pfSense roadmap
Post by: biggsy on February 26, 2015, 12:57:34 am
COBOL and Fortran in a forum thread and the late, great FZ invoked in a pfSense blog post. 

So now I feel I can post some details of my first computer (https://en.wikipedia.org/wiki/Honeywell_200).

Yeah, Python sounds good as a new language.

Edit by GruensFroeschli: i fixed the link
Title: Re: a pfSense roadmap
Post by: kejianshi on February 26, 2015, 01:06:40 am
I tell people that programming is a never ending game of catchup.  That every single time I have a reason to code something big I have to learn a new language.   Its pretty much true. 
Title: Re: a pfSense roadmap
Post by: NOYB on February 26, 2015, 01:21:03 am
 
I tell people that programming is a never ending game of catchup.  That every single time I have a reason to code something big I have to learn a new language.   Its pretty much true.

Code more "something big's" and then you won't have to learn a new language every single time.  Just every other time.   ;)
 
Title: Re: a pfSense roadmap
Post by: kejianshi on February 26, 2015, 01:39:58 am
Ehhhhhhh.  Sounds like so much work....  haha
Title: Re: a pfSense roadmap
Post by: gonzopancho on February 26, 2015, 01:48:42 am
The PCengines APU is 64 bit, 2GB or 4GB real memory, 3 NICs and in that price range.

But the Realtek NICs are awful.

Be aware that Pascal is on record about engineering a replacement in the short-term. (EOY, I imagine.) The next PC Engines board has a Jaguar (so: AES-NI) 2 or 4 core CPU, 2 or 4GB RAM (ECC on the 4GB model) and (wait for it), Intel NICs (I imagine these will be i217/218 class.)

I took this into consideration for 3.0.

Our low-end strategy is the C2000 Avoton/Rangeley series of SoCs.


Roadmap looks good. Separating the GUI presentation code from the input validation from the backend implementation is really needed. Then other bits like pfCenter can have well-defined interfaces to use to make multi-system config changes and get monitoring data...

If Python turns out to be the major selected language for a lot of the code, then thanks for the opportunity to learn another language ;)
What ever happened to good old that some of us know (and loved?) Cobol, Fortran  :-\

I wrote a lot of Fortran in my youth.
Title: Re: a pfSense roadmap
Post by: gonzopancho on February 26, 2015, 01:49:31 am

Thanks for sharing with us the road map.  It's nice to know where the chauffeur is taking us.
 
Any mile stone timeline goals, estimates, hopes, wishful thinking, anything?
 
Thanks

New hardware in q3.  That's all the hint I'll give.
Title: Re: a pfSense roadmap
Post by: gonzopancho on February 26, 2015, 01:50:27 am
Ehhhhhhh.  Sounds like so much work....  haha

Indeed.
Title: Re: a pfSense roadmap
Post by: kejianshi on February 26, 2015, 02:16:04 am
I might consider it - I have time now.  I used to be pretty good at it, relatively speaking (-;
Title: Re: a pfSense roadmap
Post by: grandrivers on February 26, 2015, 12:32:57 pm
It would be great to see Apinger's issues called out with a action plan sooner vs later as I have provider issues and graphs that are unusable in helping to get these issues fixed
Title: Re: a pfSense roadmap
Post by: Derelict on February 26, 2015, 01:46:05 pm
It would be great to see Apinger's issues called out with a action plan sooner vs later as I have provider issues and graphs that are unusable in helping to get these issues fixed
There's always cacti, etc.  pfSense doesn't have to do everything. (Not that I don't want apinger fixed/replaced, but if it's broken get another tool.)
Title: Re: a pfSense roadmap
Post by: gonzopancho on February 26, 2015, 10:54:39 pm
It would be great to see Apinger's issues called out with a action plan sooner vs later as I have provider issues and graphs that are unusable in helping to get these issues fixed

apinger needs a re-write.  It's garbage code.
Title: Re: a pfSense roadmap
Post by: jits on February 27, 2015, 06:13:02 am
Wow!

There is just something magical reading the project map for 3.0 while feasting on a Cadbury's almonds and raisin chocolate bar.

But...any consideration for the Wireless ISP guys? No MPLS implementation? No MIPS hardware as yet? Can these be options for consideration for small ISP types?
Title: Re: a pfSense roadmap
Post by: Michael Sh. on February 27, 2015, 05:28:03 pm
Fortran IV - holes in punched cards can be seen. And the 6 position is marked usual.  ;)
Python? Programming with spaces? Loss/extra space and the program behaves unpredictably? Forget copy/paste, move pieces of code, and so on?
Great...  :(
Title: Re: a pfSense roadmap
Post by: gonzopancho on February 27, 2015, 11:37:30 pm
Wow!

There is just something magical reading the project map for 3.0 while feasting on a Cadbury's almonds and raisin chocolate bar.

But...any consideration for the Wireless ISP guys? No MPLS implementation? No MIPS hardware as yet? Can these be options for consideration for small ISP types?

Did I say there would not be MPLS, or GRE support?

No, I did not.   It's a path, jtls.

In any case, 2.x is always an option on existing hardware.
Title: Re: a pfSense roadmap
Post by: jimp on March 02, 2015, 12:34:07 pm
Fortran IV - holes in punched cards can be seen. And the 6 position is marked usual.  ;)
Python? Programming with spaces? Loss/extra space and the program behaves unpredictably? Forget copy/paste, move pieces of code, and so on?
Great...  :(

If it forces us to maintain proper style and spacing, it's not a bad thing.
Title: Re: a pfSense roadmap
Post by: gonzopancho on March 02, 2015, 01:11:36 pm
Fortran IV - holes in punched cards can be seen. And the 6 position is marked usual.  ;)
Python? Programming with spaces? Loss/extra space and the program behaves unpredictably? Forget copy/paste, move pieces of code, and so on?
Great...  :(

If it forces us to maintain proper style and spacing, it's not a bad thing.

python is a lot like lisp without the parenthesis.   Once you figure that out, it gets easy.
Title: Re: a pfSense roadmap
Post by: router_wang on March 02, 2015, 01:40:12 pm

The next PC Engines board has a Jaguar (so: AES-NI) 2 or 4 core CPU, 2 or 4GB RAM (ECC on the 4GB model) and (wait for it), Intel NICs (I imagine these will be i217/218 class.)


Intel NIC's? That is awesome, where did you see this?
Title: Re: a pfSense roadmap
Post by: jimp on March 02, 2015, 02:13:15 pm
[...]and the program behaves unpredictably?[...]

Forgot something:

Unpredictable behavior will most likely be caught by the copious amount of unit tests we'll surely be adding during the rewrite.
Title: Re: a pfSense roadmap
Post by: gonzopancho on March 02, 2015, 06:37:57 pm

The next PC Engines board has a Jaguar (so: AES-NI) 2 or 4 core CPU, 2 or 4GB RAM (ECC on the 4GB model) and (wait for it), Intel NICs (I imagine these will be i217/218 class.)


Intel NIC's? That is awesome, where did you see this?

Pascal told Chrs months ago.
Title: Re: a pfSense roadmap
Post by: kejianshi on March 03, 2015, 12:12:29 am
Sounds like nice hardware.  These will work well when its 32C outside, hotter inside and no airconditioning?  (Its a serious question)
Title: Re: a pfSense roadmap
Post by: gonzopancho on March 03, 2015, 02:29:23 am
I don't design the PC Engines boards. 

The RCC-VE & RCC-DF will.
Title: Re: a pfSense roadmap
Post by: dennypage on March 03, 2015, 04:45:26 pm
Totally

apinger needs a re-write.  It's garbage code.
Title: Re: a pfSense roadmap
Post by: grandrivers on March 03, 2015, 07:28:31 pm
rewrite can't happen soon enough dual wan failover is what brought me to Pfsense on my connections it no longer works 
Title: Re: a pfSense roadmap
Post by: Superman on March 04, 2015, 03:46:55 pm
...The next PC Engines board has a Jaguar (so: AES-NI) 2 or 4 core CPU, 2 or 4GB RAM (ECC on the 4GB model) and (wait for it), Intel NICs (I imagine these will be i217/218 class.)

Do we have anywhere we can get more info on this? Sounds like it's worth waiting for before my next upgrade!

Thanks,
Supe
Title: Re: a pfSense roadmap
Post by: EasyNT on March 05, 2015, 04:23:38 am
They expect the new board mid-2015 and it's also expected to deliver full gigabit transport with pfSense... (called 'em and asked).
Title: Re: a pfSense roadmap
Post by: jcyr on March 05, 2015, 06:32:46 pm
Blocks declared using whitespace!!! Gotta be the dumbest idea ever...
Title: Re: a pfSense roadmap
Post by: jimp on March 06, 2015, 09:59:21 am
Blocks declared using whitespace!!! Gotta be the dumbest idea ever...

I'll take that over an unreadable perl script with no whitespace any day of the week. :-)

See above, re: coding style.

Title: Re: a pfSense roadmap
Post by: jimp on March 06, 2015, 10:01:49 am
Also: http://www.secnetix.de/olli/Python/block_indentation.hawk
Title: Re: a pfSense roadmap
Post by: Michael Sh. on March 06, 2015, 01:33:52 pm
Also: http://www.secnetix.de/olli/Python/block_indentation.hawk

Mice were crying, injected, but continued to eat a cactus. ;D

50% of the source code holds significant whitespaces. Tabs canceled because for 20 years and have not decided what to do with them.
Title: Re: a pfSense roadmap
Post by: Michael Sh. on March 06, 2015, 02:20:35 pm
Blocks declared using whitespace!!! Gotta be the dumbest idea ever...

I'll take that over an unreadable perl script with no whitespace any day of the week. :-)

See above, re: coding style.

Well, yes, it is an advantage Perl. Read compressed JS is also impossible, but one press of the button in the editor and we can see the code in your favorite style to us. Just Perl and the vast majority of system programming languages so may, not only C-like, but Python - no. ;)
Title: Re: a pfSense roadmap
Post by: jimp on March 06, 2015, 02:28:19 pm
Because you can't mangle python into an unreadable mess in quite the same way, so it's not necessary. :)
Title: Re: a pfSense roadmap
Post by: Michael Sh. on March 06, 2015, 02:34:08 pm
That's what I watch a lot of programs available in Python byte-compiled code. Suddenly anyone in any wrong editor will open.  :D
Title: Re: a pfSense roadmap
Post by: gonzopancho on March 07, 2015, 10:24:07 pm
Wot?

I design the API in the lift line.

(http://m.imgur.com/iZ4XRN9)
Title: Re: a pfSense roadmap
Post by: fatsailor on March 11, 2015, 08:14:48 am
You've clearly put a great deal of thought into the roadmap, and I'm impressed.The recently announced Intel Xeon SOC will be very interesting with v3.

One thought/suggestion regarding packages- have you thought about enforcing a rule that requires all third party packages to have a separate jail? Freenas does this now, and it improves the security and stability of the platform. It will make creating packages a bit more work, but with COW ZFS you won't waste disk.

(You are migrating to root on ZFS I hope).
Title: Re: a pfSense roadmap
Post by: gonzopancho on March 11, 2015, 07:22:29 pm
You've clearly put a great deal of thought into the roadmap, and I'm impressed.The recently announced Intel Xeon SOC will be very interesting with v3.

One thought/suggestion regarding packages- have you thought about enforcing a rule that requires all third party packages to have a separate jail? Freenas does this now, and it improves the security and stability of the platform. It will make creating packages a bit more work, but with COW ZFS you won't waste disk.

(You are migrating to root on ZFS I hope).

Yes, we knew about Broadwell-DE (the codename for Xeon D), and kept it in-mind while evaluating our options.  We have a future product based on BDE in development.

root on ZFS: perhaps even for embedded.  The issue here is that ZFS eats ram for breakfast, and lower-end systems don't necessarily have same to spare.

We're quite aware of what the guys at iXsystems are doing with FreeNAS and PC-BSD.  First step here is to get to 'pkg(ng)' on pfSense.
Title: Re: a pfSense roadmap
Post by: fatsailor on March 11, 2015, 07:58:28 pm

Yes, we knew about Broadwell-DE (the codename for Xeon D), and kept it in-mind while evaluating our options.  We have a future product based on BDE in development.

root on ZFS: perhaps even for embedded.  The issue here is that ZFS eats ram for breakfast, and lower-end systems don't necessarily have same to spare.

We're quite aware of what the guys at iXsystems are doing with FreeNAS and PC-BSD.  First step here is to get to 'pkg(ng)' on pfSense.

ZFS only really eats RAM when deduplication is used. The COW capability of ZFS combined with Jails is light years ahead of Docker et. al.

I agree that getting pkg working is the first step, and I love that you're getting rid of PHP!
Title: Re: a pfSense roadmap
Post by: riahc3 on March 20, 2015, 02:37:02 pm
I am against the idea of dropping PPTP.

While I agree deprecating it and not supporting it (hell, hide it if necessary), there are a lot of industrial machines that only support PPTP. For example, PLCs come to mind.

I understand the reason and I agree that noone should use PPTP but thats not a reason to remove it. With it disabled and/or not recommended, it does not hurt pfSense. Whoever chooses to enable it, is under his/her own consequences.
Title: Re: a pfSense roadmap
Post by: doktornotor on March 20, 2015, 03:08:04 pm
With it disabled and/or not recommended, it does not hurt pfSense.

I guess you figure the code is self-maintaining. And also will rewrite itself to Python by some magic.
Title: Re: a pfSense roadmap
Post by: kejianshi on March 20, 2015, 05:30:23 pm
"While I agree deprecating it and not supporting it (hell, hide it if necessary), there are a lot of industrial machines that only support PPTP. For example, PLCs come to mind."

I assume these PLCs are sitting behind a router?  Why not let pfsense tunnel all the stuff you used to use PPTP for over a different type of vpn?

I can't imagine a situation (other than being unable to purchase or build a pfsense) where you can't replace PPTP.
Title: Re: a pfSense roadmap
Post by: riahc3 on March 21, 2015, 12:29:22 pm
With it disabled and/or not recommended, it does not hurt pfSense.

I guess you figure the code is self-maintaining. And also will rewrite itself to Python by some magic.
Rewrite the code once to Python and thats it. End of support.

On top of that, don't write whatever the fuck you want; 2.3 is set to drop PPTP. 3.0 is far away from us. The rewrite isnt even taking in though PPTP.

2.3 should be released with PPTP "as-is" and disabling/hiding it unless the user himself decides to enable it. If it drops in 3.0 (whenever that is in the far future), so be it (depending on what timeframe, I would probably be for dropping it).

Title: Re: a pfSense roadmap
Post by: riahc3 on March 21, 2015, 12:31:37 pm
I assume these PLCs are sitting behind a router?  Why not let pfsense tunnel all the stuff you used to use PPTP for over a different type of vpn?
Because old stuff is usually only compatible with PPTP.

I just gave my point of view; I understand that security wise (and technology wise) the choice to drop PPTP, I just dont agree removing it; I think it should be unsupported.
Title: Re: a pfSense roadmap
Post by: doktornotor on March 21, 2015, 12:42:24 pm
With it disabled and/or not recommended, it does not hurt pfSense.

I guess you figure the code is self-maintaining. And also will rewrite itself to Python by some magic.
Rewrite the code once to Python and thats it. End of support.

I assume you volunteer to do the job...  ::)
Title: Re: a pfSense roadmap
Post by: riahc3 on March 21, 2015, 01:16:13 pm
With it disabled and/or not recommended, it does not hurt pfSense.

I guess you figure the code is self-maintaining. And also will rewrite itself to Python by some magic.
Rewrite the code once to Python and thats it. End of support.

I assume you volunteer to do the job...  ::)
You are avoiding the subject.

2.3 is to released soon.
3.0 is to be released in a distant future.

Leave it as-is right now unsupported in 2.3 (PHP), 2.3.1 (PHP), 2.3.2 (PHP), 2.4 (PHP), etc.

THEN when the rewrite in Python comes (3.0) if noone wants to rewrite it in Phyton, then don't. Release the 3.0 release without PPTP.

Do I need to spoonfeed you any further?
Title: Re: a pfSense roadmap
Post by: riahc3 on March 21, 2015, 01:26:50 pm
Also, from what I understood, the team wants to move away from having a pfSense distribution to being a package called pfSense that runs on FreeBSD.

If this is so, technically you would install FreeBSD then install a package called "pfSense" and if you still want to, you can install a package that acts like a PPTP server on FreeBSD. Thats what I understood from the blog post although I might be mistaken.

I think that would be great personally :)
Title: Re: a pfSense roadmap
Post by: doktornotor on March 21, 2015, 01:36:34 pm
Do I need to spoonfeed you any further?

No, thanks. Enough time wasted debating obvious junk that should already have been removed, since it's been utterly broken for years.
Title: Re: a pfSense roadmap
Post by: riahc3 on March 21, 2015, 03:51:22 pm
Do I need to spoonfeed you any further?

No, thanks. Enough time wasted debating obvious junk that should already have been removed, since it's been utterly broken for years.
I just want to go on record saying I personally use SSTP and/or OpenVPN. I do understand certain scenarios (like I listed) where PPTP might come in handy (even as a quick test).
Title: Re: a pfSense roadmap
Post by: gonzopancho on March 25, 2015, 01:07:05 am
Also, from what I understood, the team wants to move away from having a pfSense distribution to being a package called pfSense that runs on FreeBSD.

If this is so, technically you would install FreeBSD then install a package called "pfSense" and if you still want to, you can install a package that acts like a PPTP server on FreeBSD. Thats what I understood from the blog post although I might be mistaken.

I think that would be great personally :)

both will exist, but having pfSense as a package (including 'base') will allow us to update individual components.  I suppose if someone wanted to create a "PPTP package" and add it in, that would still work.
Title: Re: a pfSense roadmap
Post by: apollo13 on July 10, 2015, 09:55:43 am
Are there some public discussions about which web framework to use for pFsense 3, how the api would look like etc… or did nothing happen in that regard yet. Also is there a way to sign up somewhere if one would be interested in helping out on the effort?
Title: Re: a pfSense roadmap
Post by: cmb on July 10, 2015, 07:54:46 pm
Are there some public discussions about which web framework to use for pFsense 3, how the api would look like etc… or did nothing happen in that regard yet. Also is there a way to sign up somewhere if one would be interested in helping out on the effort?

Not yet, right now from a web perspective we're still focused on the Bootstrap work for 2.3. We'll start a thread on the development board here (https://forum.pfsense.org/index.php?board=32.0) when all that gets underway, as well as the dev mailing list (https://lists.pfsense.org/mailman/listinfo/dev). Definitely would appreciate help on that effort when we get to that point!

In the mean time, we welcome contributions to the bootstrap effort (https://github.com/SjonHortensius/pfsense).
Title: Re: a pfSense roadmap
Post by: YipYip on November 01, 2016, 05:57:28 pm
Any ~ ETA on 2.4 as Im pretty keen to get a non corrupting Filesystem
Title: Re: a pfSense roadmap
Post by: jimp on November 01, 2016, 07:12:43 pm
Any ~ ETA on 2.4 as Im pretty keen to get a non corrupting Filesystem

It'll be beta quite soon. Not too much longer now. It's shaping up fast.
Title: Re: a pfSense roadmap
Post by: bimmerdriver on November 06, 2016, 10:18:23 pm
Any ~ ETA on 2.4 as Im pretty keen to get a non corrupting Filesystem

It'll be beta quite soon. Not too much longer now. It's shaping up fast.

Currently the description of the 2.4 development snapshot says:
Quote
HIGHLY-EXPERIMENTAL pfSense 2.4.0 ALPHA developers tree

Are you implying that at some point in the (near?) future the description will say BETA instead of ALPHA? If so, what are the criteria for ALPHA vs. BETA? I'm looking forward to 2.4 being released so I can move away from a tunnel to native ipv6.
Title: Re: a pfSense roadmap
Post by: jimp on November 08, 2016, 08:33:50 am
Yes, beta soon and that page will be updated.
Title: Re: a pfSense roadmap
Post by: bimmerdriver on September 17, 2017, 06:22:57 pm
No doubt the developers are all busy getting 2.4 ready for release, but the original post of this thread is coming up on 3 years old. It would be nice if there was an update to the roadmap.
Title: Re: a pfSense roadmap
Post by: andrewinhawaii on October 04, 2017, 03:57:18 am
OK, I see the new roadmap in the 2.4.0-RC announcement here:

https://www.netgate.com/blog/pfsense-2-4-0-rc-now-available.html

But my concerns right now are the recent Dnsmasq exploits.  So I tried updating, and tried, and tried, until I read the not so fine print:

"32-bit x86 and NanoBSD have been deprecated and are not supported on 2.4."

Well fuuuuu.  I just repurposed a Checkpoint U-20 box, and bought a spare just in case.  Alas, they are Pentium-M based, which means a lousy 32 bit x86 core.  So most embedded hardware can now be tossed in the trash because they have old 32-bit cores?

And how about my security concerns over Dnsmasq?

https://www.netgate.com/blog/no-plan-survives-contact-with-the-internet.html

"Users on pfSense 2.3.x or earlier concerned about these bugs can switch to the DNS Resolver (Unbound) until a new pfSense software release is available."

Will there be a 2.3.4_2 for us poor 32-bit untouchables?

What would it take for us to roll our own 32 bit 2.4 binaries?  I see that FBSD-11.1 is still supported for 32-bit x86.  All of the FreeBSD packages will have precompiled 32 bit binaries, so what else do I need to do to build a 32 bit x85 version of pfSense 2.4+?
Title: Re: a pfSense roadmap
Post by: jimp on October 04, 2017, 06:23:31 am
Read https://www.netgate.com/blog/no-plan-survives-contact-with-the-internet.html closer.

We'll be putting out 2.3.5 after 2.4.0.
Title: Re: a pfSense roadmap
Post by: andrewinhawaii on October 04, 2017, 09:20:37 am
Ooops, that's on me.  I stopped reading when it seemed to be addressing only the 2.4 branch.  Thank you for including plans to update the 2.3 branch.

The question remains going forward: can we come up with a recipe for a 32-bit build of the 2.4 branch when the dust settles?  Sure it won't be supported but sometimes you just gotta deal with it.
Title: Re: a pfSense roadmap
Post by: jimp on October 04, 2017, 09:23:53 am
No, it is not viable. None of the patches have been tested on i386 and it's entirely possible there are required pieces missing (like an i386 kernel config), and who knows what else.

It isn't going to happen, and the time wasted on chasing it down on the off chance it might work would be better spent on non-obsolete hardware.
Title: Re: a pfSense roadmap
Post by: jimp on October 04, 2017, 12:40:54 pm
And how about my security concerns over Dnsmasq?

https://www.netgate.com/blog/no-plan-survives-contact-with-the-internet.html

"Users on pfSense 2.3.x or earlier concerned about these bugs can switch to the DNS Resolver (Unbound) until a new pfSense software release is available."

FYI- As of right now, if you are on 2.3.4-p1 you can fetch an updated dnsmasq

pkg update -y dnsmasq

That should find the update and install it, afterward you have to restart the dnsmasq service
Title: Re: a pfSense roadmap
Post by: andrewinhawaii on October 04, 2017, 05:45:24 pm
Yes, that did the trick:

  pkg upgrade dnsmasq


brought me upto

dnsmasq upgraded: 2.76,1 -> 2.78,1

Thank you.
Title: Re: a pfSense roadmap
Post by: Novalis on October 09, 2017, 03:42:58 am
Quote
And how about my security concerns over Dnsmasq?[/size]
https://www.netgate.com/blog/no-plan-survives-contact-with-the-internet.html
"Users on pfSense 2.3.x or earlier concerned about these bugs can switch to the DNS Resolver (Unbound) until a new pfSense software release is available."
FYI- As of right now, if you are on 2.3.4-p1 you can fetch an updated dnsmasq

The simplest way is to use:
13) Update from console

via Console or ssh admin
Title: Re: a pfSense roadmap
Post by: pbnet on November 01, 2017, 03:59:32 am
Regarding the roadmap.
Do we have any approximate timeframe when PFSense 2.5 will be out ? Maybe when a beta will be available for testing ?
Since AES-NI will be required, I want to know how much time to I have until I would need new hardware :)

Thanks a lot,
Andy.