Hmm, when you edit/save OpenVPN it should restart that instance. Even if that doesn't, you can use Status > Services to stop and restart the VPN instance.

If you had any static routes or gateways defined that should really be in the VPN config you will want to remove those, as that's probably the source of the issue with needing to reboot to fix the routing table.

(side note: quagga should be better now)

I'm waiting for this finished too ;) Core team and all developers that helps on 2.1 devel are working hard to finish it as soon as possible.

Take a look on packages topics.
Most packages has a workaround for it's install.
One I saw is still broken for 2.1 is the widescreen package.

@Nealio:

Have you verified that PFsense is giving out that address? That happened to me once, and someone else had incorrectly setup a 2nd DHCP server instead of a 2nd DNS server.

Some systems will report the DHCP server they last used. (Windows Vista ipconfig command if I recall correctly.) That can help verify the system got the "wrong" IP address from the "right" server.

It could also be informative to look at the pfSense DHCP log to see how pfSense treated the DHCP requests from systems that got the "wrong" IP address. (See Status -> System Logs, click on DHCP tab.)

I'm still trying to poke at ntpdc a little and figure out why the status is different. Still using ntpq now, and it's tally codes don't line up 100% with ntpdc's peer modes.

For instance:

From ntpdc(8):

            The character in the left margin indicates the mode this peer             entry is operating in.  A `+' denotes symmetric active, a `-'             indicates symmetric passive, a `=' means the remote server is             being polled in client mode, a `^' indicates that the server is             broadcasting to this address, a `~' denotes that the remote peer             is sending broadcasts and a `*' marks the peer the server is cur-             rently synchronizing to.

And from ntpq(8):

  Tally Codes     The character in the left margin in the `peers' billboard, called the     tally code, shows the fate of each association in the clock selection     process.  Following is a list of these characters, the pigeon used in the     rv command, and a short explanation of the condition revealed.     space   (reject) The peer is discarded as unreachable, synchronized to             this server (synch loop) or outrageous synchronization distance.     x       (falsetick) The peer is discarded by the intersection algorithm             as a falseticker.     .       (excess) The peer is discarded as not among the first ten peers             sorted by synchronization distance and so is probably a poor can-             didate for further consideration.     -       (outlyer) The peer is discarded by the clustering algorithm as an             outlyer.     +       (candidat) The peer is a survivor and a candidate for the combin-             ing algorithm.     #       (selected) The peer is a survivor, but not among the first six             peers sorted by synchronization distance.  If the association is             ephemeral, it may be demobilized to conserve resources.     *       (sys.peer) The peer has been declared the system peer and lends             its variables to the system variables.     o       (pps.peer) The peer has been declared the system peer and lends             its variables to the system variables.  However, the actual sys-             tem synchronization is derived from a pulse-per-second (PPS) sig-             nal, either indirectly via the PPS reference clock driver or             directly via kernel interface.

So while the ntpq codes give more accurate information on some areas, ntpdc seems to give more in others. I think we'll stick with ntpq for now, though I do need to see a little more about how both of them give info about clients syncing from this ntpd as a server.

…and now we're straying properly off topic. :-)

I did the upgrade but the WebGUI kept saying upgrade in progress, firewall will reboot after completed, and then it stopped serving the WebGUI and it never rebooted.  I have a feeling I will be down for the count if I reboot it manually… :(

EDIT:  Upgrade worked after a manual reboot.  I saw what you meant by "slow" i.e. when I save/apply a change it takes a bit, but it's ok since I don't sit on the webgui changing settings all day  ;)

I don't know if it's me but I notice everything faster and snappier (or my firewall needed a reboot?  LOL)   I do need new files to turn off LCD and to change the light to green, etc etc, you have those around? :)

Thanks!!!

EDIT2:  It is DEFINITELY faster, I can tell, is it caching or what?  I am very happy with this even on DEVELOPMENT!  Good job guys!!!

OK, locking this topic for now so it doesn't attract more random ntp issues, this thread originally was for OpenNTP losing sync which is very far away from tweaking ntpd.

I may split some older posts from this topic off into separate threads since there are still interesting things in them, but they have diverged from the original topic.

That is a known issue, has always been that way, and is done that way on purpose as the way that some of the data is passed makes that necessary.

I blew this box up again and loaded 2.0.1 and upgraded to the last 2.1 snap of Friday May 18…

The gateway is now coming up fine...    So possibly good since issue 2314 was fixed and just took a rebuild on my end...

:)

Thanks, I'll give that a try during this week :)

Yeah that's the post I was talking about. That's everything you need to know about how to make it work.

Probably related to these known issues:

http://redmine.pfsense.org/issues/2074
http://redmine.pfsense.org/issues/2306

That was a list of things we wanted to have, written quite a while ago. That one isn't likely to happen for 2.1.

MANY of the packages (FreeRADIUS, FreeRADIUS 2, Widescreen, others I'm pretty sure) and parts of the base (traffic shaper) are broken at this point in the 2.1 game. We just gotta be patient :) This is an awesome open source project, and while I do wish playing the beta game wasn't needed to get a fairly common RealTek NIC working, at this point in the game it is what it is and we just gotta be patient and glad we get such an awesome open source firewall! Huge shout out to the developers! (now… go have a snack and get back to getting FreeRADIUS 2 and the traffic shaper working for me :P LOL :D :D :D j/k... mostly :) )

Nicely solved ! I read about that Multimegabit downstream in Australia in another post - I sometimes dream about this would be possible in Germany too. (hsupa wt max 1m down in Frankfurt… If you are curious, i opened another thread about a plan to implement an editable mpd_[interface].conf in
http://forum.pfsense.org/index.php/topic,49478.0.html

hanD :)

It's set there because we don't write out a dnsmasq.conf so the only way we control dnsmasq is via the command line.

Yes, services.inc will be overwritten during an update, so you'll have to edit it again. There isn't a way to make such a change permanent yet.

that did it, thanks again jim!

Ok thank you, then I will use a HDD in the meantime and I'll keep my SSD for the new release.

Mmh, its motivating to see when groundwork is useful for more people :)
As told i started to code some gui to use for cases wher users need some further customization of pfsenses chatscripts.
So just some status info about some work on the frontend widgets i created for that task.

adv_custom_chatscript_edit.png_thumb
adv_custom_chatscript.png_thumb
adv_custom_chatscript.png
adv_custom_chatscript_edit.png

Should be fixed by this:
https://github.com/bsdperimeter/pfsense/commit/29c2c1db15b7b6765da24218f06295a98e9e8983

This has now been fixed by Seth - https://github.com/bsdperimeter/pfsense/commit/e32cb5d08d313f8265038e66a91ac96d4232ec53