Yup, I noticed:

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

@cmb:

Nothing in the base system should show the real if name, open a ticket on redmine with anywhere you see that in the base system.

I'll go on a hunting expedition when I find a bit of time…
...and file the stuffed beasts in red mine ;)

Still one question: at what level are these real names real?

Obviously they are not the physical interfaces, which have names like em0, nor are they real even for things like fail-over interfaces (lagg0) nor for tunnels, nor...
So if they are not defined at the OS level, why can't we just rename the "real" names, forget about "friendly" names, and be done? Is this a BSD thing, or has it to do pfSense internals, or what?

Do you need any more information from me to investigate this?

There's already a feature request open. The reason it's not allowed is it was easy and bug-free to prohibit renaming rather than go through the bug-prone process of going through and changing all the potential references in the config. Not a priority to change at the moment but hopefully eventually. Patches welcome.

http://www.isc.org/software/dhcp

Thanks Jim!

It seems that the cause of this problem was the upgrade code issue described in http://forum.pfsense.org/index.php/topic,50182.0.html

I had to fix the config by hand:

$ diff config.xml ../pfsense2.1-config-fw.localdomain-20120529162500.xml
3c3
< <version>8.7</version>
–-

<version>8.6</version>
681d680
< <ipprotocol>inet</ipprotocol>
699,700c698,699
< <dnpipe>Downlimiter</dnpipe>
< <pdnpipe>Uplimiter</pdnpipe>

<dnpipe>1</dnpipe>
<pdnpipe>2</pdnpipe>
1194c1193
< <number>1</number>

<number>1207c1206
< <number>2</number>

</number>

Ah, then that's still something wrong in the package… It shouldn't be notifying for a configuration issue especially if it's valid. (if it's set to never and you have no blacklists, it shouldn't notify you that it can't download them...)

@databeestje:

should be fixed, gitsync please.

Sorry for the delay in this. It's fixed and working great. Thanks!  ;D

I belie problems lies in the fact that gui does not create proper list of rules that need to be loaded.
I don't know if the gui should store stuff in database or creates file with rules.
I can start snort by typing snort using ssh but trying to start snort with config files as it does not know what rules to load.

@daplumber:

Given that I only have mobile users it would be nice to be able to change the widget so that the "Mobile" tab displays by default. I'm sure people who don't have any mobile users might feel the same way about the "tunnel" tab.  8)

+1

And while we're at it: add buttons to bring up/down a tunnel or force-terminate a user

It depends on what is wrong, though from the errors you posted that doesn't sound like something that would normally resolve itself, even after a reboot.

You need to manually install the package:

For 32-bit run:

pkg_add -rf http://files.pfsense.org/packages/8/All/squid-3.1.19.tbz

For 64-bit run:

pkg_add -rf http://files.pfsense.org/packages/amd64/8/All/squid-3.1.19.tbz

It works fine for me. Credit to marcelloc for the instructions, see http://forum.pfsense.org/index.php?topic=48347.0

Thanks for reporting should be fixed on latest snaps.

I am also on the latest snap and not having any issues at all.

Be sure you clear the cache or force a page reload after getting an error like that.

IIRC I also committed that update to 2.0.x so when 2.0.2 comes out (RSN) the same applies there.

Please make new threads for each separate issue, otherwise things get buried in old threads that people may not check.
Locking topic.