Kris Kennaway wrote:
> On Tue, 11 Jul 2000, Ben Smithurst wrote:
>
>> 'pseudo-device stf' gives an error, stf lives in the gif driver, so this
>> is required really. Is that ok? Is there anyone at KAME I should send
>> this to as well?
>
> Um, "device stf" certainly does work.
Ah. I'm using
On Tue, 11 Jul 2000, Ben Smithurst wrote:
> I'd like to commit this:
>
> --- stf.4 2000/07/04 16:39:23 1.4
> +++ stf.4 2000/07/11 13:44:47
> @@ -36,7 +36,7 @@
> .Nd
> .Tn 6to4 tunnel interface
> .Sh SYNOPSIS
> -.Cd "pseudo-device stf"
> +.Cd "pseudo-device gif"
> .Sh DESCRIPT
Hajimu UMEMOTO wrote:
>> On Tue, 11 Jul 2000 14:56:35 +0100
>> Ben Smithurst <[EMAIL PROTECTED]> said:
>
> ben> 'pseudo-device stf' gives an error, stf lives in the gif driver, so this
> ben> is required really. Is that ok? Is there anyone at KAME I should send
> ben> this to as well?
> On Tue, 11 Jul 2000 14:56:35 +0100
> Ben Smithurst <[EMAIL PROTECTED]> said:
ben> 'pseudo-device stf' gives an error, stf lives in the gif driver, so this
ben> is required really. Is that ok? Is there anyone at KAME I should send
ben> this to as well?
No. Before merging latest KAME,
Sheldon Hearn wrote:
> On Tue, 11 Jul 2000 14:56:35 +0100, Ben Smithurst wrote:
>
>> 'pseudo-device stf' gives an error, stf lives in the gif driver, so this
>> is required really. Is that ok? Is there anyone at KAME I should send
>> this to as well?
>
> I'm interested to see how the KAME fol
On Tue, 11 Jul 2000 14:56:35 +0100, Ben Smithurst wrote:
> 'pseudo-device stf' gives an error, stf lives in the gif driver, so this
> is required really. Is that ok? Is there anyone at KAME I should send
> this to as well?
I'm interested to see how the KAME folks react to our chucking out th
Kris Kennaway wrote:
> In this vein, I'd like to suggest a new "hands-off" policy of not
> committing gratuitous changes to KAME-derived code, including manpage
> changes, unless:
>
> a) The commit is required for operation on FreeBSD (in which case it's not
> really gratuitous)
I'd like to com
> > Could you mention the locations (as in a set of paths) that are
> > hands-off?
>
> I'll generate a list and put it somewhere (in the tree?) Good idea.
To be honest, I was more thinking of the heads up message. But it was
suggested to add it to the readme in netinet6/
Nick
--
[EMAIL PROTECTE
On Wed, 5 Jul 2000, Robert Watson wrote:
>
> This is great news -- one of the big hangups in our interop testing at NAI
> Labs was the like of IKE on FreeBSD. I notice that right now racoon is a
> port -- assuming this interpretation is correct, are their any plans to
> integrate racoon as a ba
On Wed, 5 Jul 2000, Nick Hibma wrote:
> Could you mention the locations (as in a set of paths) that are
> hands-off?
I'll generate a list and put it somewhere (in the tree?) Good idea.
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTE
>This is great news -- one of the big hangups in our interop testing at NAI
>Labs was the like of IKE on FreeBSD. I notice that right now racoon is a
>port -- assuming this interpretation is correct, are their any plans to
>integrate racoon as a base system component? As you point out, without
This is great news -- one of the big hangups in our interop testing at NAI
Labs was the like of IKE on FreeBSD. I notice that right now racoon is a
port -- assuming this interpretation is correct, are their any plans to
integrate racoon as a base system component? As you point out, without
IKE,
>Could you mention the locations (as in a set of paths) that are
>hands-off?
thanks for your understanding,
will try to list those and put the list into sys/netinet6/README.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
Could you mention the locations (as in a set of paths) that are
hands-off?
Nick
On Wed, 5 Jul 2000, Kris Kennaway wrote:
> As itojun has already posted, we are in the process of updating the
> KAME IPv6/IPSEC code in FreeBSD to the latest KAME sources.
>
> In importing the latest KAME code, we
>These changes should only impact ipv6 and ipsec, with the exception of the
>DNS resolver code which I'm still unsure about merging (even though it's
>been well tested by KAME users, there remains the possibility of breakage
>for ipv4 resolution if there are undiscovered bugs)
actually,
On Wed, 5 Jul 2000, Samuel Tardieu wrote:
> On 5/07, Kris Kennaway wrote:
>
> | I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any
> | problems, so this means we need everyone who is capable of doing so to
> | stress the new code as much as possible. IMO we *really* need
On 5/07, Kris Kennaway wrote:
| I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any
| problems, so this means we need everyone who is capable of doing so to
| stress the new code as much as possible. IMO we *really* need to get this
| into 4.1 despite the relatively short t
On Wed, 5 Jul 2000, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Kri
> s Kennaway writes:
>
> >I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any
> >problems,
>
> I'm sorry, but isn't that a tad fast, considering the scope of these
> changes ?
I forgot to m
In message <[EMAIL PROTECTED]>, Kri
s Kennaway writes:
>I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any
>problems,
I'm sorry, but isn't that a tad fast, considering the scope of these
changes ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
As itojun has already posted, we are in the process of updating the
KAME IPv6/IPSEC code in FreeBSD to the latest KAME sources.
In importing the latest KAME code, we are not being too concerned about
whitespace or cosmetic diffs, unifdef'ing __NetBSD__ sections (at least in
userland) and so forth
20 matches
Mail list logo
