Could be fixed, but it is probably very low priority, as only one of those will ever execute anyway when the condition is true. (though it will try the condition that many times if the condition is false)

Added a note

https://github.com/bsdperimeter/pfsense/commit/b835b1faffe90b7dcb2e6ef9ce846998074d696a

@jimp:

The bulk of the hard work is due to the fundamental differences between the image/install style of the two, and they aren't compatible really. And simply generating a larger NanoBSD image (say, 16GB+) wouldn't really be practical, though the builder does support it.

Well, yes, besides one would lose all the various advantages of the rw file system.

I mean, it's not like we would have to switch back and forth all the time. It would be OK to have a main system, that acts just as what we have now, with some logic to fall back on an alternate slice if things go haywire.
I'm less concerned about the A/B/A/B/A/B thing that nanoBSD does than about having something that can be easily, preferably automatically be booted if the main partition gets screwed up, and allows the system to be fixed remotely.

So I don't mind living 99% on partition A, updating partition A, etc. as long as I can easily fall back on a partition B with a fall-back configuration. Key would only be that both partition A and B have the ability to wipe and reinstall the non-active partition, and dump a known-to-work configuration on the other partition.

So I guess what would be needed is that the original installer can make the extra partition(s) needed, and that the regular system gains the ability to download and install on the other partition, a full fresh installation, and then restore some configuration to that other partition, and then switch the boot partition.

Basically, if there were a rescue partition that only needs a password and a valid WAN address set, and if booted from that, one could reinstall the other partition from a web interface, and then restore a backed up configuration to that other partition, then that would cover things. So it's not really needed to have two fully functional installs. On the other hand, it may be more hassle to maintain a rescue system than to just put that ability to install/restore another partition into the regular system, so in that case there would simply be two systems installed, that can each nuke/restore the currently unused partition, and switch the slice booted from.

Heck, since during install one can do custom partitioning, I wouldn't mind if the initial install would be mostly manual work following some how-to write-up, as long as in the end it's possible to easily image a system install on the other partition, and restore a configuration to it without having physical access to the device.

@jimp:

Yes, the day this message was posted (and a few times since then)

thanks jimp… I ask because I tried a build a few days ago and was getting the same upnp errors that were reported... not sure what the build was... I'll try a new snapshot shortly

Build: 2.1-BETA0 (i386) built on Mon Jun 11 03:04:57 EDT 2012

Does not exhibit the same problem.

I hope I'm not jinxing myself by posting this, but, things seem to have remained stable since I turned off NAT Traversal on both sides.

Strictly speaking, right now things don't go through NAT, but there are/were cases when I had to put a VoIP appliance between the WAN and the firewall, at which point there would be NAT even though the firewall would be an "exposed host". So for such cases, I always had NAT traversal turned on, and during link negotiation the systems notice that it's not needed and then don't use it.

This was the same with pfSense according to the logs, so I figured, it's fine. For shits and giggles, I turned NAT-T off on both sides, and since then things have been up. (Of course, maybe I was just lucky and in a few hours I have to say:"Oops, back to the same old…")

Still, while it seems like I might have found a cure, why would it negotiate a NAT-T free connection, and then later fail?

Well, I'll keep an eye on things, to see if it now stays up reliably, which would be great.

Or have there been other recent changes that could have had an influence on this issue?

@databeestje:

we start dhcpd with both -4 and -6, so we should be able differentiate between the 2. That and we have 2 PID files too.

I know that, just thought because:

@jimp:

The way our service control code works, it only looks at the executable name, which since this is the same for both, I'm not sure there is a way to separate the two without changing significant portions of the service control code.

So by using a hardlink, the service control code wouldn't need to change, that was all. Otherwise, sure, if the service control code is parsing the options passed to the executable it can be done without that trick.

@jimp:

Sure you've cleared your cache and everything? Perhaps your browser cached an older version of jQuery from the firewall.

Just verified the reported behavior using ctrl-shift-R (reload overriding cache), autocomplete=off using attr works whereas prop doesn't. Your original commit worked fine when I tried it several days ago, which is why I was puzzled to notice the same issue today.

It's a minor issue, but it shows attention to detail …

@cmb:

Web interface has done the same since 2.0 betas.

Cool, that's all I needed to know…
...makes me a bit less paranoid about keeping the interface open to https access from the WAN side :)

@cmb:

Probably would work if that CNAME is listed as an authorized hostname under System>Advanced.

I'll try that later on. Good idea.

EDIT: That seems to have fixed it. At least it works now…

Thanks! This was driving me nuts. Still don't get it why this was only an issue on the 3G network  ???

Sounds like a better candidate for a package.

Can't argue feature bloat if it's a package. :-)

If you were using policy routing rules for ipv6 (rules with a gateway set) that was broken sometime recently, but was fixed this afternoon. Wait for a new snapshot or gitsync and trigger a filter reload to see if that helps.

was indeed related to http://forum.pfsense.org/index.php/topic,50221.0.html

this is now solved

thanks, all seems ok

I've got a similar box an Atom D525 with 4 GB RAM, 400000 seems to work well.

@jimp:

I can't reproduce "a". Note that to save those now you have to set the graph how you want, then click the little wrench in the title bar of the traffic graph widget itself, then click save there.

Reordering the graphs has never been possible, but if someone wants to do that, patches would be more than welcome (you can open a feature request on redmine for that, target=future)

Ah, OK. I thought that saved only the update interval, and layout etc. was saved when you save the dashboard setup as a whole.

@jimp:

There is not and never has been any dynamic width adjustment in the widgets (yet?), the columns are all fixed-size. As is probably evident in many places, we don't have much in the way of HTML/CSS experts to polish up things in the GUI like that. I thought there was already a feature request somewhere in redmine to handle those sorts of things better.

Sure. My thing is more that certain layouts are destined to break, and thus I believe need a rethinking of the layout, because there's no way that things can fit, e.g. when IPv4 and IPv6 addresses are on the same line in the interfaces section, there's just not enough space for an IPv4 address in the ddd.ddd.ddd.ddd format and an IPv6 address in the hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh format side by side.
So either these addresses need to be listed below each other, or some other solution has to be found.

A similar one is the firewall log widget: it already has trouble with lines where we have two full IPv4:port pairs in full length, i.e. ddd.ddd.ddd.ddd:ddddd. Not sure how that's going to fare once IPv6 addresses start showing up there…

Of course, there are other issues, that are less predictable and likely require some CSS magic, like hostnames and descriptions that can be of nearly arbitrary length, these can easily be deferred until some web wizard takes them on, but I think the others would be good to fix before the final release, because there we deal with strings of which we know the upper size limit, and we know that limit is being reached every so often, and when it's reached (or even before) it just breaks the layout.

@jimp:

Someone didn't read their stickies :-)

http://forum.pfsense.org/index.php/topic,50095.0.html

Well, didn't have an issue with the gateway being down or showing "gathering" or anything like that.
Just the pop-up menu next to the DNS servers behaved funky.

Actually, it still behaves in ways that are not fully clear to me, sometimes showing all gateways (IPv4 and IPv6) and sometimes only a subset matching the address in the DNS server field, meaning, sometimes I have to save first to get the pop-up to be populated with the gateways I need.

So even deleting/recreating all gateways (in order to rename them) didn't really help getting consistent behavior.