When the package is made properly, the pkg add will perform the exact same install procedure as the GUI would.

I also found myself with this problem, which I was able to fix with this fix : https://github.com/freebsd/freebsd/commit/6884a6e482ca6effa702761a1e3fa98bb6946c30#diff-49d9a861ee932d5b656eb20466f2a292
But other problems have occurred. :-[
I had not had this problem with the RC version, which it was in "FreeBSD 11.0", so I put a compilation environment under this version, and compilation to work.
I therefore conclude that the development team forgot to add a "BRANCH RELENG_2_4_0" on this repository: https://github.com/pfsense/FreeBSD-src

The "Main repository for pfSense" is also unusable because it refers to a "BRANCH" that is missing: https://github.com/pfsense/pfsense/blob/RELENG_2_4_0/tools/builder_defaults.sh#L108

Can someone tell us about this omission ?

Thank you !

As far as I'm aware, we have no intention of adding any wifi features like that. AP features belong in an AP. FreeBSD is great, but it does not lend itself well to being an AP.

@biggsy:

Thanks Bill but I'm not sure how it would be related to Squid.  However, I'm not a Squid user either so I could easily be wrong.

I run this bgpctl command from a tiny PHP script called through an afterfilterchange shellcmd.

It causes the BGP peer to resend all the currently blacklisted IPs, which are loaded into an Alias table referenced by a block rule on WAN.  It does this very, very quickly, too.

The only reason for having to do all this is that the Alias table is not managed through the GUI, so it gets cleared on a rule change or reload.

Of course, I have no reason to expect this won't be achievable in some other way under 3.0 but it is a very useful function of openbgpd.

Sorry…just realized today that I posted my reply to the wrong thread ...  :-[

Bill

If it was an optional package add-on, the GPL license doesnt taint the base at all.

+1 to this.

This guy brought it in via freebsd packages https://blog.dhampir.no/content/pfsense-as-a-cisco-anyconnect-vpn-client-using-openconnect

FauxAPI has received an update to v1.1

In brief:-

new API call alias_update_urltables - forces the immediate update of remote URL tables new API call gateway_status - returns the current status of the gateways updated documentation tested against pfSense 2.3.2 and 2.3.3

The package has received some great feedback and users deploying in complex large environments - enjoy, send feedback.

N

I had the same issue until I increased my RAM disk size.  I think what happens is the file tries to write to the RAM disk but fails since it's out of space with the default size.  The setting is found under System/Advanced/Miscellaneous.  I increased mine to 512 MB's.  Since I have 8 or 16 gigs of RAM and have plenty to spare.

I followed the detailed post above, its on the right path but the build script is clearly designed with obstacles.

So if rename to pfSense it blocks the build.

So then try to rename appropriate files from pfSense to nonSense since they dont distribute with that name

in addition it tries to fetch packages from dead netgate url's.

The showstopper is when renaming the 3 files in here to nonSense

pfsense # ls /root/work/pfsense/pfsense/tmp/FreeBSD-src/release/conf/
pfSense_make.conf          ufw_installer_make.conf    ufw_recover_make.conf
pfSense_src-env.conf      ufw_installer_src-env.conf ufw_recover_src-env.conf
pfSense_src.conf          ufw_installer_src.conf    ufw_recover_src.conf

Then running build.sh again, the build script itself renames them back to pfSense and then complains it cannot find the nonSense files, so its sabotaging itself.

I blocked the script doing the sabotage by making the filles immune (root cannot even write/delete)

chflags schg nonSense_*

But now hitting repo clone errors.

Since I only need to compile a custom kernel I might just try to compile the kernel in the traditional FreeBSD way, as I am only oing this to get a patched kernel to fix a nasty panic bug.

My method is automated, Even the people who connect to these remote devices in many cases dont know anything about linux, or security.  So with a bit or code i wrote, When you SSH to the SG-1000 it automatically redirects you into telnet to the proper device, no need to issue any telnet commands, etc.  You SSH, and its as if you have gone directly to the telnet device in question.

The SG-1000 would also take the place of the firewalling of the crappy DSL Modems, as they could be put in transparent mode, and the pfsense then utilized for a much better firewalling solution and access control.

It would be a simultaneous upgrade to the firewall, and the telnet device at the same time, as well as facilitating better security for any other devices connected in that location.

My code supports tunneling each user account to a different telnet device, not just 1 telnet device.  So its flexible in its usage, and works on bigger models as well, such as SG-2220, and 2440.

Looking for syslogs with external host data (i.e. public internet facing)

I have internal network logs and can collect without an issue.