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 commit
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 the
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 folks react
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, that is true.
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?
No. Before
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 DESCRIPTION
The
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 -STABLE
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 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
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]
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 mention that
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
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 to
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,
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
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
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
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
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 base
20 matches
Mail list logo
