On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
[...]
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
I have tested the RELENG7 version of the patch, and it works well.
But I noticed a misplaced #endif at the beginning of
On Wed, 16 Jul 2008, Sam Leffler wrote:
Hi,
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
This adds only the kernel portion of the NAT-T support; you must provide the
user-level code from another place.
The main difference from
Old Synopsis: carp stuck in init when using bridge interface
New Synopsis: [carp] [bridge] carp stuck in init when using bridge interface
Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Mon Jul 21 13:53:12 UTC 2008
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
[...]
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
I have tested the RELENG7 version of the patch,
[Larry, I kept you in an explicit CC, even if I guess you suscribed to
the list]
On Mon, Jul 21, 2008 at 09:26:15AM +, Bjoern A. Zeeb wrote:
On Wed, 16 Jul 2008, Sam Leffler wrote:
Hi,
Hi.
[...]
My main concern at the moment is the API (pfkey stuff) to userland as
Yvan had stated in
Bjoern A. Zeeb wrote:
On Wed, 16 Jul 2008, Sam Leffler wrote:
Hi,
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
This adds only the kernel portion of the NAT-T support; you must
provide the user-level code from another place.
The
VANHULLEBUS Yvan wrote:
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
[...]
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
I have tested
VANHULLEBUS Yvan wrote:
[Larry, I kept you in an explicit CC, even if I guess you suscribed to
the list]
On Mon, Jul 21, 2008 at 09:26:15AM +, Bjoern A. Zeeb wrote:
On Wed, 16 Jul 2008, Sam Leffler wrote:
Hi,
Hi.
[...]
My main concern at the moment is the API (pfkey stuff)
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
After some more testing, I found another issue: in udp4_espdecap(),
when payload = sizeof(uint64_t) + sizeof(struct esp), packet should
not be discarded, but just returned for normal processing.
I noticed this too. But the
On Mon, Jul 21, 2008 at 01:27:05PM -0500, Matthew Grooms wrote:
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
After some more testing, I found another issue: in udp4_espdecap(),
when payload = sizeof(uint64_t) + sizeof(struct esp), packet should
not be discarded, but just
On Mon, 21 Jul 2008, Sam Leffler wrote:
Hi Sam,
We are still missing other things I think not mentioned elswhere like
partial checksum recalculation.
Please send me your specific issues; I haven't seen any comments about
partial checksum recalculations.
So what has kept you from reading
Hi,
maybe this question is better asked in this list ...
I was searching why ports/net/p5-Net-Interface was not working as
expected and found some reasons. Most of them I can answer by implementing
some test code as attached, but now I'm wondering why em0 is shown twice
and lo0 is not included.
Hi,
maybe this question is better asked in this list ...
I was searching why ports/net/p5-Net-Interface was not working as
expected and found some reasons. Most of them I can answer by implementing
some test code as attached, but now I'm wondering why em0 is shown twice
and lo0 is not
On Mon, Jul 21, 2008 at 10:36 AM, David Christensen
[EMAIL PROTECTED] wrote:
I'm working on implementing multi-queue support for a 10Gb
device on FreeBSD and I wanted to find out the current state
of the OS with regards to supporting this. It seems that
support for multiple receive queues can
Brooks Davis wrote:
Hi,
maybe this question is better asked in this list ...
I was searching why ports/net/p5-Net-Interface was not working as
expected and found some reasons. Most of them I can answer by implementing
some test code as attached, but now I'm wondering why em0 is shown twice
and
On Mon, Jul 21, 2008 at 09:30:39PM +, Jens Rehsack wrote:
Brooks Davis wrote:
Hi,
maybe this question is better asked in this list ...
I was searching why ports/net/p5-Net-Interface was not working as
expected and found some reasons. Most of them I can answer by implementing
some
Brooks Davis wrote:
On Mon, Jul 21, 2008 at 09:30:39PM +, Jens Rehsack wrote:
Brooks Davis wrote:
Hi,
maybe this question is better asked in this list ...
I was searching why ports/net/p5-Net-Interface was not working as
expected and found some reasons. Most of them I can answer by
On Mon, Jul 21, 2008 at 10:36:34PM +, Jens Rehsack wrote:
Brooks Davis wrote:
On Mon, Jul 21, 2008 at 09:30:39PM +, Jens Rehsack wrote:
Brooks Davis wrote:
Hi,
maybe this question is better asked in this list ...
I was searching why ports/net/p5-Net-Interface was not working as
I noticed this too. But the only situation that I could think of where a
valid ISAKMP packet will be smaller than this is a NAT-T keep-alive.
These are handled previously in the code path so I don't think there is
an issue from a functional standpoint.
That's what I also supposed when I
We are still missing other things I think not mentioned elswhere like
partial checksum recalculation.
Please send me your specific issues; I haven't seen any comments about
partial checksum recalculations.
I've never heard of this term used before with regard to NAT-T ( and
neither has
Old Synopsis: tcp_lro_rx() should make use of hardware IP cksum assistance when
available
New Synopsis: [netinet] [patch] tcp_lro_rx() should make use of hardware IP
cksum assistance when available
Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: linimon
21 matches
Mail list logo
