RE: [pfSense Support] New custom overlay option added for 3rd party builders
Where would we find out about this redistribution agreement this is the first that I have heard mentioned of it since we started with pfsense on the fork from monowall. Would love some clarification of what this means -Original Message- From: Scott Ullrich [mailto:[EMAIL PROTECTED] Sent: 13 July 2006 15:29 To: support @ pfsense. com Subject: [pfSense Support] New custom overlay option added for 3rd party builders Take a look at pfSense_local.sh which now has a entry for custom_overlay commented out. Basically this is a field that you can store the complete path to a .tgz. During the build phase if this file is found we will automatically tar extract that overlay on top of the pfSense CVS checkout. This allows third parties, etc to extend the image without having to modify pfSense builder files. Scott PS: This option is added for your convenience only. We do not support the builder system unless you have a redistribution agreement in place with us. In the past we have been pretty willing to help but be advised that in the future we will be firm with this policy. - 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]
[pfSense Support] New custom overlay option added for 3rd party builders
Take a look at pfSense_local.sh which now has a entry for custom_overlay commented out. Basically this is a field that you can store the complete path to a .tgz. During the build phase if this file is found we will automatically tar extract that overlay on top of the pfSense CVS checkout. This allows third parties, etc to extend the image without having to modify pfSense builder files. Scott PS: This option is added for your convenience only. We do not support the builder system unless you have a redistribution agreement in place with us. In the past we have been pretty willing to help but be advised that in the future we will be firm with this policy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] CARP - failover inconsistencies
On 7/13/06, Alastair Stevens <[EMAIL PROTECTED]> wrote: Hi Tom - thanks for this. I've updated my advertising frequencies, such that all interfaces on "master" are 0, and all interfaces on "backup" are 111, arbitrarily. But it's still not behaving correctly. Could this be to do with VHID groups? At the moment, each pair of interfaces shares a VHID group, in other words I have 4 different VHID groups, for the 4 pairs of interfaces. Is this the wrong way to do it? I have experimented with this before but not achieved consistent results. Each distinct IP must share a common VHID. If you have 13 distinct IP's, then you need 13 VHID's. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] CARP - failover inconsistencies
Title: RE: [pfSense Support] CARP - failover inconsistencies Hi Tom - thanks for this. I've updated my advertising frequencies, such that all interfaces on "master" are 0, and all interfaces on "backup" are 111, arbitrarily. But it's still not behaving correctly. Could this be to do with VHID groups? At the moment, each pair of interfaces shares a VHID group, in other words I have 4 different VHID groups, for the 4 pairs of interfaces. Is this the wrong way to do it? I have experimented with this before but not achieved consistent results. Cheers Alastair -Original Message- From: Tom Müller-Kortkamp [mailto:[EMAIL PROTECTED]] Sent: Thu 13/07/2006 07:30 To: support@pfsense.com Subject: Re: [pfSense Support] CARP - failover inconsistencies Am 12.07.2006 um 14:28 schrieb Alastair Stevens: > But do you know why we are seeing this asymmetric 'flapping' at > other times? I have checked all the settings, and each CARP pair > has a unique VHID, and box A is set to a lower advertising > frequency. My understanding is that the 'preempt' flag should > cause all interfaces to failover together. Hi, had the same problem with a fast Master and a WRAP for backup: Go to the Slave-Servers CARP-Settings and rise the Advertising Frequency for each CARP-Interface above 100. This should make it a real "hot-standby" Slave ... I also enabled "Load Balancing" in the CARP Settings which should enable net.inet.carp.arpbalance. Tom -- kommunity GmbH & Co.KG Tom Müller-Kortkamp Netzwerke & Internet Goseriede 4 D-30159 Hannover
Re: [pfSense Support] CARP - failover inconsistencies
Am 12.07.2006 um 14:28 schrieb Alastair Stevens: Hi - the final question I have with our current setup concerns CARP/ failover between our pair of boxes, each of which has 2 WAN and 2 LAN interfaces. What we're seeing sometimes is that box B will become "master" for the LAN interfaces, but not the WANs, or vice versa. This obviously breaks things! For a full failover simulation (ie reboot one of the boxes!) everything works correctly, and all 4 interfaces fail over to the other box, and everything carries on flowing. But do you know why we are seeing this asymmetric 'flapping' at other times? I have checked all the settings, and each CARP pair has a unique VHID, and box A is set to a lower advertising frequency. My understanding is that the 'preempt' flag should cause all interfaces to failover together. Hi, had the same problem with a fast Master and a WRAP for backup: Go to the Slave-Servers CARP-Settings and rise the Advertising Frequency for each CARP-Interface above 100. This should make it a real "hot-standby" Slave ... I also enabled "Load Balancing" in the CARP Settings which should enable net.inet.carp.arpbalance. Tom -- kommunity GmbH & Co.KG Tom Müller-Kortkamp Netzwerke & Internet Goseriede 4 D-30159 Hannover Phone +49 (0)5 11 - 80 72 58 0 Fax +49 (0)5 11 - 80 72 58 10 http://www.kommunity.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] pppoe : mpd: [pppoe0] PPPoE connection timeout after 9 seconds
The mtu on pfsense if 1492 or 1496 for the link. Not 1460 as you have entered. I have found that this problem is definitely a windows 2000/xp problem but not all the time check the boxes registry it is not setting it’s mtu correctly there. It is more likely the mru that is wrong in fact. From: juan pablo burd [mailto:[EMAIL PROTECTED] Sent: 12 July 2006 21:50 To: support@pfsense.com Subject: RE: [pfSense Support] pppoe : mpd: [pppoe0] PPPoE connection timeout after 9 seconds I am using rasspppoe De: Scott Ullrich [mailto:[EMAIL PROTECTED]] Enviado el: Miércoles, 12 de Julio de 2006 05:05 p.m. Para: support@pfsense.com Asunto: Re: [pfSense Support] pppoe : mpd: [pppoe0] PPPoE connection timeout after 9 seconds The problem is with windows 2000, not pfSense. On 7/12/06, juan pablo burd <[EMAIL PROTECTED] > wrote: I have installed pfsense, and I only have a problem with Windows 2000, i config el mtu y el mru en 1460, look for in all the forums and not find solution the error is the following one : (this error only with Windows 2000) Jul 12 13:53:35 mpd: [pppoe1] PPPoE connection timeout after 9 seconds Jul 12 13:53:35 mpd: [pppoe1] device: DOWN event in state OPENING Jul 12 13:53:35 mpd: [pppoe1] device is now in state DOWN Jul 12 13:53:35 mpd: [pppoe1] link: DOWN event Jul 12 13:53:35 mpd: [pppoe1] LCP: Down event Jul 12 13:53:35 mpd: [pppoe1] LCP: Close event Jul 12 13:53:35 mpd: [pppoe1] LCP: state change Starting --> Initial Jul 12 13:53:35 mpd: [pppoe1] LCP: LayerFinish Jul 12 13:53:35 mpd: [pppoe1] closing link "pppoe1"... Jul 12 13:53:35 mpd: [pppoe1] IPCP: Close event Jul 12 13:53:35 mpd: [pppoe1] IPCP: state change Starting --> Initial Jul 12 13:53:35 mpd: [pppoe1] IPCP: LayerFinish Jul 12 13:53:35 mpd: [pppoe1] bundle: CLOSE event in state OPENED Jul 12 13:53:35 mpd: [pppoe1] link: CLOSE event Jul 12 13:53:35 mpd: [pppoe1] LCP: Close event Jul 12 13:53:35 mpd: [pppoe1] device: CLOSE event in state DOWN Jul 12 13:53:35 mpd: [pppoe1] device is now in state DOWN Jul 12 13:53:36 mpd: Incoming PPPoE connection request via em1: for service "*" from 00:50:da:ce:07:61 De: alan walters [mailto:[EMAIL PROTECTED]] Enviado el: Martes, 11 de Julio de 2006 08:19 p.m. Para: support@pfsense.com Asunto: RE: [pfSense Support] pppoe : mpd: [pppoe0] PPPoE connection timeout after 9 seconds Well that is more specifically a question to ask Microsoft. I can vouch for problems with all windows clients sometimes. Some work fine some do not. I can't explain it sorry. You need to align your mru and mtu settings . particularly the mru From: juan pablo burd [mailto:[EMAIL PROTECTED]] Sent: 11 July 2006 23:57 To: support@pfsense.com Subject: [pfSense Support] pppoe : mpd: [pppoe0] PPPoE connection timeout after 9 seconds This error only ocurred in Windows 2000 profesional / Server …… why Error in pfsense pppoe Server log file is : mpd: [pppoe0] PPPoE connection timeout after 9 seconds In connection Windows 2000 (Rasspppoe) : error 678 Please help me ……. __ Informacisn de NOD32, revisisn 1.1655 (20060712) __ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com
