On 7/4/06, Max Laier <[EMAIL PROTECTED]> wrote:
Right, forgot about pfsync. Use this in addition. Again, only compile
tested.
No problem. That did the trick. pfSync is online and operational:
pfsync0: flags=41 mtu 2020
pfsync: syncdev: lo0 syncpeer: 224.0.0.240 maxupd: 128
Thanks!
On Tuesday 04 July 2006 02:50, Scott Ullrich wrote:
> On 6/27/06, Max Laier <[EMAIL PROTECTED]> wrote:
> > See attached, for a possible fix. Untested, so be careful.
>
> Unfortunately this patch does not help. I was able to get a trace
> prior to the patch if that would help:
> http://www.pfsense
kOn Tue, 4 Jul 2006, 02:36-0400, Scott Ullrich wrote:
> On 7/4/06, Maxim Konovalov <[EMAIL PROTECTED]> wrote:
> > How to repeat? Btw allr, lockedvnods etc are not needed there. "bt
> > full" is.
>
> # ifconfig pfsync0
> pfsync0: flags=0<> mtu 2020
>syncpeer: 224.0.0.240 maxupd: 128
> # i
On 7/4/06, Maxim Konovalov <[EMAIL PROTECTED]> wrote:
How to repeat? Btw allr, lockedvnods etc are not needed there. "bt
full" is.
# ifconfig pfsync0
pfsync0: flags=0<> mtu 2020
syncpeer: 224.0.0.240 maxupd: 128
# ifconfig pfsync0 syncdev lo0
Fatal trap 12: page fault while in kernel
On Mon, 3 Jul 2006, 20:50-0400, Scott Ullrich wrote:
> On 6/27/06, Max Laier <[EMAIL PROTECTED]> wrote:
> > See attached, for a possible fix. Untested, so be careful.
>
> Unfortunately this patch does not help. I was able to get a trace
> prior to the patch if that would help:
> http://www.pfsen
On 6/27/06, Max Laier <[EMAIL PROTECTED]> wrote:
See attached, for a possible fix. Untested, so be careful.
Unfortunately this patch does not help. I was able to get a trace
prior to the patch if that would help:
http://www.pfsense.com/~sullrich/panics/pfsync_panic_freebsd_7.txt
Scott
__
On Tuesday 27 June 2006 00:46, Maxim Konovalov wrote:
> Hi Bruce,
>
> On Sun, 14 May 2006, 14:22-, Bruce M Simpson wrote:
> > bms 2006-05-14 14:22:49 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > sys/netinet in.h ip_output.c ip_var.h
> > Log:
> > Fi
Hi Bruce,
On Sun, 14 May 2006, 14:22-, Bruce M Simpson wrote:
> bms 2006-05-14 14:22:49 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/netinet in.h ip_output.c ip_var.h
> Log:
> Fix a long-standing limitation in IPv4 multicast group membership.
>
> By
Bruce M Simpson <[EMAIL PROTECTED]> wrote:
> Something like this:
In general, you may want to appropriately initialize ip_moptions
everywhere it is allocated. E.g., a quick search for "ip_moptions"
reveals that igmp_sendpkt() inside netinet/igmp.c also may have to
be modified. Another suspect (am
Something like this:
%%%
--- ip_mroute.c.origMon May 15 09:52:41 2006
+++ ip_mroute.c Mon May 15 09:54:01 2006
@@ -2115,6 +2115,7 @@
ip_output(m, NULL, &vifp->v_route, IP_FORWARDING, NULL, NULL);
else {
struct ip_moptions imo;
+ struct in_multi *imm[2];
int e
[Cc: to Pavlin]
On Sun, May 14, 2006 at 02:22:49PM +, Bruce M Simpson wrote:
> By making the imo_membership array a dynamically allocated vector,
> this minimizes disruption to existing IPv4 multicast code. This
> change breaks the ABI for the kernel module ip_mroute.ko, and may
> caus
On Sun, May 14, 2006 at 02:22:49PM +, Bruce M Simpson wrote:
> By making the imo_membership array a dynamically allocated vector,
> this minimizes disruption to existing IPv4 multicast code. This
> change breaks the ABI for the kernel module ip_mroute.ko, and may
> cause a small amount
bms 2006-05-14 14:22:49 UTC
FreeBSD src repository
Modified files:
sys/netinet in.h ip_output.c ip_var.h
Log:
Fix a long-standing limitation in IPv4 multicast group membership.
By making the imo_membership array a dynamically allocated vector,
this minimizes d
13 matches
Mail list logo
