[pfSense Support] SS with Putty don`t work
It would be worth going into session settings in the putty configuration dialogue and setting 'close window on exit' to 'never'. Then you'll actually get to see error messages that precede your connection being closed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Re: [pfSense-discussion] DynDNS and PPPoE
On 9/11/05, Damien Dupertuis [EMAIL PROTECTED] wrote: Hello, To install the 0.84 I had to re-install ewerythig from scratch... By the way I was unable to re-install on my 256mb cf-card because the installer said it was full (with swap 1mb) I'm using an old 2.5inch 4gb hdd I had lying around but it is wery noizy :-( If your installing to a CF: #1. Do not include the swap partition #2. You really should be using our Embedded version Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] strange problem with /boot/loader.rc
I upgraded to 0.84 yesterday, it went apparently without problems. Today I rebooted the system and it wouldn't boot. After inspection of the files in /boot, it appeared that loader.rc was 14672 bytes of size and contained thousands of blank lines in addition to the few it should contain. I grepped the non-empty lines into a new loader.rc and now the system is up and running again. Is this a known issue or would it be a good idea to look into this a little more in detail? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] strange problem with /boot/loader.rc
On 9/11/05, Oliver Stark [EMAIL PROTECTED] wrote: I upgraded to 0.84 yesterday, it went apparently without problems. Today I rebooted the system and it wouldn't boot. After inspection of the files in /boot, it appeared that loader.rc was 14672 bytes of size and contained thousands of blank lines in addition to the few it should contain. I grepped the non-empty lines into a new loader.rc and now the system is up and running again. Is this a known issue or would it be a good idea to look into this a little more in detail? Can't say that I have seen this problem. What version where you upgrading from? We have made a number of changes to the upgrade procedure recently to try and prevent corruption/race issues after upgrade. Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] Error in Services: PFStat Settings
In item Services: PFStat Settings _(http://192.168.202.253/pkg_edit.php?xml=pfstat.xml after filling settings and then save, occurs error as bellow: http://192.168.202.253/pkg_edit.php $value = $_POST['location0'];$value = $_POST['counters0'];$value = $_POST['color0'];$value = $_POST['appearance0'];$value = $_POST['location1'];$value = $_POST['counters1'];$value = $_POST['color1'];$value = $_POST['appearance1'];$value = $_POST['location2'];$value = $_POST['counters2'];$value = $_POST['color2'];$value = $_POST['appearance2'];$value = $_POST['location3'];$value = $_POST['counters3'];$value = $_POST['color3'];$value = $_POST['appearance3'];$value = $_POST['location4'];$value = $_POST['counters4'];$value = $_POST['color4'];$value = $_POST['appearance4'];$value = $_POST['location5'];$value = $_POST['counters5'];$value = $_POST['color5'];$value = $_POST['appearance5'];$value = $_POST['location6'];$value = $_POST['counters6'];$value = $_POST['color6'];$value = $_POST['appearance6'];$value = $_POST['location7'];$value = $_POST['counters7'];$value = $_POST['color7'];$value = $_POST['appearance7'];$value = $_POST['location8'];$value = $_POST['counters8'];$value = $_POST['color8'];$value = $_POST['appearance8'];$value = $_POST['location9'];$value = $_POST['counters9'];$value = $_POST['color9'];$value = $_POST['appearance9'];$value = $_POST['location10'];$value = $_POST['counters10'];$value = $_POST['color10'];$value = $_POST['appearance10'];$value = $_POST['location11'];$value = $_POST['counters11'];$value = $_POST['color11'];$value = $_POST['appearance11'];$value = $_POST['location12'];$value = $_POST['counters12'];$value = $_POST['color12'];$value = $_POST['appearance12'];$value = $_POST['location13'];$value = $_POST['counters13'];$value = $_POST['color13'];$value = $_POST['appearance13'];$value = $_POST['location14'];$value = $_POST['counters14'];$value = $_POST['color14'];$value = $_POST['appearance14'];$value = $_POST['location15'];$value = $_POST['counters15'];$value = $_POST['color15'];$value = $_POST['appearance15'];$value = $_POST['location16'];$value = $_POST['counters16'];$value = $_POST['color16'];$value = $_POST['appearance16'];$value = $_POST['location17'];$value = $_POST['counters17'];$value = $_POST['color17'];$value = $_POST['appearance17'];$value = $_POST['location18'];$value = $_POST['counters18'];$value = $_POST['color18'];$value = $_POST['appearance18'];$value = $_POST['location19'];$value = $_POST['counters19'];$value = $_POST['color19'];$value = $_POST['appearance19'];$value = $_POST['location20'];$value = $_POST['counters20'];$value = $_POST['color20'];$value = $_POST['appearance20'];$value = $_POST['location21'];$value = $_POST['counters21'];$value = $_POST['color21'];$value = $_POST['appearance21'];$value = $_POST['location22'];$value = $_POST['counters22'];$value = $_POST['color22'];$value = $_POST['appearance22'];$value = $_POST['location23'];$value = $_POST['counters23'];$value = $_POST['color23'];$value = $_POST['appearance23'];$value = $_POST['location24'];$value = $_POST['counters24'];$value = $_POST['color24'];$value = $_POST['appearance24'];$value = $_POST['location25'];$value = $_POST['counters25'];$value = $_POST['color25'];$value = $_POST['appearance25'];$value = $_POST['location26'];$value = $_POST['counters26'];$value = $_POST['color26'];$value = $_POST['appearance26'];$value = $_POST['location27'];$value = $_POST['counters27'];$value = $_POST['color27'];$value = $_POST['appearance27'];$value = $_POST['location28'];$value = $_POST['counters28'];$value = $_POST['color28'];$value = $_POST['appearance28'];$value = $_POST['location29'];$value = $_POST['counters29'];$value = $_POST['color29'];$value = $_POST['appearance29'];$value = $_POST['location30'];$value = $_POST['counters30'];$value = $_POST['color30'];$value = $_POST['appearance30'];$value = $_POST['location31'];$value = $_POST['counters31'];$value = $_POST['color31'];$value = $_POST['appearance31'];$value = $_POST['location32'];$value = $_POST['counters32'];$value = $_POST['color32'];$value = $_POST['appearance32'];$value = $_POST['location33'];$value = $_POST['counters33'];$value = $_POST['color33'];$value = $_POST['appearance33'];$value = $_POST['location34'];$value = $_POST['counters34'];$value = $_POST['color34'];$value = $_POST['appearance34'];$value = $_POST['location35'];$value = $_POST['counters35'];$value = $_POST['color35'];$value = $_POST['appearance35'];$value = $_POST['location36'];$value = $_POST['counters36'];$value = $_POST['color36'];$value = $_POST['appearance36'];$value = $_POST['location37'];$value = $_POST['counters37'];$value = $_POST['color37'];$value = $_POST['appearance37'];$value = $_POST['location38'];$value = $_POST['counters38'];$value = $_POST['color38'];$value = $_POST['appearance38'];$value = $_POST['location39'];$value = $_POST['counters39'];$value = $_POST['color39'];$value = $_POST['appearance39'];$value = $_POST['location40'];$value = $_POST['counters40'];$value =
RE: [pfSense Support] Hang at the end of bootup
Changed to keyboard and mouse and it's working now. Thanks John -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: Sunday, September 11, 2005 12:01 PM To: support@pfsense.com Subject: Re: [pfSense Support] Hang at the end of bootup This happens on USB keyboards for some reason. If you can, use a PC keyboard. Scott On 9/10/05, John Cianfarani [EMAIL PROTECTED] wrote: I'm working on install version 0.82.4 / 0.84 and seem to be having some troubles. I have gotten it to work fine under vmware though now that I'm trying to move it to a real machine it doesn't seem to like it. Essentially after the LiveCD boots and I do my entire interface configuration it comes to the end with Bootup complete and then hangs. During the initial load there are few error messages that I can see: This repeats several times: acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 error=4ABORTED A few lines before the option to setup interfaces I get: mount: /: unknown special file or file system No Swap on CDROM After configuring the interfaces there is a line: kbdcontrol: cannot open /dev/ukbd0: Device Busy This and reading some posts in the list made me think the CDROM could be the problem, I moved it to the secondary ide and changed the cable, also reburned the cd at 4x. I set my dhcp server to statically give out ip to see if I could ssh into it but I still could not get it after it hangs. System specs CPU: Celeron 2.6Ghz Board: Asus P4P800-MX (All hardware except for NIC is disabled, IDE mode is set to compatible) Memory: 512Meg CDROM: LG GCE-8526B HD: WD160GB Mouse Keyboard are USB (Gyration) If anyone knows anything else I could try that would be great as I'd like to start testing it on a real box. Wish I could post more output but I have to way to copy it out only retyping L Thanks John Cianfarani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pfSense Support] FW: Cosmetic Bug in Trafficshaper?
Any ideas? From: Robo.K. [mailto:[EMAIL PROTECTED] Sent: Sunday, September 11, 2005 1:14 AMTo: 'support@pfsense.com'Subject: Cosmetic Bug in Trafficshaper? After complete the traffic shaper wizard I go into any item of Queue and change anything , only save queue, then in /firewall_shaper_queues.php in culmn Bandwidth dismiss value of amount persents or kilobits. This box remains empty. 10 RED ECN 5 No 1 % qGamesDown 11 RED ECN 4 No 1 % qOthersUpH 12 RED ECN 4 No 1 % qOthersDownH 13 RED ECN 2 No qOthersUpL 14 RED ECN 2 No qOthersDownL 15 RED ECN 5 No pokusssnaaa --No virus found in this outgoing message.Checked by AVG Anti-Virus.Version: 7.0.344 / Virus Database: 267.10.20/95 - Release Date: 9.9.2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 10.9.2005 -- * www.inMail.sk - Vasa emailova adresa na cely zivot ZDARMA * www.inshop.sk - virtualna obchodna galeria s viac ako 230 obchodmi! * www.SlovakNET.sk - profesionalny webhosting, domena .SK ZADARMO
[pfSense Support] Unable setting all 13 channels of Europe (ETSI) 13 Channels : 2.412GHz~2.472GHz
In version 0.84 PFsense is unable set with Atheros 5004 based card /CM-9/ theEurope (ETSI) 13 Channels : 2.412GHz~2.472GHz 13 Channels : 2.412GHz~2.472GHz. in mode hostap and standard 802.11b and g. In menu is channels available,but after save don`t works. Works only channels 1-11. When change to channel 12 or 13 is made, works last used channel 1-11. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 10.9.2005 -- * www.inMail.sk - Vasa emailova adresa na cely zivot ZDARMA * www.EuropskaDomena.sk - bezplatna predregistracia domen .EU * www.ZonerPress.sk - pocitacova literatura, zameranie na webdesign a grafiku
[pfSense Support] extra '!' in NOT rules
I've got an interesting bug to report... i'm not sure if my rules logic is smart from a best-practices standpoint (suggestions welcome) but i have 4 NICs in my pfSense box: LAN (rl2), WAN (rl1), DMZ0 (rl0 = opt1), and VOIP (ep0 = opt2). All are realtek chips except VOIP which is an old ISA 3com 10baseT. I just a few moments ago realized a fatal flaw in my plan to give my vonage router its own interface in that pfSense just now informed me that the old 3com nic's driver doesnt support AltQ (doh!) but that has no bearing on this issue. my strategy was to make rules that would allow the DMZ and VOIP interfaces full access out to the internet but no access to each other or the LAN interface (pretty standard setup really) but LAN int can go anywhere. So I made some rules stating the following on the DMZ0 interface: -Allow all outbound ports/protocols on DMZ0 that is not destined for the LAN subnet. (this one works fine) -Allow all outbound ports/protocols on DMZ0 that is not destined for the VOIP subnet. (this one generates an error) then i got a parsing error from pfsense in the system log, reason for which is obvious below. (email me direct if you want the uncensored version of the subnets or any other somewhat security sensitive debug info). notice the extra '!' in the rules below (from /tmp/rules.debug): pass in quick on $VOIP from 10.x.x.x/30 to !192.168.x.x/24 keep state label "USER_RULE: Allow ALL outbound traffic except to LAN subnet" pass in quick on $VOIP from 10.x.x.x/30 to ! !10.y.y.y/24 keep state label "USER_RULE: Allow ALL outbound traffic except to LAN subnet" pass in quick on $DMZ0 from any to !192.168.x.x/24 keep state label "USER_RULE: Allow ALL outbound traffic except to LAN subnet" pass in quick on $DMZ0 from any to ! !10.x.x.x/30 keep state label "USER_RULE: Allow ALL outbound traffic except to OPT2 subnet" pass in quick on $lan proto tcp from 192.168.x.x/24 to any flags S/SA synproxy state queue (qLANdef, qLANacks) label "USER_RULE: Default LAN - any" i hope thats enough info for you to debug... let me know if you are unable to reproduce. btw, i installed with 80.2 and updated to 82.4 if that makes a difference. oh and also i have the same bug i noticed someone else mention where my WAN interface always shows DHCP to be down even though its not. Hitting "renew" works fine and shows it properly for a little while but it always goes back to being down... This is strictly cosmetic as I have no issues on that interface and although its DHCP my ISP (comcast) does some kind of MAC registration so as to stop us from pulling multiple real IP addies, so my WAN IP will never change really unless I swap NICs or change the MAC. TIA, mOjO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] extra '!' in NOT rules
oh... just noticed the new release.. will try that and get back to you guys on this... mOjO wrote: I've got an interesting bug to report... i'm not sure if my rules logic is smart from a best-practices standpoint (suggestions welcome) but i have 4 NICs in my pfSense box: LAN (rl2), WAN (rl1), DMZ0 (rl0 = opt1), and VOIP (ep0 = opt2). All are realtek chips except VOIP which is an old ISA 3com 10baseT. I just a few moments ago realized a fatal flaw in my plan to give my vonage router its own interface in that pfSense just now informed me that the old 3com nic's driver doesnt support AltQ (doh!) but that has no bearing on this issue. my strategy was to make rules that would allow the DMZ and VOIP interfaces full access out to the internet but no access to each other or the LAN interface (pretty standard setup really) but LAN int can go anywhere. So I made some rules stating the following on the DMZ0 interface: -Allow all outbound ports/protocols on DMZ0 that is not destined for the LAN subnet. (this one works fine) -Allow all outbound ports/protocols on DMZ0 that is not destined for the VOIP subnet. (this one generates an error) then i got a parsing error from pfsense in the system log, reason for which is obvious below. (email me direct if you want the uncensored version of the subnets or any other somewhat security sensitive debug info). notice the extra '!' in the rules below (from /tmp/rules.debug): pass in quick on $VOIP from 10.x.x.x/30 to !192.168.x.x/24 keep state label "USER_RULE: Allow ALL outbound traffic except to LAN subnet" pass in quick on $VOIP from 10.x.x.x/30 to ! !10.y.y.y/24 keep state label "USER_RULE: Allow ALL outbound traffic except to LAN subnet" pass in quick on $DMZ0 from any to !192.168.x.x/24 keep state label "USER_RULE: Allow ALL outbound traffic except to LAN subnet" pass in quick on $DMZ0 from any to ! !10.x.x.x/30 keep state label "USER_RULE: Allow ALL outbound traffic except to OPT2 subnet" pass in quick on $lan proto tcp from 192.168.x.x/24 to any flags S/SA synproxy state queue (qLANdef, qLANacks) label "USER_RULE: Default LAN - any" i hope thats enough info for you to debug... let me know if you are unable to reproduce. btw, i installed with 80.2 and updated to 82.4 if that makes a difference. oh and also i have the same bug i noticed someone else mention where my WAN interface always shows DHCP to be down even though its not. Hitting "renew" works fine and shows it properly for a little while but it always goes back to being down... This is strictly cosmetic as I have no issues on that interface and although its DHCP my ISP (comcast) does some kind of MAC registration so as to stop us from pulling multiple real IP addies, so my WAN IP will never change really unless I swap NICs or change the MAC. TIA, mOjO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
