VANHULLEBUS Yvan wrote:
On Mon, Jul 21, 2008 at 08:33:57AM -0700, Sam Leffler wrote:
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 ret
Bjoern A. Zeeb wrote:
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
On Mon, Jul 21, 2008 at 08:33:57AM -0700, Sam Leffler wrote:
> 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.
> 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
> 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 n
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
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,
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 onl
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)
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 th
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 m
[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
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 th
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 the
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
Sam,
> The main difference from the patches floating around are in the
> ctloutput path (adding proper locking for HEAD) and decap of ESP-in-UDP
> frames. Assuming folks are ok w/ these changes I'll commit to HEAD.
> Once this stuff goes in we can look at getting the user-mode mods into
> th
On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
> This adds only the kernel portion of the NAT-T support; you must provide
> the user-level code from another place.
Note for people who are interested:
user-level code comes from ipsec-tools, as for previous versions of
the NAT-T pa
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
For those who may be interested,I ported Sam's changes to FreeBSD7,
the patch is here:
http://people.freebsd.org/~vanhu
Sam,
> 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 the patches floating around ar
Sam Leffler wrote:
Larry Baird wrote:
And how do I know that it works ?
Well, when it doesn't work, I do know it, quite quickly most of the
time !
I have to chime in here. I did most of the initial porting of the
NAT-T patches from Kame IPSec to FAST_IPSEC. I did look at every
line of co
20 matches
Mail list logo
