Hi,
[just replying to a random mail of one of the various NAT-T threads
at this point]
I had started to review the code (to find some problems people had
with the patch) and came up with the following so far. This work
was done based on the old freebsd6-natt.diff which is no longer
available:(
On Fri, Sep 15, 2006 at 09:24:03AM +, Bjoern A. Zeeb wrote:
> Hi,
Hi.
> [just replying to a random mail of one of the various NAT-T threads
> at this point]
>
> I had started to review the code (to find some problems people had
> with the patch) and came up with the following so far. This
Julian Elischer wrote:
Forgot to mention: 4.7-PRERELEASE :(
ugh... no tables
and 45000 lines will be bad.
load an old PC with 6.2
and seet it up as a bridge with 2 interfaces.
and use ipfw table to filter on the bridge
If I could have easy access to the box, that would be the sollution. Bu
Willem Jan Withagen wrote:
> Julian Elischer wrote:
> > > Forgot to mention: 4.7-PRERELEASE :(
> >
> > ugh... no tables
> > and 45000 lines will be bad.
Not necessarily ...
> Over that time I collected over 50.000 IP's which all ended up
> in IPFW. :) The box (PIII, 750 Mhz, 512Mb) starte
On Thu, Sep 14, 2006 at 09:43:38PM -0400, Scott Ullrich wrote:
> On 9/14/06, Larry Baird <[EMAIL PROTECTED]> wrote:
> > Please find attached two patches for adding FAST_IPSEC NAT-T support to
> > FreeBSD 6.x. The patch "freebsd6-fastipsec-natt.diff" is dependent
> > upon Yvan's IPSEC NAT-T patch "
On Wed, Sep 13, 2006 at 03:09:56PM +0200, Slawek Zak wrote:
S> I'm testing network failover on IBM BladeCenter running FreeBSD 6.1
S> STABLE for Sep 6th.
S>
S> I suspect a problem with link state change detection in bge code. When
S> I disable internal port on chassis built-in ethernet switch, ker
On Mon, Sep 11, 2006 at 02:02:58PM -0700, Jack Vogel wrote:
J> In the last attempt to merge community CVS with Intel internal code I
J> came across an issue I'd like to bring up.
J>
J> There is an ancient e1000 card, pci id 1000, an 82542, that we
J> don't have in our source, yet community cvs sti
> You have tested with a GENERIC kernel? You should remove all
> debugging kernel options before testing performance.
Sure. Removing debug I got:
Kernel UP
Timecounter queries/s
--- -
TSC 16541
There is no difference.
--
Att.,
Marcelo Gardini
_
Oliver Fromme wrote:
Willem Jan Withagen wrote:
> Julian Elischer wrote:
> > > Forgot to mention: 4.7-PRERELEASE :(
> >
> > ugh... no tables
> > and 45000 lines will be bad.
Not necessarily ...
> Over that time I collected over 50.000 IP's which all ended up
> in IPFW. :) The box (PIII, 750
On 9/15/06, Larry Baird <[EMAIL PROTECTED]> wrote:
On Thu, Sep 14, 2006 at 09:43:38PM -0400, Scott Ullrich wrote:
> On 9/14/06, Larry Baird <[EMAIL PROTECTED]> wrote:
> > Please find attached two patches for adding FAST_IPSEC NAT-T support to
> > FreeBSD 6.x. The patch "freebsd6-fastipsec-natt.d
Andrew Thompson wrote:
On Thu, Sep 14, 2006 at 04:23:07PM +0200, Jon Otterholm wrote:
Andrew Thompson wrote:
On Thu, Sep 14, 2006 at 10:30:21AM +0200, Jon Otterholm wrote:
Andrew Thompson wrote:
On Wed, Sep 13, 2006 at 08:19:41PM +0200, Jon Otterholm wrote:
>From
On Fri, Sep 15, 2006 at 12:07:58PM -0400, Scott Ullrich wrote:
> On 9/15/06, Larry Baird <[EMAIL PROTECTED]> wrote:
> > On Thu, Sep 14, 2006 at 09:43:38PM -0400, Scott Ullrich wrote:
> > > On 9/14/06, Larry Baird <[EMAIL PROTECTED]> wrote:
> > > > Please find attached two patches for adding FAST_IP
On 9/15/06, Larry Baird <[EMAIL PROTECTED]> wrote:
Just to be sure I understand the issue. You have a kernel built
with the FAST_IPSEC NAT-T patches but without the IPSEC_NAT_T option.
Your VPNs work but you are unable to dump your SAD entries.
No, I have it built with options IPSEC_NAT_T and
Sam Leffler wrote:
> Hans Nieser wrote:
>
>> [EMAIL PROTECTED]:~# uname -a
>> FreeBSD aphax-laptop.lan 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Thu May 11
>> 07:17:09 CEST 2006
>> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/APHAX-LAPTOP i386
>
> Are you running the iwi driver that came with 6.1-release?
On 9/15/06, Gleb Smirnoff <[EMAIL PROTECTED]> wrote:
On Mon, Sep 11, 2006 at 02:02:58PM -0700, Jack Vogel wrote:
J> In the last attempt to merge community CVS with Intel internal code I
J> came across an issue I'd like to bring up.
J>
J> There is an ancient e1000 card, pci id 1000, an 82542, that
Although it sounds silly, could you try recompiling 6.1 and 7.0 with a
non-SMP kernel and see how they perform? That would at least tell us if
it's a general performance problem in 6.x and 7.x, or if SMP is somehow
hurting performance in this case.
Mike "Silby" Silbersack
_
Not sure if I should post this here or straight to the pfSensse list.
I suspect this kind of thing is a faulty NIC but since I've not seen it
before I'm not sure:
vr0: receive error (81): rx buffer error
vr0: revieve error (0024) no buffers
vr0: receive error (81): rx buffer error
vr0: revieve
17 matches
Mail list logo