I can also confirm the limiter bug in the snap, disabling the limiter clears the issue.

Ok, that response is a bit silly.

I changed out the WIDE dhcp6 client for the ISC client, it appears to work on a VM here including prefix delegation, but it will need more testing.

See if this helps your situation.

OK I went ahead and committed that file. If you (or anyone else) gets a chance to test it more extensively, post here if there are more errors/problems.

@bardelot:

Just try Jim's suggestion:
Copy the pfSense.po and pfSense.mo files into the 'zh_CN.GB2312/LC_MESSAGES' folder. And make sure the file names are correct (the S is upper case).

Then change those two set_language function calls to be:
set_language($g['language'], 'GB2312'); // in usr/local/www/guiconfig.inc
set_language($config['system']['language'], 'GB2312'); // in usr/local/www/system.php

Edit 1:
Btw: Did you translate the correct file? The original file size (pfSense.pot) is 10x yours.

Edit 2:
Looking at the translation project website I think you have used the Terminology project (http://pootle.pfsense.org.br/zh_CN/). However there should be a pfSense project as is the case here (http://pootle.pfsense.org.br/pt_BR/). I don't know how you can add the correct project, maybe send an email to the maintainer (vcoque).

yes, I am download the Terminology project, there has no other chinese file can downlaod.  I don't know which file need tranlater.

You can't do NPt from a /64 to a /48

It has to be an identical size subnet.

That page still needs a bit of input validation. Go ahead and open a ticket on http://redmine.pfsense.org/ for it.

@xbipin:

enabling schedules on limiter also give the below error

php: : The command '/sbin/ipfw /tmp/rules.limiter' returned exit code '64', the output was 'Line 1: bad command `bw''

You should create a new thread and not abuse this one, as it is a different problem.

I have had CF cards that spat out IO errors on the console when used for real (and caused system hangs, crashes, whatever). I took them out, put them in my CF card reader, and used phydiskwrite to write a complete new image with no errors reported. Put the card back in the system, booted OK, reloaded the config from backup. Not long after, IO errors are happening again.
So physdiskwrite must have done a lot of good stuff (the card got a bootable FreeBSD/pfSense slice, the files that pfSense actually uses must have been written OK, the config restored OK…), but I have trouble believing that it really wrote to the whole CF card successfully. Maybe physdiskwrite doesn't check the IO return status of its writes?
Obviously, I replaced that card with a new one!

@jdamnation:

I think someone suggested just sticking FBSD clean and re-run the test - which is a very good idea as it cuts PF totally out and enables us to bench the metal.

Enabling pf on the traffic cuts down significantly on throughput. You'll be able to route a gigabit through it, but not filter w/pf. Stock FreeBSD won't be any different.

It's not a workaround ;)

(unless you want to scheduled different NAT rules to different internal servers. But if you're fighting with problems like this… NAT is the wrong approach)

Should be OK now

https://github.com/bsdperimeter/pfsense/commit/64eda26c1efa0305824edbfb0ad37703a5f64ca3

@akha666:

@bkraptor:

Under System -> Advanced you have the option named "Password protect the console menu". A reboot of the box is required after activating this option.

Oh, thank you
U point me for what I'm looking for , you make me feel i'm blind . hahaha
thank you for help

Don't feel bad… I missed it too.

[OT] another cool feature could be supporting thermal ethernet voucher ticket printers, like zyxel's (http://www.zyxel.com/products_services/n4100_vsg_1200_v2.shtml?t=p). quite fool proof for the average receptionist: 3 buttons.

i have a couple of them btw, i could do some packet sniffing if needed to decode comm protocol

@jimp:

those have nothing to do with captive portal. They specifically refer to the squid package and tinydns package.

OK, I was mislead by the include path… should have read the messages more precisely.

It is trickier than it seems. /var/log/filter.log has entries that have rule numbers:

clog /var/log/filter.log | grep "rule 84" Oct  4 08:37:21 pfsense pf: 00:00:00.000000 rule 84/0(match): block in on vr0: (tos 0x0, ttl 128, id 3507, offset 0, flags [DF], proto TCP (6), length 56) Oct  4 08:37:21 pfsense pf: 00:00:00.250417 rule 84/0(match): block in on vr0: (tos 0x0, ttl 128, id 3508, offset 0, flags [DF], proto TCP (6), length 56)

then the running pf has its own index of rules, here is a test rule I put in:

pfctl -vvsr | grep reject @84 block return in log quick on vr0 inet from any to 1.2.3.0/24 label "USER_RULE: Test reject 1234"

If the "label" value had an index back into the config.xml filter rules array, then anything about the rule in the pfSense config could be looked up. e.g. make "label" say "USER_RULE: 999 Test Reject 1234" - where "999" is a unique ruleid stored in the filter array in config.xml
The tricky bit is that filter.log does not have this "label" text. It contains a rule index into the pf rules of the running pf at the time the entry was logged. If the pf rules are reloaded, then the rule indexes in old filter.log entries are now (potentially) invalid. The original index information from the time of the filter.log entry is gone.
To fix that problem, every time pf rules are reloaded the list of pf rule indexes and rule data (pfctl -vvsr) would have to be saved, along with a timestamp for the ruleset change. Then when filter.log is parsed, the ruleset in use at the time of the filter log entry could be used to find the correct details of the rule index number.
Almost anything is possible, but it sounds like a fair bit of effort!

@jimp:

patches accepted…

If someone wants to make gui knobs, have at it. :-)

I've done some minimal additions to generate offset and frequency graphs with rrdtool, for testing the 2.1 ntp daemon.  I can supply the shell lines to generate the ntpd stats (below), but I'm not too sure I could integrate rrdtool ntp info into the existing GUI rddtool graphs.  Would be great to be able to track the performance of your ntpd server with a tab on the RRD graph page.  Where are the RRD databases first initialized?  Need to create one before using script below.

BTW, I noticed ntpd offset swings of about -600 to +700 microseconds with /usr/local/bin/ntpd (running 2.1snapshot ova in virtual box, syncing to a stratum 1 server on a local subnet).  The swings went down to -150 to +150 microseconds when I reverted to /usr/bin/ntpd.

SImple shell script for offset & frequency; change as needed:

#!/bin/sh counter=1 while [ "$counter" -ne 0 ] do DATA=`ntpdc -c kerninfo | awk '/^pll offset/ {printf $3*1000000}; /pll frequency/ {printf ":"$3}'` #echo ${DATA} /usr/bin/nice -n 20 /usr/local/bin/rrdtool update /var/db/rrd/ntp_stats.rrd N:${DATA} sleep 60 done

yes but i think some way to specify those in the pfsense gui need to be present as well for more control

Reset the network settings on the iPad and see if that helps. Maybe the iPad has been on another network and had the 0.26 address there. Just guessing ;)