2.1-release [Update - Success]
-
My issues seem to be fixed now. Removed Avahi and re-installed other packages (LED pkg for Alix board and OpenVPN client exporter).
Thanks for your help guys :D
-
My issues seem to be fixed now. Removed Avahi and re-installed other packages (LED pkg for Alix board and OpenVPN client exporter).
Well, all good then. Still leaves the question why stuff like avahi, snort or squid are even offered on nanobsd.
-
Not sure - but now I need a new way to get my mDNS packets across VLANs. I have a separate 'internal' wifi network to secure traffic from the internal ethernet. I also have a 'guest' wifi network that is even more restricted but without Avahi / mDNS I can't get traffic across the VLANs to allow things such as Apple Remote (control music / Apple TV etc).
First world problems I know :D
-
An alternate way to get around the mDNS problem is to configure the IGMP proxy.
I'm not really sure what avahi actually does (i know it's an mDNS implementation, but that's about it).
What i do know is to allow mDNS devices to communicate over a router, you need to route 224.0.0.251 (which the igmp proxy should be able to do). -
An alternate way to get around the mDNS problem is to configure the IGMP proxy.
I'm not really sure what avahi actually does (i know it's an mDNS implementation, but that's about it).
What i do know is to allow mDNS devices to communicate over a router, you need to route 224.0.0.251 (which the igmp proxy does).OK - cool. I'll look into this some more !
-
success..mostly from 2.0.3 to 2.1 Release. Thanks :-)
It seems IPSEC though has some issues. Clients using Shrewsoft VPN can't connect any longer. Any pointers here?
-
99% Success on two Alix-Boards
Only problem: I had some OpenVPN-Server setup with tunnle-network "x.x.x.1/24" that worked since 2.0 but 2.1 needs it as "10.x.x.0/24" otherwise you find a message like this "Options error: –server directive network/netmask combination is invalid" at the log.
But now I have to get to the other side of the tunnel and change it there, too :-(
Bye,
eweriP.S. pfsense is really great! ;-)
P.P.S. Just found out, that my OpenVPN-Server got a new WAN-IP because of the reboot after upgrade but forgot to update DynDNS - updated DynDNS by hand, now every VPN tunnle is up and running
-
I did two 2.0.3 CARP boxes today (full installs). No issues with the upgrade but twice I had issues with the primary box locking up when I hit "Disable CARP", requiring a reboot and then a second disable (I did a dry run first, the real upgrade did the same thing). Maybe it's a hardware thing, maybe it's a software thing, I don't know. The boxes will be replaced withing the next few months though so it likely won't matter.
-
Did an upgrade from console with full update AMD64 release. Effortless and 100% successful! First time Snort updated and started and ran without errors. Been running for 36 hours with no issues whatsoever.
Great job, guys.
-
P.P.S. Just found out, that my OpenVPN-Server got a new WAN-IP because of the reboot after upgrade but forgot to update DynDNS - updated DynDNS by hand, now every VPN tunnle is up and running
Between DynDNS trying to disable free service [for those who signed up long ago when that existed at Dyn] and their failure to update the address with an updater running, I had to shift my dynamic DNS service to another provider that actually worked (as in, autoupdated correctly.) Failure to update correctly was not exactly an inducement to start paying for Dyn's [evidently degraded] service, from what I could tell. It was one of the mysterious problems about getting my VPN to work in the first place, and it's been working fine and auto-updating correctly since I moved to a better free service (afraid.org) that isn't trying to get rid of me for not buying other services.
I have concerns about updating 2.0.3 to 2.1 in case it messes with my OpenVPN, as that will get me harassed by users. Seamless would be good…I suspect I won't rush in just yet, despite this hopeful report.
-
One last thing - To me, it seems people with Alix have so far been far more willing to spend 3 hours or more in forums than to do a clean wipe and reinstall of all services, so I STILL have no idea if avahi will work after a fresh re-install. Don't think anyone has done it. (But I do fresh install at the first sign of a snag - I don't like beating my head against walls)
The RRD upgrade process leaves too much junk in /tmp for the Alix to handle which causes a lot of other parts of the upgrade process to fail. And if you have more than ~6 interfaces (vlans, or whathave you) the default 60mb /var is too small during backups of the RRD graphs.
-
Yep - I've been working under the assumption that there is alot of data being left on the disk causing failures.
Lots of people are shy to reimage their systems, but some seem to have moved in that direction with good results. -
@Xon:
if you have more than ~6 interfaces (vlans, or whathave you) the default 60mb /var is too small during backups of the RRD graphs.
You recommend a /var size? The 10 interfaces in my home box proved your point. ::)
Steve
-
@Xon:
if you have more than ~6 interfaces (vlans, or whathave you) the default 60mb /var is too small during backups of the RRD graphs.
You recommend a /var size? The 10 interfaces in my home box proved your point. ::)
Steve
Applying this patch, will mean you don't need to touch /tmp. The real problem is it is about ~3.6mb per RRD graph with 2 years of stats, or 1.5mb new. The XML dump is ~4.5mb per RRD.
And the backup process requires dumping every RRD graph to XML, then compressing it. So maybe 90-100mb for /var should let you do the upgrade sucessfully?
Doing that on an Alix platform and getting it to boot would be hard. And if you ever decrease /var's size the RRD backup process would fail next shutdown/backup cycle, and thus cause RRD data lose on the next reboot.
The alternative solution which I'm poking at, is to update ./rc.backup_rrd.sh, /etc/inc/rrd.inc, /etc/inc/upgrade_config.inc to compress each file one by one, and then tarball it up.
So instead of dumping all the files to XML, then processing them dump 1 to xml, gzip it, then after tarball all the gzip'ed files. This is less efficient, both in time and over all compression of the final archive. But it fits in the memory constrains.
I'm bashed up a changed backup script and have the restore parts looking right. It is just a matter of testing and ensuring the restore process handles if you give it a .tgz or a gz.tgz
-
Personally I don't have an Alix, I have 512MB so running a 100MB /var is at least feasible. Also I have at least two years of data so I'm probably pushing the maximum size you might face.
That at least explains why I have had no problems updating any previous test box that had fewer interfaces and much less data.Steve
-
Update 4 Alix1D3 by now. Almost perfect, but in my CARP setup from 2.0.2 -> 2.1 OpenVPN is not working. The server doesn't answer anymore, I'm rolling back
-
Update Alix2D3 from 2.0.1 to 2.1
All perfect
Congrats and thanks
-
halo ,
PFSENSE router using for dual wan failover , working very good with wan and opt1 as wans and lan as lan network.
Upgraded 2.0.3 to 2.1 my opt1 is not working after upgrdation. Opt1 is showing in dashboard pending and unknown.
Please advise me work the opt1 .Thanking you .
(this is my first post . Please tell me where can i start my new post or question.I didnt find anywhere to post thatswhy
I used this Excuse me please. ) -
Another successful installation on a Soekris 6501-70.
This was an auto-upgrade from pfSense 2.03 Release to 2.1 Release, i386. I'm using the full version of pfSense, not the NanoBSD images, with a standard HDD. No issues to report.
-
Just updated to 2.1 but having problem with squid. got this error meesage.
squid package is missing required dependencies and must reinstalled
