The wiki article here: http://doc.pfsense.org/index.php/Creating_Your_Own_Package_Repository Was written before when the repo was on rcs.pfsense.org. Over the years people have checked in all kinds of binaries into the repo, and they don't belong there. Only the PHP/xml/scripts belong in there. So when we moved to github a lot of that data that shouldn't have been in the repo was purged (lots of .tgz/.tbz files add up quickly in size!) and moved to where it should be on files.pfsense.org. As a consequence of that purge, the size has reduced quite a lot. It used to be nearly 1GB in size between the data and the history in the .git directory. It's still nearly 200MB. pfSense-packages$ du -k -d 1 88258  ./.git 110476  ./config 198970  . When developing packages, especially making new ones, having your own repo is quite handy. It's even better if you make your own fork of the packages repo on github and work with that on your server as you make changes. Then once you have it ready you can just submit a merge request there.

I don't know about bandwidthd but outbound loadbalancing has changed in 2.0. To configure it you setup a gateway group (system >> routing >> groups) and add your WANs to it. Then assign each wan a tier, all tier 1 will result in equal priority and hence load balancing. Use lower tiers if you want failover. Now edit your firewall rules to use the gateway groups as gateway. Steve Edit: Exactly which version are you running? If you are running the 'official' RC1 release, 26.02.2011, the try a much more recent snapshot. A lot has been fixed since then.

I have checked my config backup with the xmllint command and it has problems with letter ñ, I change it and I can restore the configuration from 1.2.3 to 2.0 version. Maybe that's the problems with continuous automatic reset configuration, I gonna do test to confirm that.

Nope, not us. Clearly we aren't "Proffesional" ;-)

Possibly, with the Captive Portal functionality. If you configure it to authenticate against your active directory you may be able to get it to work.

Thanks for using it. Spread the word :-)

Please read the link I provided.

Dear Jimp Thanks a Lot for vital information. My LAN is 192.168.0.0/21.It has 2 gateway servers. one gateway is on pfsense and the other on Linux Box. I need loadbalance the traffic of 192.168.5.0/21 subnet  and 192.168.7.0/21 subnet  using routing tables,I need to divert the http traffice that is coming on to pfsense LAN interface to other Linux box (gateway) The reason I cant use policy based routing is, the LAN interface of the Linux box is not visible on the gateway list of pfsense. cheers Asanka.

That's just a ridiculous article.  >:( I mean I like the idea of a mobile interface to my router but to describe it as an 'app' that controls all the devices on your network. That aside I guess this could be useful, though if you are using traffic shaping I wouldn't have thought it would be difficult to prioritize business traffic over gaming.  ::) Having to intervene manually by tweaking your router doesn't sound like something most users would want. I'd like it!  ;D Steve

I have been using tapatalk on my android tablet and it has been making browsing through forums a breeze. It would really be nice if pfsense would support tapatalk as it can be really useful and efficient. I have seen this in most forums I join and I think it would really be a great addition to pfsense's arsenal of functions.

@stephenw10: Just to say that changes to the boot file should be in: /boot/loader.conf.local Changes added there will be copied across an upgrade. See: http://forum.pfsense.org/index.php/topic,28181.0.html Steve Thanks.. Updating the thread, I have to say that since I'm on RC versions, things have changed. I've stopped using these: kern.ipc.nmbclusters="32768" kern.maxfiles="131070" And it's running very well. @Nachtfalke: alternate dns 127.0.0.1 in squid.inc(usr/local/pkg): dns_children 20 Don't use this too. As for the other options, I'm not using disk cache. It seemed to me that that was really my problem. Slow disks. Squid cache was very intensive  with my 400+ users. I've changed my updates to an WSUS server and I'm only using squid in pfsense with squidGuard. The rest of my setup remains the same. (same advanced options)

Show screenshots of your setup.

First try to put only a single cam(1) on your hub >if ok> plug the second hub in "daisy chain" with only single cam(2) attached if ok> then you should upgrade your hubs power supply to 3 Amps+ and shield your cable with ducking tape if not> maybe your powered hubs does not support daisy chain….

Well, true. Checking the facts is always a very good idea too. I'm not at all concerned either way because as one NATO officer puts it…they've got warehouse size buildings with Cray supercomputers dedicated to this and you honestly think your little email with your little PGP keys have not been decoded and sent on it's merry little way? (Speaking in terms ofcourse) And who knows, unless you check the facts, that code could have changed to make the man in the middle become the man in between..just saying. Ofcourse these are all allegations...as always. Jits.

A gateway is supplied from the remote end, though it isn't really necessary in the traditional sense. It's useful to ping the other side to be sure the connection is up, and there are other reasons it's there (but I don't recall them offhand)

@greatbob6: I love the features of the Drobo, I think the simplicity can't be beat.  My issue with Drobo only has to do with potential reliability issues, a lot of the reviews I've seen on the net have not been very pleasent to read.  How long have you had yours? About a year. As I said, under warranty, the PSU failed. But the data was safe, so the unit was replaced, drives moved, and all was hunky-dory. Don't get me wrong, I'm not thrilled about an PSU failure within the first year of operation, but I'm also aware of the RhoS transition issues caused for many electronics. Of course, data integrity ranks higher than hardware reliability, because once the data collection reaches a certain size, backing up is nearly impossible, unless one has a HUGE budget. So trying to back-up an 8-drive droboPro with dual-reduncancy (RAID-6-ish) would require pretty much double the budget requirements… So from that perspective what I don't like is the lack of ECC RAM, because the one thing that in the past caused data loss on a RAID setup, aside from accidentally deleting data, was defective cache RAM. RAID-[56] won't protect against corrupted disk buffers being written to the drives, if there's no way of parity checking on the RAM that holds the disk buffers. So for data integrity, it's the lack of ECC RAM that concerns me. The dead PSU was one of these things that's annoying, but as long as the data didn't suffer, it's bearable. From the operating functionality, though, it's the best. So it's a question of what bullet you want to bite ;) I wish there had not been the legal controversy around ZFS. If Mac OS X had adopted/supported ZFS, then that would have solved just about all of my demands. I bought the drobo after Apple dropped development of ZFS for Mac OS X due to legal/patent disputes over ZFS. But for many reasons, I need something that to the OS is a locally attached storage device, rather than a network file server. So typical NAS devices just don't cut it, and other iSCSI devices don't allow for thin provisioning and OS-transparent capacity upgrades. That's what really sold me on the drobo. Other stuff, in particularly Thecus and QNap were high on my list of competing products, but in the end I settled for a droboPro for reasons of cost and operational simplicity, even though I'm quite vocal about the reservations I have in regards to not using ECC RAM and less than ideal transparency of systems diagnostics.