Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Eygene Ryabinkin rea-f...@codelabs.ru writes: Dag-Erling Smørgrav d...@des.no writes: Eygene Ryabinkin rea-f...@codelabs.ru writes: Perhaps 'XXX for direnter()' should be changed to something like 'strip trailing slashes in cnp-cn_nameptr'. I'll just remove it, since the previous comment clearly explains what is going on. May be it's better to leave the comment, but replace it with more undestandable one: this instruction is a bit tricky and it makes one to think what the hell is going on. Isn't it clearly described in the preceding comment? Specifically, by the first two sentences: Replace multiple slashes by a single slash and trailing slashes by a null. This must be done before VOP_LOOKUP() because some fs's don't know about trailing slashes. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Wed, Jun 03, 2009 at 11:03:45AM +0200, Dag-Erling Sm??rgrav wrote:
Isn't it clearly described in the preceding comment? Specifically, by
the first two sentences: Replace multiple slashes by a single slash and
trailing slashes by a null. This must be done before VOP_LOOKUP()
because some fs's don't know about trailing slashes.
Yes, it is clearly described. But I started to understand this
description only after asking myself what ndp-ni_next is doing here
and why do we want to place '\0' to this address? I could be a bit
stupid, yeah ;)) But this code snippet can be a bit hard to read for
others as well. May be not -- can't say for sure.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Dag-Erling, good day.
Fri, May 29, 2009 at 06:58:08PM +0200, Dag-Erling Sm??rgrav wrote:
Index: sys/kern/vfs_lookup.c
===
--- sys/kern/vfs_lookup.c (revision 193028)
+++ sys/kern/vfs_lookup.c (working copy)
@@ -454,7 +454,6 @@
int docache;/* == 0 do not cache last component */
int wantparent; /* 1 = wantparent or lockparent flag */
int rdonly; /* lookup read-only flag bit */
- int trailing_slash;
int error = 0;
int dpunlocked = 0; /* dp has already been unlocked */
struct componentname *cnp = ndp-ni_cnd;
@@ -529,12 +528,10 @@
* trailing slashes to handle symlinks, existing non-directories
* and non-existing files that won't be directories specially later.
*/
- trailing_slash = 0;
while (*cp == '/' (cp[1] == '/' || cp[1] == '\0')) {
cp++;
ndp-ni_pathlen--;
if (*cp == '\0') {
- trailing_slash = 1;
*ndp-ni_next = '\0'; /* XXX for direnter() ... */
cnp-cn_flags |= TRAILINGSLASH;
}
@@ -711,7 +708,7 @@
error = EROFS;
goto bad;
}
- if (*cp == '\0' trailing_slash
+ if (*cp == '\0' (cnp-cn_flags TRAILINGSLASH)
!(cnp-cn_flags WILLBEDIR)) {
For the current code state, check *cp == '\0' seems to be redundant:
VOP_LOOKUP had failed at this point and we're running with EJUSTRETURN.
And EJUSTRETURN can happen only if ISLASTCN is set, that in turn implies
that *ndp-ni_next is 0 and ndp-ni_next is equal to the cp.
Seems like this change makes symlink behavior more consistent: if any
previous component had a trailing slash, then we will bail out unless
we intend to create/rename directory.
By the way, comment before the test if (rdonly)' seems to be slightly
misleading: we could be not only creating the file but could be renaming
at this point as well. Perhaps 'creating' should be changed to
'creating/renaming'.
error = ENOENT;
goto bad;
@@ -788,7 +785,7 @@
* Check for symbolic link
*/
if ((dp-v_type == VLNK)
- ((cnp-cn_flags FOLLOW) || trailing_slash ||
+ ((cnp-cn_flags FOLLOW) || (cnp-cn_flags TRAILINGSLASH) ||
*ndp-ni_next == '/')) {
cnp-cn_flags |= ISSYMLINK;
if (dp-v_iflag VI_DOOMED) {
Seems like here we can also check for the trailing slash to be set on
any previous invocation (or the current one), since we're following
symlinks in the case of directories, so we should follow them to the
end.
BTW, what does the XXX for direnter() comment mean?
It means that the trailing slashes are eliminated because direnter() for
some FSes may choke on it. It essentially duplicates the chunk of a big
comment before the block. 'ngp-ni_next' is set to 'cp' before the
block and at that time 'cp' points to a slash that delimits directories
or null character that terminates non-slashed name.
Perhaps 'XXX for direnter()' should be changed to something like
'strip trailing slashes in cnp-cn_nameptr'.
By the way, comment just after 'nextname' label is misleading: we can be
there with symbolic link, but it won't be followed. So Not a symbolic
link can be changed to something like Not a symbolic link that will
be followed.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Eygene Ryabinkin rea-f...@codelabs.ru writes: For the current code state, check *cp == '\0' seems to be redundant: [...] By the way, comment before the test if (rdonly)' seems to be slightly misleading [...] OK, I see that. I've removed the check and rewritten the comment. What about this temporary assert? /* * This is a temporary assert to make sure I know what the * behavior here was. */ KASSERT((cnp-cn_flags (WANTPARENT|LOCKPARENT)) != 0, (lookup: Unhandled case.)); It was added by jeff@ four years ago, with the following log message: - Add a few asserts for some unusual conditions that I do not believe can happen. These will later go away and turn into implementations for these conditions. Any reason not to remove it? Seems like here we can also check for the trailing slash to be set on any previous invocation (or the current one), since we're following symlinks in the case of directories, so we should follow them to the end. I'm not sure I understand... Perhaps 'XXX for direnter()' should be changed to something like 'strip trailing slashes in cnp-cn_nameptr'. I'll just remove it, since the previous comment clearly explains what is going on. By the way, comment just after 'nextname' label is misleading: we can be there with symbolic link, but it won't be followed. So Not a symbolic link can be changed to something like Not a symbolic link that will be followed. /* * Not a symbolic link that we will follow. Continue with the * next component if there is any; otherwise, we're done. */ DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Bruce Evans b...@zeta.org.au writes:
This comment could do with some rewording to emphasize inheritance of the
flag and to improve the grammar of the comment.
Suggestions? For reference, here's the entire comment:
/*
* Replace multiple slashes by a single slash and trailing slashes
* by a null. This must be done before VOP_LOOKUP() because some
* fs's don't know about trailing slashes. Remember if there were
* trailing slashes to handle symlinks, existing non-directories
* and non-existing files that won't be directories specially later.
*/
-if (*cp == '\0' trailing_slash
+if (*cp == '\0' (cnp-cn_flags TRAILINGSLASH)
!(cnp-cn_flags WILLBEDIR)) {
error = ENOENT;
goto bad;
Try replacing *cp == '\0' by (cnp-cn_flags ISLASTCN) and maybe combine
the flags tests. Apparently I hacked in the *cp test because I didn't
quite understand ISLASTCN.
Is the test necessary at all? Cf. Eygene's comment.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Tue, Jun 02, 2009 at 01:28:34PM +0200, Dag-Erling Sm??rgrav wrote:
Eygene Ryabinkin rea-f...@codelabs.ru writes:
For the current code state, check *cp == '\0' seems to be redundant:
[...] By the way, comment before the test if (rdonly)' seems to be
slightly misleading [...]
OK, I see that. I've removed the check and rewritten the comment.
Thanks.
What about this temporary assert?
/*
* This is a temporary assert to make sure I know what the
* behavior here was.
*/
KASSERT((cnp-cn_flags (WANTPARENT|LOCKPARENT)) != 0,
(lookup: Unhandled case.));
It is partly handled at the beginning of lookup:
-
wantparent = cnp-cn_flags (LOCKPARENT | WANTPARENT);
KASSERT(cnp-cn_nameiop == LOOKUP || wantparent,
(CREATE, DELETE, RENAME require LOCKPARENT or WANTPARENT.));
-
So, only LOOKUP could have both {LOCK,WANT}PARENT to be unset. And it
seems to be fine, because LOOKUP shouldn't care about parent vnode,
either locked or just referenced. So this assertion seems to be really
redundant.
Seems like here we can also check for the trailing slash to be set on
any previous invocation (or the current one), since we're following
symlinks in the case of directories, so we should follow them to the
end.
I'm not sure I understand...
I meant the following: you're trading 'trailing_slash' to the
TRAILINGSLASH. The former is local to this call of lookup(), the latter
persists throughout the namei() invocation, so it could be set by the
previous lookup() calls. But this seems to be fine: since we were
started to look for directory at some point, we should continue to do
it.
Perhaps 'XXX for direnter()' should be changed to something like
'strip trailing slashes in cnp-cn_nameptr'.
I'll just remove it, since the previous comment clearly explains what is
going on.
May be it's better to leave the comment, but replace it with more
undestandable one: this instruction is a bit tricky and it makes one to
think what the hell is going on.
By the way, comment just after 'nextname' label is misleading: we can be
there with symbolic link, but it won't be followed. So Not a symbolic
link can be changed to something like Not a symbolic link that will
be followed.
/*
* Not a symbolic link that we will follow. Continue with the
* next component if there is any; otherwise, we're done.
*/
Yes, very good.
Thanks.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Bruce Evans b...@zeta.org.au writes:
Dag-Erling Smørgrav d...@des.no writes:
% Index: sys/kern/vfs_lookup.c
% ===
% --- sys/kern/vfs_lookup.c (revision 192899)
% +++ sys/kern/vfs_lookup.c (working copy)
% @@ -147,6 +147,9 @@
% cnp-cn_flags = ~LOCKSHARED;
% fdp = p-p_fd;
% % + /* We will set this ourselves if we need it. */
% + cnp-cn_flags = ~TRAILINGSLASH;
% +
Can TRAILINGSLASH ever be set here? Is namei() ever called recursively?
suspenders and a belt
It is hypothetically possible for the caller to have set it.
% /*
% * Get a buffer for the name to be translated, and copy the
% * name into the buffer.
% @@ -533,6 +536,8 @@
% if (*cp == '\0') {
% trailing_slash = 1;
I thought at first that this flag can go away.
I intend to remove it later - I just wanted to get the bug fixed first.
I'm happy to hear that removing it will fix the two bugs introduced by
the patch I committed :)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
How's this?
Index: sys/kern/vfs_lookup.c
===
--- sys/kern/vfs_lookup.c (revision 193028)
+++ sys/kern/vfs_lookup.c (working copy)
@@ -454,7 +454,6 @@
int docache;/* == 0 do not cache last component */
int wantparent; /* 1 = wantparent or lockparent flag */
int rdonly; /* lookup read-only flag bit */
- int trailing_slash;
int error = 0;
int dpunlocked = 0; /* dp has already been unlocked */
struct componentname *cnp = ndp-ni_cnd;
@@ -529,12 +528,10 @@
* trailing slashes to handle symlinks, existing non-directories
* and non-existing files that won't be directories specially later.
*/
- trailing_slash = 0;
while (*cp == '/' (cp[1] == '/' || cp[1] == '\0')) {
cp++;
ndp-ni_pathlen--;
if (*cp == '\0') {
- trailing_slash = 1;
*ndp-ni_next = '\0'; /* XXX for direnter() ... */
cnp-cn_flags |= TRAILINGSLASH;
}
@@ -711,7 +708,7 @@
error = EROFS;
goto bad;
}
- if (*cp == '\0' trailing_slash
+ if (*cp == '\0' (cnp-cn_flags TRAILINGSLASH)
!(cnp-cn_flags WILLBEDIR)) {
error = ENOENT;
goto bad;
@@ -788,7 +785,7 @@
* Check for symbolic link
*/
if ((dp-v_type == VLNK)
- ((cnp-cn_flags FOLLOW) || trailing_slash ||
+ ((cnp-cn_flags FOLLOW) || (cnp-cn_flags TRAILINGSLASH) ||
*ndp-ni_next == '/')) {
cnp-cn_flags |= ISSYMLINK;
if (dp-v_iflag VI_DOOMED) {
BTW, what does the XXX for direnter() comment mean?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Fri, May 29, 2009 at 06:53:22PM +0200, Dag-Erling Sm??rgrav wrote:
Bruce Evans b...@zeta.org.au writes:
% /*
%* Get a buffer for the name to be translated, and copy the
%* name into the buffer.
% @@ -533,6 +536,8 @@
% if (*cp == '\0') {
% trailing_slash = 1;
I thought at first that this flag can go away.
I intend to remove it later - I just wanted to get the bug fixed first.
I'm happy to hear that removing it will fix the two bugs introduced by
the patch I committed :)
What are those bugs?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
On Tuesday 26 May 2009 23:20:01 Dag-Erling Smørgrav wrote: Dag-Erling Smørgrav d...@des.no writes: Like bde@ pointed out, the patch is incorrect. It moves the test for v_type != VDIR up to a point where, in the case of a symlink, v_type is always (by definition) VLNK. Hmm, actually, symlinks are resolved in namei(), not lookup(). This is not going to be pretty. I'll be back later... I don't pretend to comprehend the kernel side of things fully, but wouldn't it be easier to append a dot to all trailing slashes inside or before passing to namei? This works in userland at present and lighttpd could use something similar as a work around until it's fixed: % echo this is foo foo % ln -fs foo bar % cat bar/ this is foo % cat bar/. cat: bar/.: Not a directory -- Mel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Mel, good day.
Thu, May 28, 2009 at 11:07:12AM +0200, Mel Flynn wrote:
On Tuesday 26 May 2009 23:20:01 Dag-Erling Sm??rgrav wrote:
Dag-Erling Sm??rgrav d...@des.no writes:
Like bde@ pointed out, the patch is incorrect. It moves the test for
v_type != VDIR up to a point where, in the case of a symlink, v_type is
always (by definition) VLNK.
Hmm, actually, symlinks are resolved in namei(), not lookup(). This is
not going to be pretty. I'll be back later...
I don't pretend to comprehend the kernel side of things fully, but
wouldn't it be easier to append a dot to all trailing slashes inside
or before passing to namei?
A dirty hack that puts some additional burden on the namei() ;-/
This works in userland at present and lighttpd could use something
similar as a work around until it's fixed:
Yes, this will work, but it is better to apply the real fix ;)) Dirty
hacks aren't good at the long timescales -- they tend to obfuscate the
code and put unneeded interprocedure constraints (you should prepend dot
to the slash if you want to call namei()/we should add dot to slash to
make our life easier/etc).
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Dag-Erling, *, good day.
Tue, May 26, 2009 at 10:13:21PM +0200, Dag-Erling Sm??rgrav wrote:
[moving from security@ to hack...@]
Jakub Lach jakub_l...@mailplus.pl writes:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768
Like bde@ pointed out, the patch is incorrect. It moves the test for
v_type != VDIR up to a point where, in the case of a symlink, v_type is
always (by definition) VLNK.
The reason why the current code does not work is that, in the symlink
case, the v_type != VDIR test is never reached: we will have jumped to
either bad2 or success. However, it should be safe to move the test to
after the success label, because trailing_slash is only ever true for
the last component of the path we were asked to look up (see lines 520
through 535).
May be the attached patch will fix the thing? It works for me for 7.2
with WITNESS and INVARIANTS enabled. It adds an additional flag, but
this was the only thing I was able to invent to avoid ABI breakage.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From 029b779c2fe005fe0d043fb3f1990957927e6a18 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin rea-f...@codelabs.ru
Date: Wed, 27 May 2009 13:13:16 +0400
Subject: [PATCH] vfs lookups: properly handle the case of slash at the end of symlink
If symlink points to a non-directory object but the name has trailing
slash, then the current lookup/namei implementation will dereference
symlink and return dereferenced object instead of symlink even if
NOFOLLOW mode is used. That's not good at all :((
Simple test:
-
$ ln -s /etc/motd file
$ file file
file: symbolic link to `/etc/motd'
[ == Unpatched variant == ]
$ file file/
file/: ASCII English text
[ == Patched variant == ]
$ file file/
file/: cannot open `file/' (Not a directory)
-
See also: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768
See also: http://lists.freebsd.org/pipermail/freebsd-security/2009-May/005219.html
Signed-off-by: Eygene Ryabinkin rea-f...@codelabs.ru
---
sys/kern/vfs_lookup.c | 25 +
sys/sys/namei.h | 41 +
2 files changed, 38 insertions(+), 28 deletions(-)
diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
index 3770b55..75b1772 100644
--- a/sys/kern/vfs_lookup.c
+++ b/sys/kern/vfs_lookup.c
@@ -138,6 +138,9 @@ namei(struct nameidata *ndp)
cnp-cn_flags = ~LOCKSHARED;
fdp = p-p_fd;
+ /* Drop internal flag: we will set it ourselves if we'll need it. */
+ cnp-cn_flags = ~SLASHSYMLINK;
+
/*
* Get a buffer for the name to be translated, and copy the
* name into the buffer.
@@ -683,6 +686,12 @@ unionlookup:
ndp-ni_vp = dp = tdp;
}
+ /* Set slashed symlink flag if we found slash at the end of symlink */
+ if (dp-v_type == VLNK trailing_slash
+ (cnp-cn_flags ISLASTCN)) {
+ cnp-cn_flags |= SLASHSYMLINK;
+ }
+
/*
* Check for symbolic link
*/
@@ -710,14 +719,6 @@ unionlookup:
goto success;
}
- /*
- * Check for bogus trailing slashes.
- */
- if (trailing_slash dp-v_type != VDIR) {
- error = ENOTDIR;
- goto bad2;
- }
-
nextname:
/*
* Not a symbolic link. If more pathname,
@@ -741,6 +742,14 @@ nextname:
goto dirloop;
}
/*
+ * Check if we're processing slashed symlink and
+ * lookup target isn't a directory.
+ */
+ if ((cnp-cn_flags SLASHSYMLINK) dp-v_type != VDIR) {
+ error = ENOTDIR;
+ goto bad2;
+ }
+ /*
* Disallow directory write attempts on read-only filesystems.
*/
if (rdonly
diff --git a/sys/sys/namei.h b/sys/sys/namei.h
index ac3550d..d73da50 100644
--- a/sys/sys/namei.h
+++ b/sys/sys/namei.h
@@ -127,26 +127,27 @@ struct nameidata {
* name being sought. The caller is responsible for releasing the
* buffer and for vrele'ing ni_startdir.
*/
-#define RDONLY 0x200 /* lookup with read-only semantics */
-#define HASBUF 0x400 /* has allocated pathname buffer */
-#define SAVENAME 0x800 /* save pathname buffer */
-#define SAVESTART 0x0001000 /* save starting directory */
-#define ISDOTDOT 0x0002000 /* current component name is .. */
-#define MAKEENTRY 0x0004000 /* entry is to be added to name cache */
-#define ISLASTCN 0x0008000 /* this is last component of pathname */
-#define ISSYMLINK 0x001 /* symlink needs interpretation */
-#define ISWHITEOUT 0x002 /* found whiteout */
-#define DOWHITEOUT 0x004 /* do whiteouts */
-#define WILLBEDIR 0x008 /* new files will be dirs; allow trailing / */
-#define ISUNICODE 0x010 /* current component name is unicode*/
-#define ISOPEN 0x020 /* caller is opening; return a real vnode. */
-#define NOCROSSMOUNT 0x040 /* do not cross mount
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Eygene Ryabinkin rea-f...@codelabs.ru writes: May be the attached patch will fix the thing? I'm not entirely convinced. Try the regression test I wrote (head/tools/regression/vfs/trailing_slash.t) It adds an additional flag, but this was the only thing I was able to invent to avoid ABI breakage. The flag is a good idea, but I think the correct place to handle this is in namei(), around line 290 (don't be fooled by the comment on line 270; the code inside the if statement is for the *non*-symlink case). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Wed, May 27, 2009 at 01:07:15PM +0200, Dag-Erling Sm??rgrav wrote:
Eygene Ryabinkin rea-f...@codelabs.ru writes:
May be the attached patch will fix the thing?
I'm not entirely convinced. Try the regression test I wrote
(head/tools/regression/vfs/trailing_slash.t)
I see: you mean that the bare '/' at the end of everything but directory
should produce ENOTDIR. OK, patch was modified and now it passes all
your checks.
It adds an additional flag, but this was the only thing I was able to
invent to avoid ABI breakage.
The flag is a good idea, but I think the correct place to handle this is
in namei(), around line 290
The problem with the check in namei() itself is the cleanup of all locks
that were held in the lookup(). If lookup() is finished without error,
then the burden of cleanup is ours (namei's). I could duplicate the
stuff, but why? lookup() already does it and it's better to keep the
things in one place.
The logics is laid as follows: if lookup() processes the last
component and it had seen the trailing slash, the flag is set.
When we have no more targets to get from the current path inside
lookup(), check if slashed flag is set and reject anything that
is non-directory.
Such strategy should also handle the cases of dereferencing (FOLLOWs) of
all symbolic links and when some link has slash at the end of the target
name: 'ln -s /etc/motd somefile; ln -s somefile/ anotherfile; cat
anotherfile' will fail on the last command. If one agrees on such
behaviour, such test could be also added to the regression suite.
(don't be fooled by the comment on line 270;
the code inside the if statement is for the *non*-symlink case).
Me sees this on the line 226, but may be I hadn't updated my 7.x. And
yes, I know what was meant by '(cnp-cn_flags ISSYMLINK) == 0' ;))
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From 6109a710c794c4a68073d4299639cd858f762d24 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin rea-f...@codelabs.ru
Date: Wed, 27 May 2009 13:13:16 +0400
Subject: [PATCH] vfs lookups: properly handle the case of slash at the end of symlink
If symlink points to a non-directory object but the name has trailing
slash, then the current lookup/namei implementation will dereference
symlink and return dereferenced object instead of symlink even if
NOFOLLOW mode is used. That's not good at all :((
Simple test:
-
$ ln -s /etc/motd file
$ file file
file: symbolic link to `/etc/motd'
[ == Unpatched variant == ]
$ file file/
file/: ASCII English text
[ == Patched variant == ]
$ file file/
file/: cannot open `file/' (Not a directory)
-
See also: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768
See also: http://lists.freebsd.org/pipermail/freebsd-security/2009-May/005219.html
Signed-off-by: Eygene Ryabinkin rea-f...@codelabs.ru
---
sys/kern/vfs_lookup.c | 24
sys/sys/namei.h | 41 +
2 files changed, 37 insertions(+), 28 deletions(-)
diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
index 3770b55..dc801fd 100644
--- a/sys/kern/vfs_lookup.c
+++ b/sys/kern/vfs_lookup.c
@@ -138,6 +138,9 @@ namei(struct nameidata *ndp)
cnp-cn_flags = ~LOCKSHARED;
fdp = p-p_fd;
+ /* Drop internal flag: we will set it ourselves if we'll need it. */
+ cnp-cn_flags = ~SLASHTARGET;
+
/*
* Get a buffer for the name to be translated, and copy the
* name into the buffer.
@@ -683,6 +686,11 @@ unionlookup:
ndp-ni_vp = dp = tdp;
}
+ /* Set slashed flag if we found slash at the end of the name */
+ if (trailing_slash (cnp-cn_flags ISLASTCN)) {
+ cnp-cn_flags |= SLASHTARGET;
+ }
+
/*
* Check for symbolic link
*/
@@ -710,14 +718,6 @@ unionlookup:
goto success;
}
- /*
- * Check for bogus trailing slashes.
- */
- if (trailing_slash dp-v_type != VDIR) {
- error = ENOTDIR;
- goto bad2;
- }
-
nextname:
/*
* Not a symbolic link. If more pathname,
@@ -741,6 +741,14 @@ nextname:
goto dirloop;
}
/*
+ * Check if we're processing slashed name
+ * and lookup target isn't a directory.
+ */
+ if ((cnp-cn_flags SLASHTARGET) dp-v_type != VDIR) {
+ error = ENOTDIR;
+ goto bad2;
+ }
+ /*
* Disallow directory write attempts on read-only filesystems.
*/
if (rdonly
diff --git a/sys/sys/namei.h b/sys/sys/namei.h
index ac3550d..42e9601 100644
--- a/sys/sys/namei.h
+++ b/sys/sys/namei.h
@@ -127,26 +127,27 @@ struct nameidata {
* name being sought. The caller is responsible for releasing the
* buffer and for vrele'ing ni_startdir.
*/
-#define RDONLY 0x200 /* lookup with read-only semantics */
-#define HASBUF 0x400 /*
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Wed, May 27, 2009 at 02:39:07PM +0200, Dag-Erling Sm??rgrav wrote:
I was working on head. The code is (mostly) the same, just shifted
somewhere between ~50 and ~90 lines depending on where you look. Your
patch should apply cleanly.
BTW, you made a lot of whitespace changes in namei.h. This is generally
frowned upon, as it makes the functional change almost impossible to
spot in the diff.
Yes, spit the patch into two pieces. Thanks for the reminder!
And yes, I know what was meant by '(cnp-cn_flags ISSYMLINK) == 0'
;))
I know you know :) I was just pointing out that the comment is
misleading.
Changed it too. All three pieces are attached.
Regarding the 'ln -s /etc/motd file; ln -s file/ anotherone': do you
(or anyone reading this) think that 'cat anotherone' should really
show the contents of /etc/motd or patch's behaviour is good?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From 03483c8e800680a8b8a3d3f0d1debdf7fd883906 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin rea-f...@codelabs.ru
Date: Wed, 27 May 2009 13:13:16 +0400
Subject: [PATCH 1/3] vfs lookups: properly handle the case of slash at the end of symlink
If symlink points to a non-directory object but the name has trailing
slash, then the current lookup/namei implementation will dereference
symlink and return dereferenced object instead of symlink even if
NOFOLLOW mode is used. That's not good at all :((
Simple test:
-
$ ln -s /etc/motd file
$ file file
file: symbolic link to `/etc/motd'
[ == Unpatched variant == ]
$ file file/
file/: ASCII English text
[ == Patched variant == ]
$ file file/
file/: cannot open `file/' (Not a directory)
-
See also: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768
See also: http://lists.freebsd.org/pipermail/freebsd-security/2009-May/005219.html
Signed-off-by: Eygene Ryabinkin rea-f...@codelabs.ru
---
sys/kern/vfs_lookup.c | 24
sys/sys/namei.h |3 ++-
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
index 3770b55..dc801fd 100644
--- a/sys/kern/vfs_lookup.c
+++ b/sys/kern/vfs_lookup.c
@@ -138,6 +138,9 @@ namei(struct nameidata *ndp)
cnp-cn_flags = ~LOCKSHARED;
fdp = p-p_fd;
+ /* Drop internal flag: we will set it ourselves if we'll need it. */
+ cnp-cn_flags = ~SLASHTARGET;
+
/*
* Get a buffer for the name to be translated, and copy the
* name into the buffer.
@@ -683,6 +686,11 @@ unionlookup:
ndp-ni_vp = dp = tdp;
}
+ /* Set slashed flag if we found slash at the end of the name */
+ if (trailing_slash (cnp-cn_flags ISLASTCN)) {
+ cnp-cn_flags |= SLASHTARGET;
+ }
+
/*
* Check for symbolic link
*/
@@ -710,14 +718,6 @@ unionlookup:
goto success;
}
- /*
- * Check for bogus trailing slashes.
- */
- if (trailing_slash dp-v_type != VDIR) {
- error = ENOTDIR;
- goto bad2;
- }
-
nextname:
/*
* Not a symbolic link. If more pathname,
@@ -741,6 +741,14 @@ nextname:
goto dirloop;
}
/*
+ * Check if we're processing slashed name
+ * and lookup target isn't a directory.
+ */
+ if ((cnp-cn_flags SLASHTARGET) dp-v_type != VDIR) {
+ error = ENOTDIR;
+ goto bad2;
+ }
+ /*
* Disallow directory write attempts on read-only filesystems.
*/
if (rdonly
diff --git a/sys/sys/namei.h b/sys/sys/namei.h
index ac3550d..70e902c 100644
--- a/sys/sys/namei.h
+++ b/sys/sys/namei.h
@@ -146,7 +146,8 @@ struct nameidata {
#define GIANTHELD 0x200 /* namei() is holding giant. */
#define AUDITVNODE1 0x400 /* audit the looked up vnode information */
#define AUDITVNODE2 0x800 /* audit the looked up vnode information */
-#define PARAMASK 0xe00 /* mask of parameter descriptors */
+#define SLASHTARGET 0x1000 /* last component of the name was slashed */
+#define PARAMASK 0x1e00 /* mask of parameter descriptors */
#define NDHASGIANT(NDP) (((NDP)-ni_cnd.cn_flags GIANTHELD) != 0)
--
1.6.3.1
From 2539d4f31a2f85504672e8113343242782e737a7 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin rea-f...@codelabs.ru
Date: Wed, 27 May 2009 17:06:39 +0400
Subject: [PATCH 2/3] namei.h: realign numbers
Functional no-op, just for the eye's pleasure.
Signed-off-by: Eygene Ryabinkin rea-f...@codelabs.ru
---
sys/sys/namei.h | 39 ---
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/sys/sys/namei.h b/sys/sys/namei.h
index 70e902c..c84a823 100644
--- a/sys/sys/namei.h
+++ b/sys/sys/namei.h
@@ -127,25 +127,26 @@ struct nameidata {
* name being sought. The caller is responsible for releasing the
* buffer and for vrele'ing
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Eygene Ryabinkin rea-f...@codelabs.ru writes: Regarding the 'ln -s /etc/motd file; ln -s file/ anotherone': do you (or anyone reading this) think that 'cat anotherone' should really show the contents of /etc/motd or patch's behaviour is good? if you mean $ ln -fs /etc/motd foo $ ln -fs foo/ bar $ readlink foo bar /etc/motd foo/ $ cat foo then IMHO it should produce an error. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Bruce Evans b...@zeta.org.au writes:
This seems to be equivalent to the patch in the PR at the time of PR,
except it risks breaking some other cases, so I don't see how it can
work.
As discussed on -hackers, it doesn't. This one does, though.
DES
--
Dag-Erling Smørgrav - d...@des.no
Index: sys/kern/vfs_lookup.c
===
--- sys/kern/vfs_lookup.c (revision 192899)
+++ sys/kern/vfs_lookup.c (working copy)
@@ -147,6 +147,9 @@
cnp-cn_flags = ~LOCKSHARED;
fdp = p-p_fd;
+ /* We will set this ourselves if we need it. */
+ cnp-cn_flags = ~TRAILINGSLASH;
+
/*
* Get a buffer for the name to be translated, and copy the
* name into the buffer.
@@ -533,6 +536,8 @@
if (*cp == '\0') {
trailing_slash = 1;
*ndp-ni_next = '\0'; /* XXX for direnter() ... */
+ if (cnp-cn_flags ISLASTCN)
+cnp-cn_flags |= TRAILINGSLASH;
}
}
ndp-ni_next = cp;
@@ -807,14 +812,6 @@
goto success;
}
- /*
- * Check for bogus trailing slashes.
- */
- if (trailing_slash dp-v_type != VDIR) {
- error = ENOTDIR;
- goto bad2;
- }
-
nextname:
/*
* Not a symbolic link. If more pathname,
@@ -838,6 +835,14 @@
goto dirloop;
}
/*
+ * If we're processing a path with a trailing slash,
+ * check that the end result is a directory.
+ */
+ if ((cnp-cn_flags TRAILINGSLASH) dp-v_type != VDIR) {
+ error = ENOTDIR;
+ goto bad2;
+ }
+ /*
* Disallow directory write attempts on read-only filesystems.
*/
if (rdonly
Index: sys/sys/namei.h
===
--- sys/sys/namei.h (revision 192900)
+++ sys/sys/namei.h (working copy)
@@ -143,6 +143,8 @@
#define AUDITVNODE1 0x0400 /* audit the looked up vnode information */
#define AUDITVNODE2 0x0800 /* audit the looked up vnode information */
#define PARAMASK 0x0e00 /* mask of parameter descriptors */
+#define TRAILINGSLASH 0x1000 /* path ended in a slash */
+#define PARAMASK 0x1e00 /* mask of parameter descriptors */
#define NDHASGIANT(NDP) (((NDP)-ni_cnd.cn_flags GIANTHELD) != 0)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Wed, May 27, 2009 at 06:44:35PM +0200, Dag-Erling Sm??rgrav wrote:
Eygene Ryabinkin rea-f...@codelabs.ru writes:
[new three-part patch]
I committed the namei.h cleanup patch and the vfs_lookup.c comment
patch.
Thanks!
I made a number of changes to the trailing-slash patch. Can you
double-check it before I commit it?
Yes, comments are below.
Index: sys/kern/vfs_lookup.c
===
--- sys/kern/vfs_lookup.c (revision 192899)
+++ sys/kern/vfs_lookup.c (working copy)
@@ -147,6 +147,9 @@
cnp-cn_flags = ~LOCKSHARED;
fdp = p-p_fd;
+ /* We will set this ourselves if we need it. */
+ cnp-cn_flags = ~TRAILINGSLASH;
+
/*
* Get a buffer for the name to be translated, and copy the
* name into the buffer.
@@ -533,6 +536,8 @@
if (*cp == '\0') {
trailing_slash = 1;
*ndp-ni_next = '\0'; /* XXX for direnter() ... */
+ if (cnp-cn_flags ISLASTCN)
+ cnp-cn_flags |= TRAILINGSLASH;
'if ()' looks suspicious: ISLASTCN is set some lines below so it could
be not yet flagged. Seems like we could omit 'if ()' clause but leave
it's body for the current state of the code -- it will be equivalent to
the mine's check.
But for the clarity, I will leave the full condition, 'trailing_slash
(cnp-cn_flags ISLASTCN)' somewhere below the block with
-
if (*ndp-ni_next == 0)
cnp-cn_flags |= ISLASTCN;
else
cnp-cn_flags = ~ISLASTCN;
-
My original intent was to push it to the bottom of the code to slightly
optimize code path: some checks above could already fail and we won't
have to perform our test. But now I feel that the best place for the
test is immediately below the cited chunk of the code.
The rest looks fine. Had you tried your variant of patch? May be I
am missing something and the test for ISLASTCN really in place?
By the way, I had somewhat extended your regression tests with the
intermediate symlink tests, directory tests and device-as-a-target
tests. Patches are attached. Will they go?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From 8ed2a144245bdb714217f982f6ee1f7d0b784b1c Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin rea-f...@codelabs.ru
Date: Wed, 27 May 2009 20:55:50 +0400
Subject: [PATCH 4/5] vfs regression testuite: add double links and directory tests
Directory tests are to make sure that no regressions were introduced by
patches -- they should work on the systems without patched vfs_lookup as
at the patched ones.
Double link tests should verify that if any part of the symlink chain
has trailing slash, then target should be a directory.
Signed-off-by: Eygene Ryabinkin rea-f...@codelabs.ru
---
tools/regression/vfs/trailing_slash.t | 67 -
1 files changed, 66 insertions(+), 1 deletions(-)
diff --git a/tools/regression/vfs/trailing_slash.t b/tools/regression/vfs/trailing_slash.t
index fe6d799..5209979 100755
--- a/tools/regression/vfs/trailing_slash.t
+++ b/tools/regression/vfs/trailing_slash.t
@@ -6,8 +6,10 @@
# point to files. See kern/21768
#
+testdir=/tmp/testdir-$$
testfile=/tmp/testfile-$$
testlink=/tmp/testlink-$$
+testlink1=/tmp/testlink1-$$
tests=
$testfile:$testlink:$testfile:0
@@ -18,8 +20,29 @@ $testfile/:$testlink:$testlink:1
$testfile/:$testlink:$testlink/:1
+tests1=
+$testfile:$testlink:$testlink:$testlink1:$testlink1:0
+$testfile:$testlink:$testlink/:$testlink1:$testlink1:1
+$testfile:$testlink:$testlink:$testlink1:$testlink1/:1
+$testfile:$testlink:$testlink/:$testlink1:$testlink1/:1
+$testfile/:$testlink:$testlink:$testlink1:$testlink1:1
+$testfile/:$testlink:$testlink/:$testlink1:$testlink1:1
+$testfile/:$testlink:$testlink:$testlink1:$testlink1/:1
+$testfile/:$testlink:$testlink/:$testlink1:$testlink1/:1
+
+
+dirtests=
+$testdir:$testlink:$testdir:0
+$testdir:$testlink:$testdir/:0
+$testdir:$testlink:$testlink:0
+$testdir:$testlink:$testlink/:0
+$testdir/:$testlink:$testlink:0
+$testdir/:$testlink:$testlink/:0
+
+
touch $testfile || exit 1
-trap rm $testfile $testlink EXIT
+mkdir $testdir || exit 1
+trap rm $testfile $testlink $testlink1; rmdir $testdir EXIT
set $tests
echo 1..$#
@@ -40,3 +63,45 @@ for testspec ; do
n=$((n+1))
)
done
+
+set $tests1
+echo 1..$#
+n=1
+for testspec ; do
+ (
+ IFS=:
+ set $testspec
+ unset IFS
+ ln -fs $1 $2 || exit 1
+ ln -fs $3 $4 || exit 1
+ cat $5 /dev/null 21
+ ret=$?
+ if [ $ret -eq $6 ] ; then
+ echo ok $n
+ else
+ echo
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Hi! This is a redefinitions of PARAMASK in the patch, that you attached ---8- ... #definePARAMASK0x0e00 /* mask of parameter descriptors */ +#defineTRAILINGSLASH 0x1000 /* path ended in a slash */ +#definePARAMASK0x1e00 /* mask of parameter descriptors */ ... ---8- On 5/27/09, Dag-Erling Smørgrav d...@des.no wrote: Eygene Ryabinkin rea-f...@codelabs.ru writes: [new three-part patch] I committed the namei.h cleanup patch and the vfs_lookup.c comment patch. I made a number of changes to the trailing-slash patch. Can you double-check it before I commit it? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Oliver Pinter oliver.p...@gmail.com writes: This is a redefinitions of PARAMASK in the patch, that you attached Sorry, I forgot to regenerate the patch after fixing it. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Eygene Ryabinkin rea-f...@codelabs.ru writes: 'if ()' looks suspicious: ISLASTCN is set some lines below so it could be not yet flagged. Seems like we could omit 'if ()' clause but leave it's body for the current state of the code -- it will be equivalent to the mine's check. Yes, I was a little too quick there. You're right, we can just drop the if(). Actually, the reason why I moved this up is that I was considering eliminating the trailing_slash variable entirely. By the way, I had somewhat extended your regression tests with the intermediate symlink tests, directory tests and device-as-a-target tests. Patches are attached. Will they go? I'll take a look at them later. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
[moving from security@ to hack...@]
Jakub Lach jakub_l...@mailplus.pl writes:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768
Like bde@ pointed out, the patch is incorrect. It moves the test for
v_type != VDIR up to a point where, in the case of a symlink, v_type is
always (by definition) VLNK.
The reason why the current code does not work is that, in the symlink
case, the v_type != VDIR test is never reached: we will have jumped to
either bad2 or success. However, it should be safe to move the test to
after the success label, because trailing_slash is only ever true for
the last component of the path we were asked to look up (see lines 520
through 535).
The attached patch should work.
DES
--
Dag-Erling Smørgrav - d...@des.no
Index: sys/kern/vfs_lookup.c
===
--- sys/kern/vfs_lookup.c (revision 192614)
+++ sys/kern/vfs_lookup.c (working copy)
@@ -800,14 +800,6 @@
goto success;
}
- /*
- * Check for bogus trailing slashes.
- */
- if (trailing_slash dp-v_type != VDIR) {
- error = ENOTDIR;
- goto bad2;
- }
-
nextname:
/*
* Not a symbolic link. If more pathname,
@@ -861,6 +853,14 @@
VOP_UNLOCK(dp, 0);
success:
/*
+ * Check for bogus trailing slashes.
+ */
+ if (trailing_slash dp-v_type != VDIR) {
+ error = ENOTDIR;
+ goto bad2;
+ }
+
+ /*
* Because of lookup_shared we may have the vnode shared locked, but
* the caller may want it to be exclusively locked.
*/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Dag-Erling Smørgrav d...@des.no writes: The attached patch should work. Oops. It actually triggers a KASSERT. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Dag-Erling Smørgrav d...@des.no writes: Like bde@ pointed out, the patch is incorrect. It moves the test for v_type != VDIR up to a point where, in the case of a symlink, v_type is always (by definition) VLNK. Hmm, actually, symlinks are resolved in namei(), not lookup(). This is not going to be pretty. I'll be back later... DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FYI: 3Ware 9650 can cause data corruption
Peter B wrote: 3ware 9650 in RAID6 mode with firmware version 3.08.00.004 seems to cause data corruption when rebuilding a single disc with raid6. http://www.webmasternetwork.se/f4t23551.html (Swedish) I thought this was serious enough for people to know. If another mailinglist is more appropiate for this kind of FYI then tell. well I guess that's better than the 7800 that just corrupted data during standard writes. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI: 3Ware 9650 can cause data corruption
Peter B wrote: 3ware 9650 in RAID6 mode with firmware version 3.08.00.004 seems to cause data corruption when rebuilding a single disc with raid6. http://www.webmasternetwork.se/f4t23551.html (Swedish) I thought this was serious enough for people to know. If another mailinglist is more appropiate for this kind of FYI then tell. This is a known issue with 3ware software v9.4.1.0 and 9.4.1.1 (firmware v3.08.00.004). 3ware released software v9.4.1.2 (firmware 3.08.02.005) that corrects the problem over three months ago and it has since been obsoleted by 9.4.1.3 and 9.5.0 (released earlier this week). In fact, the link you cite links to 3ware's advisory: http://www.3ware.com/support/UserDocs/RAID6-data-integrity-customer-notification_061907-FINAL.pdf While it is appreciated that you felt obligated to post this important bug notice, it would be even more appreciated if in the future, you would do a bit of research before clicking send. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI: NetBSD mmap Improvements
Hi again; Reading more deeply,the patch was made to be able to run Linux's crossover office, but it would seem like it's not required on FreeBSD though as out mmap behaves similar to the linux one. FWIW, I found this reference on the NetBSD mailing lists: http://mail-index.netbsd.org/tech-kern/2003/06/20/0006.html cheers, Pedro. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI: NetBSD mmap Improvements
On Tue, Sep 09, 2003 at 09:58:03PM -0700, Pedro F. Giffuni wrote: taken from wine HQ: [snip] Does this make Wine significantly faster for you? Has anybody prepared benchmarks for this? I can take a look at implementing this if it's likely to offer benefits. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI - Just got a kernel panic - RELENG_4
On Fri, 29 Aug 2003, Kris Kennaway wrote: On Thu, Aug 28, 2003 at 05:34:29PM -0400, Marc Ramirez wrote: supped as of ~ 1:40pm EST today The panic: Fatal trap 12: page fault while in kernel mode This is probably hardware-related, but it's possible it may be due to a kernel problem. As a first step, you need to try and get a gdb traceback with debugging symbols as explained in the developer's handbook on the website. I forgot to turn off the cvsup cron job; I went to rebuild the kernel with DDB, and found out that my code base had changed... Everything works now. I have been unable to reproduce the crash... Thanks for taking the time, though. Marc. -- Marc Ramirez Blue Circle Software Corporation 513-688-1070 (main) 513-382-1270 (direct) http://www.bluecirclesoft.com http://www.mrami.com (personal) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI - Just got a kernel panic - RELENG_4
On Thu, Aug 28, 2003 at 05:34:29PM -0400, Marc Ramirez wrote: supped as of ~ 1:40pm EST today The panic: Fatal trap 12: page fault while in kernel mode This is probably hardware-related, but it's possible it may be due to a kernel problem. As a first step, you need to try and get a gdb traceback with debugging symbols as explained in the developer's handbook on the website. Kris pgp0.pgp Description: PGP signature
Re: FYI - Just got a kernel panic - RELENG_4
On 28 Aug 2003, at 17:34, Marc Ramirez wrote: c0271430 T vm_page_remove c02714f8 T vm_page_lookup Your fault address is between those two, so it happened sometime after you entered vm_page_remove. This particular failure is often related to running out of KVM/KVA space (or hardware problems as someone else mentioned), but without a backtrace it's tough to tell for sure. We had this problem on one of our machines and recently another fellow had this same problem. If you're able to duplicate the panic reliably, then it's likely a KVM/KVA shortage that you'd fix by rebuilding your kernel with a larger KVA_PAGES value (see LINT). If this fixes it for you, please be sure to respond to the list with news of your success so that others searching for this problem and a solution are able to do so. If the fault address is variable and the panic is not consistently reproduceable, then hardware problems are more likely. In many cases with random panics related to memory allocation or deallocation, bad RAM is the culprit, but sometimes it can be a heat issue or a semi-fried CPU that randomly flips bits. Hope that helps. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI: FreeBSD and Intel/ICP Vortex Raid-Controllers
Also, incase your intrested, you can also use icpcon with the iir driver incase you want to fool with the raid from userland. icpcon looks alot like the interface you get when booting. You can look for failures, rebuild the raid, and get statistics. To use icpcon, you just need to: mknod /dev/iir c 164 0 ln -s /dev/iir /dev/icp You can get icpcon as part of the icp freebsd driver zip from icp-vortex.com. -Joel On Wed, 30 Oct 2002, Kai Gallasch wrote: Hi, a few days ago I looked through the LINT file of the stable kernel sources and wondered if the iir RAID device would also support the ICP vortex line of RAID controllers (INTEL recently bought the manufacturer ICP and with it its whole productline of controllers) So I asked one of the contacts for the iir named in the LINT - [EMAIL PROTECTED] - if ICP Vortex controllers are also supported.. Achim had this to say.. ---snip--- Hello Kai, the iir driver supports the ICP vortex controller line AND the intel controller line. You must not use another ICP specific driver. Regards, Achim - Achim Leubner Research Development ICP vortex Computersysteme GmbH, an Intel company Gostritzer Str. 61-63 D-01217 Dresden, Germany Phone: +49-351-871-8291 Fax: +49-351-871-8448 Mail: [EMAIL PROTECTED] Url: www.icp-vortex.com -Original Message- From: Kai Gallasch [mailto:kai;adminhell.org] Sent: Wednesday, October 30, 2002 11:08 AM To: Leubner, Achim Subject: FreeBSD and Intel/ICP Vortex Raid-Controllers Hello, does the device iir in the kernel sources of FreeBSD stable also support the ICP Vortex Raid-Controller line, or do I still have to use the FreeBSD driver delivered by ICP Vortex? I found the following in the LINT file of the freebsd kernel sources.. --snip-- # # Intel Integrated RAID controllers. # This driver was developed and is maintained by Intel. Contacts # at Intel for this driver are # Kannanthanam, Boji T [EMAIL PROTECTED] and # Leubner, Achim [EMAIL PROTECTED]. # device iir --snip-- Proposal: The iir comment section of the LINT file in stable should mention that ICP vortex controllers are also supported by the iir driver. Cheers, Kai. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Mike Smith wrote: So the driver writers are forced to at least recompile their drivers for each release. This isn't typically the case, actually. 4.x has in fact been very good in this regard. What about between 3.x and 4.x ? And 5.x is going to be yet another major change. Plus people are very active at ripping away the old APIs even when there is no immediate need for that nor benefit from it (think of phk's removal of the LIST-something macros). The removal of the LIST* macros doesn't affect the kernel interface (they're macros, not functions). And if some code uses these macros and has to be recompiled then this becomes an issue. And not only for the drivers but for applications too. Remember, that the thing that broke in -current was vi. Another example would be the compatibility PCI infrastructure ripped out of -current together with a few drivers that were not newbussified yet. If people don't bother about the drivers in the source form that are parts of the official tree, they bother even less about the third-party drivers. I can understand when supporting some old piece of technology requires extra effort which is not available, so it gets into disrepair and eventually gets ripped out. But when people spend _extra_ effort on ripping out the perfectly working things which can stay in the tree for a few more years without any need for support, this amazes me to no end. So often not a simple recompilation but a noticeable rewrite may be required for a driver between different versions of FreeBSD. I've been maintaining drivers for a while now, and frankly, I just don't see this. Think of newbussification. Or of CAM-ifying. That actually is true not only for the drivers but for the usual binaries too. For example, there seems to be no way to combine COFF and ELF libraries into one executable. Sorry, I've meant to say a.out, not COFF. Of course there isn't, and there'd be no point in it. Why do you think so ? I've given you one real example why it could be useful. That made porting of Lyx to 4.0 unfeasible, as the binary-only Xforms library it used was at the time available in the COFF form only. And I haven't found how to build even purely COFF binaries on an ELF-ized system either. Use a cross-gcc setup. Which is not a too easy and obvious thing to set up. Plus at least install the static a.out libraries and headers from 3.x. Maybe we should have an official policy of keeping the things compatible and available for as long as possible even if they are considered obsolete, unless carrying them on requires a major effort. We do. And we do. Of course, this effort goes largely unnoticed and unthanked, since you're not going to comment on it unless you're personally inconvenienced by it. Maybe I'm missing something but I can't see how keeping compatibility can inconvenience someone. On the contrary, the inconvenience happens when this policy is not followed. I've asked before, I'll ask again. Will folks please just let this die? You're producing a great deal of archive-filling material that's just not accurate or relevant, and your misinformation is harmful to the Project in a very real fashion. If we hide our heads in the sand in an ostrich fashion, it won't help that much either. And this information is relevant though maybe not always quite accurate. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Tim, Your license with SBS for the DDK would prevent you from posting your code. If you read through it, you'll find that it prohibits the release of any of their DDK code under any circumstances. You could release everything EXCEPT the API for the card that SBS provides and offer the rest in object-only format. Doug On Thu, 18 Oct 2001, Tim Wiess wrote: If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. I'm actually working on a driver for the SBS WANic 600 and 800 cards. There is still a lot of work and testing to be done, but (assuming there are no problems with the powers that be over here, and there are no conflicts with our agreements with SBS) I do eventually plan on posting the code (under a BSD license). I'll keep y'all posted. tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
On Thu, 18 Oct 2001, Mike Smith wrote: Well, honestly, FreeBSD makes the life of the developers of third-party binary-only drivers fairly difficult. It does? On the whole, actually, I'd say we do a pretty good job of making it easy. The reason is that there are a lot of API changes happening between the releases (take Julian Elisher's recent problem for example). It's a poor example. Drivers don't involve themselves in the sysinit chain. welll it gets involved.. if you redefine the SYSINIT values, old drivers's aren't 'notified' (should be a module but the supplier didn't make one..) So the driver writers are forced to at least recompile their drivers for each release. This isn't typically the case, actually. 4.x has in fact been very good in this regard. with the above exception, I agree. though in userland, the library changes have caused us some grief. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: Bill Fumerola [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 11:13 PM To: Ted Mittelstaedt Cc: Doug Hass; Mike Smith; Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: FYI On Wed, Oct 17, 2001 at 10:51:25PM -0700, Ted Mittelstaedt wrote: When we have a choice, we take the BSD code and improve it as necessary. Otherwise, we take what we can get. Sometimes, even, companies that release the stuff closed source end up opening it up when they see that by doing so that lots more people will contribute bugfixes and such. you say 'we' an awful lot for someone who isn't part of, doesn't represent, and is in no way affiliated with the freebsd project. thankfully, the project's official word can be found here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ policies-encumbered.html And, what exactly on this page is any different from what I've just said? Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Smith Sent: Wednesday, October 17, 2001 10:32 PM To: Ted Mittelstaedt Cc: Doug Hass; Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: FYI That's silly, what did you find in it that's flamebait? I think you didn't read it. You're a) misrepresenting the project, b) dismissing the opinions and statements of others that are arguably more in touch with the project, and c) you won't let this stupid thread die. I do not feel that this thread is stupid. To the contrary I'm very concerned when a manufacturer pulls a specialty card supported by FreeBSD off the market and replaces it with nothing that is supported. Every time this happens (and it seems to be happening a lot with network adapters lately) it causes problems for a lot of users, confusion because This rev of the card is supported and That rev isn't, extra work for the maintainers, and in short sets the project back. This does not help FreeBSD to support lots of peripherals, as Doug pointed out we are being ignored by the RAS card manufacturers, and nobody is going to use FreeBSD no matter how good the kernel is if the OS doesen't support the hardware they own. Telling Imagestream we built a module architecture that makes writing, maintaining and deploying binary-only drivers easy is fine, but it does nothing to respond to the problem of how to convert their binary drivers to our framework. They don't even understand we have a framework, let alone how it operates. They are asking us to write the drivers and they don't even understand that some of the developers that could do it have reservations against binary-only drivers only available under NDA, or how much more it could help them if they were to just publish source. And attempting to even talk about this openly leads into irrelevant pointless accusations about stealing intellectual property. Device driver support in PC operating systems seems always to have been a political football no matter what OS vendor - even Microsoft with all their power still was forced into writing drivers for some hardware, despite all the pressure they applied to the hardware vendors to do the work. You seem to be taking the attitude that we made a framework, and that's as far as we go - you write the driver and then labeling any further discussion on the matter as stupid. Well, if this is the attitude in the FreeBSD project (which I doubt) then if it was such an effective one then why does Linux seem to have many more drivers written for it? No, I am well aware of FreeBSD's history and if you don't believe that the project avoids closed-source code then I don't know what to say, frankly. You could say I'm wrong. It'd be a good start. OK, your right, I'm wrong. Contrary to my statement, FreeBSD attempts to get as much closed-source code as possible. That's why the name of the distribution starts with the word Free Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
You're a) misrepresenting the project, b) dismissing the opinions and statements of others that are arguably more in touch with the project, and c) you won't let this stupid thread die. I do not feel that this thread is stupid. This much is obvious. You are, however, largely alone in this opinion. To the contrary I'm very concerned when a manufacturer pulls a specialty card supported by FreeBSD off the market and replaces it with nothing that is supported. If you're very concerned about it, I recommend doing something constructive to mitigate the situation. The vendor in question appears to have offered a bounty for a driver; why don't you get busy on it? Every time this happens (and it seems to be happening a lot with network adapters lately) It does? Really? You know, I can only think of one ethernet chipset currently on the market that we don't support, or don't have imminent support coming for. That's not a lot by any stretch of the imagination. So I'll say it all again, in a slightly different fashion: You sound too much like Brett Glass. Less hysteria, please, and a little more practicality. = Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. I'm actually working on a driver for the SBS WANic 600 and 800 cards. There is still a lot of work and testing to be done, but (assuming there are no problems with the powers that be over here, and there are no conflicts with our agreements with SBS) I do eventually plan on posting the code (under a BSD license). I'll keep y'all posted. tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
- Original Message - From: Tim Wiess [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 19, 2001 7:12 AM Subject: Re: FYI If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. I'm actually working on a driver for the SBS WANic 600 and 800 cards. There is still a lot of work and testing to be done, but (assuming there are no problems with the powers that be over here, and there are no conflicts with our agreements with SBS) I do eventually plan on posting the code (under a BSD license). I'll keep y'all posted. tim Yay Tim Unfortunately my skills(?) lie in the database arena or I would have jumped in myself a _LOT_ earlier and try to solve the EOL runout myself. Murray T To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Ted Mittelstaedt wrote: From: Doug Hass [mailto:[EMAIL PROTECTED]] The lack of flexibility in accepting various requirements illustrates the difference between an OS WITH legs in the market and one WITHOUT legs. Much to my chagrin, FreeBSD continues to fall more and more into the latter category. This is a gross simplification of a great many issues. I fail to see why you feel that FreeBSD is threatening anyone's IP and I don't understand why you are reacting this way. Any company is free to take the FreeBSD distribution and customize it the way they want and include any proprietary and binary code they want and hand out distributions as they see fit. Imagestream could do this Well, honestly, FreeBSD makes the life of the developers of third-party binary-only drivers fairly difficult. The reason is that there are a lot of API changes happening between the releases (take Julian Elisher's recent problem for example). So the driver writers are forced to at least recompile their drivers for each release. Plus people are very active at ripping away the old APIs even when there is no immediate need for that nor benefit from it (think of phk's removal of the LIST-something macros). So often not a simple recompilation but a noticeable rewrite may be required for a driver between different versions of FreeBSD. That actually is true not only for the drivers but for the usual binaries too. For example, there seems to be no way to combine COFF and ELF libraries into one executable. That made porting of Lyx to 4.0 unfeasible, as the binary-only Xforms library it used was at the time available in the COFF form only. And I haven't found how to build even purely COFF binaries on an ELF-ized system either. ALl this is a significant pain for everyone porting their software to FreeBSD and much stronger yet for those doing binary-only distributions. Maybe we should have an official policy of keeping the things compatible and available for as long as possible even if they are considered obsolete, unless carrying them on requires a major effort. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Well, honestly, FreeBSD makes the life of the developers of third-party binary-only drivers fairly difficult. It does? On the whole, actually, I'd say we do a pretty good job of making it easy. The reason is that there are a lot of API changes happening between the releases (take Julian Elisher's recent problem for example). It's a poor example. Drivers don't involve themselves in the sysinit chain. So the driver writers are forced to at least recompile their drivers for each release. This isn't typically the case, actually. 4.x has in fact been very good in this regard. Plus people are very active at ripping away the old APIs even when there is no immediate need for that nor benefit from it (think of phk's removal of the LIST-something macros). The removal of the LIST* macros doesn't affect the kernel interface (they're macros, not functions). So often not a simple recompilation but a noticeable rewrite may be required for a driver between different versions of FreeBSD. I've been maintaining drivers for a while now, and frankly, I just don't see this. That actually is true not only for the drivers but for the usual binaries too. For example, there seems to be no way to combine COFF and ELF libraries into one executable. Of course there isn't, and there'd be no point in it. That made porting of Lyx to 4.0 unfeasible, as the binary-only Xforms library it used was at the time available in the COFF form only. And I haven't found how to build even purely COFF binaries on an ELF-ized system either. Use a cross-gcc setup. Of course, you mean a.out, but your error doesn't help your case much. Maybe we should have an official policy of keeping the things compatible and available for as long as possible even if they are considered obsolete, unless carrying them on requires a major effort. We do. And we do. Of course, this effort goes largely unnoticed and unthanked, since you're not going to comment on it unless you're personally inconvenienced by it. I've asked before, I'll ask again. Will folks please just let this die? You're producing a great deal of archive-filling material that's just not accurate or relevant, and your misinformation is harmful to the Project in a very real fashion. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: Doug Hass [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 9:19 AM To: Ted Mittelstaedt Cc: Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: FYI Doug, in the entire history of the FreeBSD project, when given a choice between a better driver or code that is closed source, and a worse driver that has open source, the FreeBSD community has never chosen the driver or code with closed source. In fact I can only remember ONCE that the Project has recommended against freely available BSD code - and they did so in favor of GPL code, not closed source code - and this was for the coprocessor emulator (used for 386 and 486SX chips only) The only time that FreeBSD gets involved in closed-source code is when there is simply NO other alternative - like in this case where the register interface specs are being withheld. We certainly support the right for companies to protect their intellectual property in whatever way they see fit, even if the FreeBSD community does not. Whoah whoah here! Where did I say that FreeBSD didn't support intellectual property? Choosing not to include a lot of binary licensed code in the FreeBSD distribution is a free choice that the maintainers have made. How can you fault them for that?!?! I think that your ignoring a lot of issues here when you say that FreeBSD doesen't support IP. For starters I'm only stating what is current in the Project. Unlike Linux, there is not a large quantity of binary-only code distributed with FreeBSD distributions. Companies are free to distribute such as they see fit. Not many of them would allow binary-only code into the FreeBSD CD distribution anyway. In fact one of the reasons that the Ports directory is set up the way it is, is so that the project doesen't have to deal with a bunch of licensing issues. The lack of flexibility in accepting various requirements illustrates the difference between an OS WITH legs in the market and one WITHOUT legs. Much to my chagrin, FreeBSD continues to fall more and more into the latter category. This is a gross simplification of a great many issues. I fail to see why you feel that FreeBSD is threatening anyone's IP and I don't understand why you are reacting this way. Any company is free to take the FreeBSD distribution and customize it the way they want and include any proprietary and binary code they want and hand out distributions as they see fit. Imagestream could do this if it wanted to. I'm just saying that in the past the main FreeBSD distributions have preferred not to do this, and I see no indication that things are changing in the latest release. The fact is that just about everything included in the release has full source code. If Imagestream wants to release binary-only drivers for the WANic card and have them included in the FreeBSD distribution, since there's no alternative I'm sure that nobody would complain - unless Imagestream demanded that anyone getting a FreeBSD distribution with the drivers report back to them, or some such. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: Doug Hass [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 11:10 AM To: void Cc: Mike Smith; Ted Mittelstaedt; Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: FYI If you didn't say it, then you weren't the one I was talking about, was I? :-) I got several other private mails saying that BSD licensed code was the one and only way, well Doug, there's a reason you got those as private mails instead of public posts - because this isn't the viewpoint of the FreeBSD community. and 2 or 3 mails (from Ben, among others) saying that BSD-licensed was preferred. Preferred doesen't mean we are going to throw the baby out with the bathwater and turn up our nose at anyone's effort with FreeBSD. Either approach is as flawed as someone who claims GPL only or GPL preferred. The license terms of add-on drivers and products should be set according to the needs of the authoring person or company, in my opinion. This is a perfectly valid viewpoint that a lot of companies share which is why they don't include their drivers. For example Sangoma, and Emerging don't include FreeBSD drivers either - but they make them available from their own websites. In My Humble Opinion this is inferior than just giving the binaries over to the project and letting the drivers be handed out where they may, but those companies and you are welcome to do it that way if you prefer. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com Doug On Wed, 17 Oct 2001, void wrote: On Wed, Oct 17, 2001 at 12:19:34PM -0500, Doug Hass wrote: I'm glad someone else is speaking up--all I've heard is Ted's point of view (from him, and from others who have said the same thing: FreeBSD only accepts BSD licensed code, period.) I said to you in private mail that where there's a BSD-licensed solution and a non-BSD-licensed solution, all else being roughly equal, FreeBSD tends towards the BSD-licensed solution. Not the same thing at all. -- Ben An art scene of delight I created this to be ... -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: Mike Smith [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 9:46 AM To: Doug Hass Cc: Ted Mittelstaedt; Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: FYI Doug, in the entire history of the FreeBSD project, when given a choice between a better driver or code that is closed source, and a worse driver that has open source, the FreeBSD community has never chosen the driver or code with closed source. In fact I can only remember ONCE that the Project has recommended against freely available BSD code - and they did so in favor of GPL code, not closed source code - and this was for the coprocessor emulator (used for 386 and 486SX chips only) The only time that FreeBSD gets involved in closed-source code is when there is simply NO other alternative - like in this case where the register interface specs are being withheld. We certainly support the right for companies to protect their intellectual property in whatever way they see fit, even if the FreeBSD community does not. Doug; I would recommend against falling for Ted's flamebait here, since that's really all it is. That's silly, what did you find in it that's flamebait? I think you didn't read it. His characterisation of the FreeBSD Project's attitude towards proprietary drivers fails to mention many of the other factors that get weighed into these decisions, and I think he's missing a lot of history. No, I am well aware of FreeBSD's history and if you don't believe that the project avoids closed-source code then I don't know what to say, frankly. I clearly remember the ruckus over the Adaptec 2740 drivers and the long statement against Adaptec that used to be in the older versions of FreeBSD, that only had AHA 1740 code in them. If things have changed and the majority of the users in the FreeBSD project welcome closed-source code, then please point out where all of this is? I don't see it. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Doug; I would recommend against falling for Ted's flamebait here, since that's really all it is. That's silly, what did you find in it that's flamebait? I think you didn't read it. You're a) misrepresenting the project, b) dismissing the opinions and statements of others that are arguably more in touch with the project, and c) you won't let this stupid thread die. That's all flamebait. His characterisation of the FreeBSD Project's attitude towards proprietary drivers fails to mention many of the other factors that get weighed into these decisions, and I think he's missing a lot of history. No, I am well aware of FreeBSD's history and if you don't believe that the project avoids closed-source code then I don't know what to say, frankly. You could say I'm wrong. It'd be a good start. If things have changed and the majority of the users in the FreeBSD project welcome closed-source code, then please point out where all of this is? I don't see it. This isn't what's being said. See above inre: flamebait. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
- Original Message - From: Ted Mittelstaedt [EMAIL PROTECTED] To: Doug Hass [EMAIL PROTECTED] Cc: Leo Bicknell [EMAIL PROTECTED]; Jim Bryant [EMAIL PROTECTED]; MurrayTaylor [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, October 17, 2001 3:32 PM Subject: RE: FYI -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass Sent: Tuesday, October 16, 2001 9:54 AM To: Ted Mittelstaedt Cc: Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: FYI Let's dispense with all the talk about $75 T1 cards that don't exist (and won't for some time), whose licensing scheme is better, what driver architecture was developed for what reason and let's get back to the original issues: 1) Availability of the 400 series cards. If the FreeBSD market has the 400 series cards in such demand, then someone should be calling me with an order. I'll cut 20% off list for you if you tell me its for FreeBSD, and I'll still pledge 15% of your purchase price on top of that toward driver development. I'll give up my volume margin as a clear indication of my willingness to work with the community. Well, Murray started all this by asking for ONE WANic 400. ;-) I got my one (1) before the EOL cutoff here in OZ ... and am still looking forward to the next generation and to the boss saying can we create another branch office and link 'em up? FreeBSD has an eclectic mix of device drivers - some are personal efforts, some are contributed by corporations, some are ports from other OS's and some are a mix of all of the above. The point is that incentives can take forms other than just money. Getting contributed code is a very powerful incentive, and there's a lot of code in the driver modules for the WANic 5xx, 6xx 8xx and the Aries and Maxim cards that Imagestream has driver code for. Is there any way to get some of this - NOT under GPL and NOT under NDA? There's at least one person during this thread who was looking for a DS-3 card like a WANic 8xx You _did_ mention that some of the card modules in SAND are not under NDA? We might be easier getting 10 buyers for DS3 cards than 100 buyers for WANic 4xx cards, if you get my drift. The drivers BSDI developed and gave to the community for the 400 series are seriously out of date, by the way. Last I knew, they still referred to the cards as the n2pci and used some outdated code that has since been much improved. I'd be interested in working with a developer or developers to get some updated drivers out there for FreeBSD. Doug, as a FYI, I believe that I can fill in a bit on the state of the sr driver. They don't actually refer to the cards as the n2pci (now, at least) They have had work done to them already by John Hay and Julian. This brings me to... 2) Driver development for FreeBSD We'll pledge 15% of the purchase of the aforementioned 400 series cards toward supporting a developer or developers to bring drivers to the FreeBSD market. The 400 series drivers need to be updated. Yes and no - there is one bug in there that needs killing still but otherwise the driver for the 400 is OK. Let me explain the history as I am aware of it. As you stated, BSDI wrote a driver for the RISCom/N2 card and contributed this back to SDL. I believe that this version made it's way to John Hay and formed the base of the FreeBSD sr driver. At some point, this driver was enhanced by either BSDI or SDL to add support for the later RISCom cards that had an integrated T1 CSU. This support does NOT appear in the FreeBSD driver. It's not possible to use port1 (the one with the CSU port) in a FreeBSD system at this time. It may be that John Hay chopped out this support but more likely he was working with an older version of the driver. I have the source for the later N2 driver that has the integrated CSU. It would be nice if someone would put the CSU support into the FreeBSD driver. I looked at doing it myself but there's now big differences between this BSDI/SDL driver and the one in FreeBSD, too much for me to be able to do it. I would gladly loan a disk with this source plus a later model RISComN2 card with the integrated CSU port to anyone who would do it. I'm sure that someone like Julian or John could do it. At any rate, the FreeBSD fork of this driver was later modified to support the PCI version of the RISCom, the WANic 400/405 cards. Since the WANic 405 series has no integrated CSU, the sr driver works with both ports on it. The sr driver has gone through some debugging by John Hay, and Rodney Grimes. I've worked with Rod on this some, and he has discovered 2 bugs that appear on the WANic405 driver. I've verified that both of these bugs exist. The first bug deals with the interrupt handling of the transmit register. It appears on all RISCom and WANic card variants. Rod has
RE: FYI
Is there any way to get some of this - NOT under GPL and NOT under NDA? There's at least one person during this thread who was looking for a DS-3 card like a WANic 8xx You _did_ mention that some of the card modules in SAND are not under NDA? All of the code is licensed under either the LGPL or is available only under NDA. Neither of these should present a problem for developers who want to write FreeBSD drivers (whether they are based on the LGPL'ed SAND or are monolithic). We might be easier getting 10 buyers for DS3 cards than 100 buyers for WANic 4xx cards, if you get my drift. Well, if people don't mind buying cards with no drivers...The reason for offering the 400 series at a discount was to solve the supply issue that you raised originally. Doug, as a FYI, I believe that I can fill in a bit on the state of the sr driver. They don't actually refer to the cards as the n2pci (now, at least) They have had work done to them already by John Hay and Julian. I'm glad to hear that the name was corrected. If someone is interested, there is a newer development kit (actually several newer ones) that would improve that driver significantly, especially in high load situations. I'm certain that those improvements are not in the driver, since the development kit containing them is only available under license. This support does NOT appear in the FreeBSD driver. It's not possible to use port1 (the one with the CSU port) in a FreeBSD system at this time. It may be that John Hay chopped out this support but more likely he was working with an older version of the driver. There's no reason that you can't use the N2csu port in a FreeBSD system. The code to do this has been freely available for nearly 6 years. We released a version of the n2 code to open source as well. The second bug only appears on WANic 405's and is triggered by high volume rates on both interfaces simultaneously. Rod has been unable to isolate the problem but he and I confirmed that it only appears with dual-port cards. The bug causes about 10% packet loss to be noted on a Pentium 200. I believe that it is possible to minimize the effects of this bug by using the cards in a much faster CPU. Actually, it will happen with the one-port cards, too. As you increase the CPU or the clock rate, the problem gets worse. We've fixed this (among other things), which is why I recommended getting ahold of the newer DDK. Other than that the FreeBSD sr driver is stable, has not caused a crash or other problem on the hardware I've used it on over the last year and a half, on a busy Internet router that runs BGP. Great! That's what I like to hear. The hardware is quite reliable and well-proven, and I'm glad your drivers are working well. Well, we _had_ a solution - the 400/405 that worked well, and has a Netgraph-enabled driver for it. I guess that nobody let you guys know at Imagestream that developers in the FreeBSD community were maintaining the old BSDI driver. Sigh. We knew that the driver had undergone some maintainence. It still has bugs, and doesn't take advantage of the later code advances in the development kit, but if it works well enough for you, then that's not an issue. If you don't want to improve the driver beyond where it is now, that's definitely up to you. You know that improvements and bug fixes exist if you ever decide they are affect your use of the card enough to put them in place. What we don't have is a solution for the 5xx and later cards. But I think that there would be even more interest on a DS3 card like the WANic 8xx Development tools for the later cards have been freely available (under NDA) for 5 years now. No one is holding anyone in the FreeBSD community back. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
Doug, in the entire history of the FreeBSD project, when given a choice between a better driver or code that is closed source, and a worse driver that has open source, the FreeBSD community has never chosen the driver or code with closed source. In fact I can only remember ONCE that the Project has recommended against freely available BSD code - and they did so in favor of GPL code, not closed source code - and this was for the coprocessor emulator (used for 386 and 486SX chips only) The only time that FreeBSD gets involved in closed-source code is when there is simply NO other alternative - like in this case where the register interface specs are being withheld. We certainly support the right for companies to protect their intellectual property in whatever way they see fit, even if the FreeBSD community does not. The lack of flexibility in accepting various requirements illustrates the difference between an OS WITH legs in the market and one WITHOUT legs. Much to my chagrin, FreeBSD continues to fall more and more into the latter category. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Doug, in the entire history of the FreeBSD project, when given a choice between a better driver or code that is closed source, and a worse driver that has open source, the FreeBSD community has never chosen the driver or code with closed source. In fact I can only remember ONCE that the Project has recommended against freely available BSD code - and they did so in favor of GPL code, not closed source code - and this was for the coprocessor emulator (used for 386 and 486SX chips only) The only time that FreeBSD gets involved in closed-source code is when there is simply NO other alternative - like in this case where the register interface specs are being withheld. We certainly support the right for companies to protect their intellectual property in whatever way they see fit, even if the FreeBSD community does not. Doug; I would recommend against falling for Ted's flamebait here, since that's really all it is. His characterisation of the FreeBSD Project's attitude towards proprietary drivers fails to mention many of the other factors that get weighed into these decisions, and I think he's missing a lot of history. The lack of flexibility in accepting various requirements illustrates the difference between an OS WITH legs in the market and one WITHOUT legs. And you probably shouldn't try to respond with generalisations that are meant to be personal attacks. Think about who you're trying to endear yourself to, eh? Much to my chagrin, FreeBSD continues to fall more and more into the latter category. If we're legless, it's probably because we're drunk on our own success. 8) Seriously though; if you don't want to release sources for a driver for whatever reason, that's fine. But bear in mind that if you don't support your binary-only driver in a realistic and attentive fashion, you're going to make people unhappy, and they will turn to solutions that they can maintain themselves, or that they can badger other people into maintaining. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
We certainly support the right for companies to protect their intellectual property in whatever way they see fit, even if the FreeBSD community does not. Doug; I would recommend against falling for Ted's flamebait here, since that's really all it is. His characterisation of the FreeBSD Project's attitude towards proprietary drivers fails to mention many of the other factors that get weighed into these decisions, and I think he's missing a lot of history. I'm glad someone else is speaking up--all I've heard is Ted's point of view (from him, and from others who have said the same thing: FreeBSD only accepts BSD licensed code, period.) The lack of flexibility in accepting various requirements illustrates the difference between an OS WITH legs in the market and one WITHOUT legs. And you probably shouldn't try to respond with generalisations that are meant to be personal attacks. Think about who you're trying to endear yourself to, eh? Much to my chagrin, FreeBSD continues to fall more and more into the latter category. If we're legless, it's probably because we're drunk on our own success. 8) It's not a generalization at all. Honestly, compared to the market traction that Linux, VxWorks, Solaris and others have, FreeBSD is definitely without legs. The WAN card and RAS card markets are good examples of where the attitude toward BSD-licensed code or bust has resulted in FreeBSD being largely left out of the party. Three of the largest manufacturers in these segments (SBS, Cyclades, and Ariel) all support Linux and NT, but do not have BSD support. I've been frusturated repeatedly over the past few years as I try to continue to use FreeBSD myself for different applications. It's too bad we can't find a way to include more companies and solutions instead of continuing to find ways to EXCLUDE them... Seriously though; if you don't want to release sources for a driver for whatever reason, that's fine. But bear in mind that if you don't support your binary-only driver in a realistic and attentive fashion, you're going to make people unhappy, and they will turn to solutions that they can maintain themselves, or that they can badger other people into maintaining. Agreed. Maintaining code has never been a problem for us. We're talking about someone else in the FreeBSD community maintaining these drivers, though, not ImageStream. Their attentiveness to bugs would directly impact that. This will be my last message on this topic. I feel as if this discussion is going round and round and has no real end or purpose at this point. I'll quit wasting bandwidth. :-) If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. Just package your driver with your cards, or stick it on your support site. The whole point being that you don't *have* to get your code into the tree; you can maintain it successfully without either a) introducing overhead for us handling your module, or b) introducing latency for you trying to push a new version through our release process. I get the impression you haven't quite gotten the idea here yet; you don't *need* to be in the base distribution, and in many cases it's better not to be simply because it involves less work for everyone. O.k.--one more message. :-) We don't want to be in the base distribution. Never have wanted to be, nor have I indicated in my messages that we wanted to be. All we would like to see drivers for FreeBSD available in the market. Period. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
* Doug Hass [EMAIL PROTECTED] [011017 12:51] wrote: If anyone has an interest in adding support for the SBS WAN cards to FreeBSD, feel free to contact me. I'll be glad to help. Just package your driver with your cards, or stick it on your support site. The whole point being that you don't *have* to get your code into the tree; you can maintain it successfully without either a) introducing overhead for us handling your module, or b) introducing latency for you trying to push a new version through our release process. I get the impression you haven't quite gotten the idea here yet; you don't *need* to be in the base distribution, and in many cases it's better not to be simply because it involves less work for everyone. O.k.--one more message. :-) We don't want to be in the base distribution. Never have wanted to be, nor have I indicated in my messages that we wanted to be. All we would like to see drivers for FreeBSD available in the market. Period. peanut gallery Even if you wanted it in the base source under a GPL license, we could put it under sys/contrib which is where we put things with questionable licenses. We've also given CVS access to gateway developers at companies in order to improve on their drivers in the past and allow us to modify the driver to take into account for interface changes within our bus and system archetectures. /peanut gallery Having it in the base is actually kind of cool and doesn't require much effort, the only problem I see is that what you want to add requires a subsystem that is under unfavourable license restrictions that might require modifications to the base. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
If you didn't say it, then you weren't the one I was talking about, was I? :-) I got several other private mails saying that BSD licensed code was the one and only way, and 2 or 3 mails (from Ben, among others) saying that BSD-licensed was preferred. Either approach is as flawed as someone who claims GPL only or GPL preferred. The license terms of add-on drivers and products should be set according to the needs of the authoring person or company, in my opinion. Doug On Wed, 17 Oct 2001, void wrote: On Wed, Oct 17, 2001 at 12:19:34PM -0500, Doug Hass wrote: I'm glad someone else is speaking up--all I've heard is Ted's point of view (from him, and from others who have said the same thing: FreeBSD only accepts BSD licensed code, period.) I said to you in private mail that where there's a BSD-licensed solution and a non-BSD-licensed solution, all else being roughly equal, FreeBSD tends towards the BSD-licensed solution. Not the same thing at all. -- Ben An art scene of delight I created this to be ...-- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Let me cut through all this with a bit of experience if you permit: 1. BSD licensed sources are undoubtedly always preferred. 2. Other open-source licences are the best alternative. 3. closed source solutions are always risky because you don't know if the company will be willing to, or even around to, update the driver for future versions of the OS. One way to moderate #3 is to do as we did with the DiskOnChip driver for M-systems flash-disks: They gave a copy under NDA to an open source developer (me) who then produces an object only driver. That way at least one person will be able to produce new versions of the driver if the company goes titsup.com or gets bought by M$ or whatever... Over and out... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
We certainly support the right for companies to protect their intellectual property in whatever way they see fit, even if the FreeBSD community does not. Oh my. I can see that we've gone somewhat polemic here. As someone who's been around since the very beginning, I think I can fairly state that this point of view mischaracterizes the FreeBSD community somewhat. We're not against companies protecting their intellectual property at all, and the number of companies using FreeBSD in closed-source applications with the full approval of the FreeBSD community (where approval is construed by a lack of flames and general pride at FreeBSD's role in each instance) is considerable and growing. What I think Ted may be referring to, and you should be clear on the fact that Ted sometimes finds it difficult to express himself in less than hyperbolic terms, is the fact that the base FreeBSD product is one that we take special pains to keep unencumbered for exactly the reasons expressed above. If we're to continue to bill FreeBSD as a product which can be used for any purpose, we need to be careful about the licenses used for its various fundamental building blocks so that *third parties* don't get into trouble by perhaps naively assuming that all of FreeBSD is BSD copyrighted. It wouldn't hurt the FreeBSD Project at all if we started distributing some drivers in binary form only (though it would add to our tech support load in having to explain that driver foo was only supported by ABI bar), but it would potentially hurt an embedded systems developer to grab the whole ball of wax and productize it, only to have someone in legal suddenly get to that particular part of the audit and go Hey! This driver doesn't allow commercial re-use! What the hell does engineering think it's doing?! Sure, it's THEIR problem to deal with and not ours, but those same engineers won't exactly be thanking us for slipping a hand grenade amidst the roses where they didn't notice it. If the project wants to keep making friends in that community, it's encumbent on it to do as much proactive segregation of differently-licensed code as possible and impose some reasonable standards on what's brought into the base and what's kept at arm's length, again not for its purposes but for the purposes of those who might be re-using it later. That's why the GPL code lives in /usr/src/gnu and /usr/src/sys/gnu - not because we hate GPL code but because we want to make it very clear just what parts needs to be subtracted by any 3rd party doing truly closed-source development. It's also why we prefer BSD-copyrighted solutions to GPL'd ones if we have a choice - it's just simpler all the way down the line. I fully support your idea of offering a bounty to anyone writing drivers for your cards and think you're being more than generous in offering it. I wish more vendors would do that and I'm sorry that this discussion has gotten as polarized as it has. If people want to change the support situation for T1 cards, they need to get off their duffs and write the code - as a vendor, you're doing all that might be expected and more to facilitate the process. I hope the zealots in the audience realize that too. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
In message [EMAIL PROTECTED], Jordan Hubbard writes: I fully support your idea of offering a bounty to anyone writing drivers for your cards and think you're being more than generous in offering it. I wish more vendors would do that and I'm sorry that this discussion has gotten as polarized as it has. If people want to change the support situation for T1 cards, they need to get off their duffs and write the code Hey, I got two drivers under my belt already, although only E1, but isn't that enough for a beginning ? :-) I fully agree with Jordan btw, that is a very clear explanation of the situation. And as I said, we do have precedence and procedures for shipping binary drivers with FreeBSD. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
At 12:50 PM -0700 10/17/01, Jordan Hubbard wrote: I fully support your idea of offering a bounty to anyone writing drivers for your cards and think you're being more than generous in offering it. I wish more vendors would do that and I'm sorry that this discussion has gotten as polarized as it has. If people want to change the support situation for T1 cards, they need to get off their duffs and write the code - as a vendor, you're doing all that might be expected and more to facilitate the process. I hope the zealots in the audience realize that too. The freebsd project is really just a bunch of users who happen to use and work on freebsd. The group of users is such that we'll always PREFER a completely open-source BSD-licensed driver to other alternatives. However, it is also true that the vast majority of those users will prefer having a driver to NOT having a driver! :-) I think that offering some sort of bounty to have a freebsd developer work on drivers for your cards, under NDA, is a generous offer. I'm not the kind of person who writes drivers, but I certainly hope that someone takes you up on the offer. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: Doug Hass [mailto:[EMAIL PROTECTED]] Sent: Monday, October 15, 2001 6:53 AM To: Ted Mittelstaedt Cc: Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alfred Shippen Subject: RE: FYI Hi Doug, I'm going to address myself to these points openly as there's some points here which we all need to be familiar with. We are bound by third party agreements and are not allowed to release any more free code (legally) than we already have. If we were not restricted by SBS, Trillium, and Rockwell (among others), we would release all of the code under GPL or lGPL. These agreements do NOT prevent us from working with developers to support other platforms, though. It only prevents the free release of portions of the code. You said in a mail to Leo, the following: Unfortunately, the API to the cards (the driver development kit, hardware programming specifications or whatever you want to call them) are licensed from several third parties and we are bound by agreement not to make them public. I'm going to assume that the programming specs you refer to here are what is being licensed from SBS, Trillium, and Rockwell, because either Rockwell or Trillium is the actual manufacturer of the sync chip. I'll assume that SBS is just making the support chips on the board and the interface chips to the PCI bus. Now, let me discuss for a moment how the current Imagestream WAN drivers operate. (based on my reading of the public code, which of course may be incorrect) Please feel free to interject where you feel I'm full of crap. :-) The hardware API or the actual register interface code, is a binary-only module that is snapped in to SAND. SAND is GPL and is similar to the FreeBSD Netgraph module - it provides all the higher-level protocol stuff, like Frame Relay, PPP, HDLC, and such. SAND goes between the OS TCP/IP stack and that binary only module. Imagestream has no problem releasing SAND for public consumption basically because all that PPP/HDLC/Frame and other datalink code is already available, PPP code has been available for time out of mind from many places, (including BSD) long before Imagestream ever wrote SAND, and Cisco HDLC was reverse-engineered some time ago (Besides that, Cisco gave up trying to hide their HDLC interface once Wellfleet/Bay Networks died) Obviously, Imagestream had to do some work, but I'd say a lot of it was in the area of supporting these binary snap in modules. The reason that Imagestream went this road is that like Doug said, all those hardware vendors like Rockwell think that there's something valuable in a pure register interface spec publication for their products. So, this way Imagestream can sign their souls away to get access to that interface spec - but they isolate all that contaminated code in this binary snap-in module. It's a hack of a solution but unfortunately is getting more and more common under UNIX because the Linux people have caved in and are busily screwing their own principles of GPL, by soliciting ever greater amounts of closed-source, Linux code. Imagestream isn't the only one out there doing this. Now, you can make all the technical arguments you want about how a modularized development environment like this allows code reuse and this is quite true - but you must keep in mind that SAND's modularized development has a primary goal of being able to keep the contaminated code in the driver snap-in modules, code reuse is secondary. There's other modularized driver development models in which EVERYTHING is publically available including the modules. That being said, we're always interested in supporting a wide variety of platforms. Without the SAND architecture, though, there really is little hope of having FreeBSD support for the WANic 520 series cards (or other cards, for that matter). This is correct and incorrect. It's correct because what Imagestream wants to have to be able to easily graft in FreeBSD to their supported UNIX os's is SAND - if done right then the actual driver module itself would have trivial changes whether used on FreeBSD or Linux, so you don't have to do much other than keep SAND maintained in FreeBSD. It's incorrect because it's perfectly possible to write a monolithic driver under FreeBSD that's only available as an object module and instead links in to the FreeBSD answer to SAND - which is Netgraph. This is exactly how the WANic 400 driver is now. (except of course the WANic 4xx driver is source available) Of course, this object module will have to be recompiled for every new version of FreeBSD, because it has to either be mod-loaded into the kernel or statically compiled into it. It's a rather icky proposition for a company like Imagestream to contemplate from a support perspective. But it certainly is NOT impossible. If there are developers in the community interested in porting SAND and the various hardware modules (for the 520 series and other cards) to FreeBSD, we'll
RE: FYI
-Original Message- From: Doug Hass [mailto:[EMAIL PROTECTED]] Sent: Monday, October 15, 2001 8:04 AM To: Leo Bicknell Cc: Ted Mittelstaedt; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alfred Shippen Subject: Re: FYI Would your agreements allow you to provide resources to a small number of developers (under NDA and all that of course) to produce drivers that you would then release in binary form (eg a kernel module) under a free license? It sure would. If you cannot release the source code to your drivers, can you release hardware programming specifications (again, perhaps under NDA) that allowed someone to develop an independant free licensed driver? Unfortunately, the API to the cards (the driver development kit, hardware programming specifications or whatever you want to call them) are licensed from several third parties and we are bound by agreement not to make them public. The 400 series cards (and, for that matter, the RISCom/N2 series cards) did not require an API, which is how BSDI and FreeBSD drivers came about in the first place. As I mentioned above, we CAN license the driver code and the DDK for development. This means that you could produce FreeBSD drivers which we could then distribute in a binary form under a free end-user license. Frankly this is the only way I can see that FreeBSD drivers for the 5xx series would ever come about. Porting SAND over, while having advantages of long term support, is just overkill for this, besides which it's unlikely you will get a FreeBSD developer to work on GPL code. This would end up putting a WANic 5xx driver into the same status as the drivers for the Emerging Technologies, or Sangoma sync cards, which both come with binary-only FreeBSD drivers. It would actually have a leg up over those drivers because it would have Netgraph hooks and I believe that the Sangoma drivers don't (but I've never worked with the Sangoma cards so I don't know for certain) If the register interface to the 5xx cards wasn't tremendously different than the 4xx cards then the sr driver would be a good skeleton to start with. While the offer of the DDK is nice, my guess is most of the code in it is for making SAND modules. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: Doug Hass [mailto:[EMAIL PROTECTED]] Sent: Monday, October 15, 2001 8:56 AM To: Leo Bicknell Cc: Ted Mittelstaedt; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: FYI In a private e-mail, Leo writes: You offered a discount on these boards on the list. If you think there is a real opportunity to sell these to the *BSD crowd, I recomend you take that 15% (or some part of it) and offer to partially fund a driver developer. There are many freelance programmers working on the project who for $1000-$5000 (depending on complexity) could make your driver a reality. A good developer could probably also make them work under OpenBSD and NetBSD in one fell swoop. I'd be happy to pledge the 15% to a driver developer. That's a great idea! It will accomplish two objectives: 1) There will be at least 100 WANic 400 series cards available for purchase to support existing installations (assuming someone out there places the order). 2) ImageStream will pledge 15% of the purchase price of any lots of these 400 series cards toward porting of our SAND architecture to FreeBSD. That's a MINIMUM of $8,100 that ImageStream is willing to pay a developer or group of developers to port the drivers for the rest of the cards. Ted--you've indicated that there is a significant market for the 400 series cards in the community. There is depending on the price. I'll freely admit however that I have not priced the competitive serial sync cards that are currently supported under FreeBSD, so I don't know how the WANic 400 or 500 stacks up against them. For all I know right now there's someone just bringing a T1 interface card to the market with integrated CSU that sells for $30 per card which would make this entire discussion moot. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
The hardware API or the actual register interface code, is a binary-only module that is snapped in to SAND. SAND is GPL and is similar to the FreeBSD Netgraph module - it provides all the higher-level protocol stuff, like Frame Relay, PPP, HDLC, and such. SAND goes between the OS TCP/IP stack and that binary only module. That's rather simplified, since SAND also does alot of other things, but you have the basics. The reason that Imagestream went this road is that like Doug said, all those hardware vendors like Rockwell think that there's something valuable in a pure register interface spec publication for their products. So, this way Imagestream can sign their souls away to get access to that interface spec - but they isolate all that contaminated code in this binary snap-in module. It's a hack of a solution but unfortunately is getting more and more common under UNIX because the Linux people have caved in and are busily screwing their own principles of GPL, by soliciting ever greater amounts of closed-source, Linux code. Imagestream isn't the only one out there doing this. Well, not exactly. The SAND architecture was written long before we ever licensed one line of code from ANYONE. The idea behind the hardware modules was very similar to what Netgraph provides. You can snap in new hardware, software or pre- and post-processing modules without having to make accomodations in the other code. Now, you can make all the technical arguments you want about how a modularized development environment like this allows code reuse and this is quite true - but you must keep in mind that SAND's modularized development has a primary goal of being able to keep the contaminated code in the driver snap-in modules, code reuse is secondary. Again, this is incorrect. Code reuse and shorter devlopment cycles were the reason for SAND. The hardware module code is NOT all licensed code. With the exception of the ATM cards, there's more free code than licensed code in the hardware modules. It's incorrect because it's perfectly possible to write a monolithic driver under FreeBSD that's only available as an object module and instead links in to the FreeBSD answer to SAND - which is Netgraph. This is exactly how the WANic 400 driver is now. (except of course the WANic 4xx driver is source available) It is possible to have a monolithic driver set, but it doesn't accomplish the objective that we have (and you noted): to have ONE code tree for ALL platforms (save Windows, which is a different animal altogether). We don't want to see a return to the monolithic drivers of old under ANY platform. I'm not saying that monolithic drivers aren't possible, just that they aren't going to happen again. But you see that in this area SAND is no more standard than Netgraph is. SAND provides Linux users that run WANic cards a lot of stuff - but it is GPL which makes it difficult to use in many commercial FreeBSD projects. I don't think the use of GPL or LGPL prevents anyone from using it in a commercial project with FreeBSD, Linux or any OS. ImageStream, and other companies, are successfully using GPL and LGPL code in commercial projects. It's been discussed to death in this forum before but the worst possible thing that Imagestream could have done was to put SAND under GPL. If you had simply put it under BSD license then BOTH the BSD and Linux people could have used it, in fact Netgraph may have never been written, and a lot of other commercial UNIX's might have used it too (like Apple's MacOS X) I'll disagree, but the discussion is digressing here from where we started. I'm as disinterested in a license war as I was in an OS war. I believe you, I believe you. But, did the decision makers at SBS even know that the BSD community currently can't use the 500 series and above? And that discontinuting it would cut out that section of their market? Did you guys know that? They knew it. We knew it. It was such a small portion of the total market that they didn't care. We care, which is why I'm taking the time to have this discussion with all of you. During that time I've seen WANic or RISCom cards come up for bid exactly SIX times. And, THREE of the times I was the sole bidder and bought them. The other three times, well one was a 56K card, another the seller wanted $500 (hah) and the other the seller wanted another rediculous amount. During that time I've also kept tabs on what the commercial networking resale vendors that I also buy from have been doing and I've not seen anything at all marked RISCom, WANic, or Imagestream. So it's a limited option. I'd never buy commodity hardware used when you could buy it new for next to nothing (compared to even most USED Cisco gear). 1) The cards are almost impossible to identify if they are just loose with no documentation. Some vendors slap their moniker in unmistakable letters across all their cards, SDL/SBS and you
RE: FYI
There is depending on the price. I'll freely admit however that I have not priced the competitive serial sync cards that are currently supported under FreeBSD, so I don't know how the WANic 400 or 500 stacks up against them. For all I know right now there's someone just bringing a T1 interface card to the market with integrated CSU that sells for $30 per card which would make this entire discussion moot. $30 per card? Do tell, do tell. I'll buy 10,000 of them right now, and pay you $60 a card to buy them for me. What company would be foolish enough to offer a $30 T1 card? I have my credit card ready! Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass Sent: Tuesday, October 16, 2001 7:28 AM To: Ted Mittelstaedt Cc: Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: FYI There is depending on the price. I'll freely admit however that I have not priced the competitive serial sync cards that are currently supported under FreeBSD, so I don't know how the WANic 400 or 500 stacks up against them. For all I know right now there's someone just bringing a T1 interface card to the market with integrated CSU that sells for $30 per card which would make this entire discussion moot. $30 per card? Do tell, do tell. I'll buy 10,000 of them right now, and pay you $60 a card to buy them for me. What company would be foolish enough to offer a $30 T1 card? I have my credit card ready! :-) That was an example only, exaggerated to illustrate a point. But, it's a point with some validity too - if T1 circuits were as common as DSL circuits, and DSL circuits were like T1's in volume, you would see ADSL chipsets at the sync port chipset pricing levels, and sync port chipsets at the $30 range. As you pointed out this is a volume thing. Before anyone would dump $50K into a special order of WANic 400 cards, you would need to do a comparison of what's currently available in the market. As someone else pointed out in this forum, the Hitachi chipset is an older design. I'm sure that it's probably possible today to design a sync controller chip that sells for a lot less than the Hitachi part, perhaps even under the $30 level. Certainly, async chips sell at that level in volume. It's too bad that IBM didn't decide to put a sync serial port on the original XT. :-) Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
As someone else pointed out in this forum, the Hitachi chipset is an older design. I'm sure that it's probably possible today to design a sync controller chip that sells for a lot less than the Hitachi part, perhaps even under the $30 level. Certainly, async chips sell at that level in volume. It's too bad that IBM didn't decide to put a sync serial port on the original XT. :-) The conjecture and wishful thinking is nice. Unfortunately, the available chipsets today aren't running at or anywhere near the $30 range, which is why you don't see $75 T1 cards with CSUs (you see $750-$1200 ones). Let's dispense with all the talk about $75 T1 cards that don't exist (and won't for some time), whose licensing scheme is better, what driver architecture was developed for what reason and let's get back to the original issues: 1) Availability of the 400 series cards. If the FreeBSD market has the 400 series cards in such demand, then someone should be calling me with an order. I'll cut 20% off list for you if you tell me its for FreeBSD, and I'll still pledge 15% of your purchase price on top of that toward driver development. I'll give up my volume margin as a clear indication of my willingness to work with the community. The drivers BSDI developed and gave to the community for the 400 series are seriously out of date, by the way. Last I knew, they still referred to the cards as the n2pci and used some outdated code that has since been much improved. I'd be interested in working with a developer or developers to get some updated drivers out there for FreeBSD. This brings me to... 2) Driver development for FreeBSD We'll pledge 15% of the purchase of the aforementioned 400 series cards toward supporting a developer or developers to bring drivers to the FreeBSD market. The 400 series drivers need to be updated. There are a full line of cards available now that also need drivers. Even if no one in the community is willing to pledge money (through a card purchase or directly to a developer), I'm assuming that someone out there would be interested in developing the drivers. Again, if the FreeBSD market has WAN cards in such a high demand, we need to get developers on the driver development immediately. Now that you know we are interested, the code is available, and that we've pledged money toward it, I'd like to see someone in the community start working toward a solution, instead of complaining about how there isn't one. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
On Tue, 16 Oct 2001, Doug Hass wrote: The hardware API or the actual register interface code, is a binary-only module that is snapped in to SAND. SAND is GPL and is similar to the FreeBSD Netgraph module - it provides all the higher-level protocol stuff, like Frame Relay, PPP, HDLC, and such. SAND goes between the OS TCP/IP stack and that binary only module. That's rather simplified, since SAND also does alot of other things, but you have the basics. If there's a published interface, we could make a netgraph/SAND interface module To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
If there's a published interface, we could make a netgraph/SAND interface module I think it's better use of hackers' time to look at vendors who already support FreeBSD, such as SBEI and Cyclades, and see why their support for FreeBSD, while apparently useful, is behind the functionality they have in their Linux drivers and if hackers can help them improve their FreeBSD support, adapt netraph, multilink ppp, channelized RAS, etc. Unfortunately, I still looking for somebody who actually uses SBEI and Cyclades T1 boards with FreeBSD. Len http://MenAndMice.com/DNS-training http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
On Tue, Oct 16, 2001 at 06:35:43PM -0500, Len Conrad wrote: Unfortunately, I still looking for somebody who actually uses SBEI and Cyclades T1 boards with FreeBSD. I ran across them earlier when looking for what T1 boards were out there. Their boards seem nice, and they do have a driver, in full source form, that is out of date. The one thing I can't find, is prices. I know that I have never considered using a FreeBSD box to terminate a T1, in part because I didn't think there was reasonable hardware available, and good drivers to support it. I think if someone does make this work, they need to proclaim it loudly in all sorts of FreeBSD forms to drum up interest. I think it's out there, just dorment. -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
On Tue, 16 Oct 2001, Len Conrad wrote: Unfortunately, I still looking for somebody who actually uses SBEI and Cyclades T1 boards with FreeBSD. With IBM 2210 series routers going for well under $100 on the used market I can't see why anyone would opt for a host based solution. The people with cash are gonna go with Cisco anyway so unless the host based solution has great support and lots of features I can't see how any vendor could justify getting into this market. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
Better than a published interface and white paper, we also provide the direct code itself. You could certainly make a netgraph/SAND interface module. Doug On Tue, 16 Oct 2001, Julian Elischer wrote: On Tue, 16 Oct 2001, Doug Hass wrote: The hardware API or the actual register interface code, is a binary-only module that is snapped in to SAND. SAND is GPL and is similar to the FreeBSD Netgraph module - it provides all the higher-level protocol stuff, like Frame Relay, PPP, HDLC, and such. SAND goes between the OS TCP/IP stack and that binary only module. That's rather simplified, since SAND also does alot of other things, but you have the basics. If there's a published interface, we could make a netgraph/SAND interface module To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Julian Elischer Sent: Tuesday, October 16, 2001 5:29 PM To: Doug Hass Cc: Ted Mittelstaedt; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alfred Shippen Subject: RE: FYI On Tue, 16 Oct 2001, Doug Hass wrote: The hardware API or the actual register interface code, is a binary-only module that is snapped in to SAND. SAND is GPL and is similar to the FreeBSD Netgraph module - it provides all the higher-level protocol stuff, like Frame Relay, PPP, HDLC, and such. SAND goes between the OS TCP/IP stack and that binary only module. That's rather simplified, since SAND also does alot of other things, but you have the basics. If there's a published interface, we could make a netgraph/SAND interface module Well, you might want to take a shortcut and leave the SAND code out of this and just make that interface one that the driver modules that would normally snap into SAND use. The modules would think that Netgraph is SAND? The goal would be to be able to make use of all the SAND modules that Imagestream has. Then all Imagestream's programmers would need to do is add in defines to the module code for FreeBSD and build the modules. While it's not a _port_ of SAND per-se, it's an emulation of it. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass Sent: Tuesday, October 16, 2001 9:54 AM To: Ted Mittelstaedt Cc: Leo Bicknell; Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: FYI Let's dispense with all the talk about $75 T1 cards that don't exist (and won't for some time), whose licensing scheme is better, what driver architecture was developed for what reason and let's get back to the original issues: 1) Availability of the 400 series cards. If the FreeBSD market has the 400 series cards in such demand, then someone should be calling me with an order. I'll cut 20% off list for you if you tell me its for FreeBSD, and I'll still pledge 15% of your purchase price on top of that toward driver development. I'll give up my volume margin as a clear indication of my willingness to work with the community. Well, Murray started all this by asking for ONE WANic 400. ;-) FreeBSD has an eclectic mix of device drivers - some are personal efforts, some are contributed by corporations, some are ports from other OS's and some are a mix of all of the above. The point is that incentives can take forms other than just money. Getting contributed code is a very powerful incentive, and there's a lot of code in the driver modules for the WANic 5xx, 6xx 8xx and the Aries and Maxim cards that Imagestream has driver code for. Is there any way to get some of this - NOT under GPL and NOT under NDA? There's at least one person during this thread who was looking for a DS-3 card like a WANic 8xx You _did_ mention that some of the card modules in SAND are not under NDA? We might be easier getting 10 buyers for DS3 cards than 100 buyers for WANic 4xx cards, if you get my drift. The drivers BSDI developed and gave to the community for the 400 series are seriously out of date, by the way. Last I knew, they still referred to the cards as the n2pci and used some outdated code that has since been much improved. I'd be interested in working with a developer or developers to get some updated drivers out there for FreeBSD. Doug, as a FYI, I believe that I can fill in a bit on the state of the sr driver. They don't actually refer to the cards as the n2pci (now, at least) They have had work done to them already by John Hay and Julian. This brings me to... 2) Driver development for FreeBSD We'll pledge 15% of the purchase of the aforementioned 400 series cards toward supporting a developer or developers to bring drivers to the FreeBSD market. The 400 series drivers need to be updated. Yes and no - there is one bug in there that needs killing still but otherwise the driver for the 400 is OK. Let me explain the history as I am aware of it. As you stated, BSDI wrote a driver for the RISCom/N2 card and contributed this back to SDL. I believe that this version made it's way to John Hay and formed the base of the FreeBSD sr driver. At some point, this driver was enhanced by either BSDI or SDL to add support for the later RISCom cards that had an integrated T1 CSU. This support does NOT appear in the FreeBSD driver. It's not possible to use port1 (the one with the CSU port) in a FreeBSD system at this time. It may be that John Hay chopped out this support but more likely he was working with an older version of the driver. I have the source for the later N2 driver that has the integrated CSU. It would be nice if someone would put the CSU support into the FreeBSD driver. I looked at doing it myself but there's now big differences between this BSDI/SDL driver and the one in FreeBSD, too much for me to be able to do it. I would gladly loan a disk with this source plus a later model RISComN2 card with the integrated CSU port to anyone who would do it. I'm sure that someone like Julian or John could do it. At any rate, the FreeBSD fork of this driver was later modified to support the PCI version of the RISCom, the WANic 400/405 cards. Since the WANic 405 series has no integrated CSU, the sr driver works with both ports on it. The sr driver has gone through some debugging by John Hay, and Rodney Grimes. I've worked with Rod on this some, and he has discovered 2 bugs that appear on the WANic405 driver. I've verified that both of these bugs exist. The first bug deals with the interrupt handling of the transmit register. It appears on all RISCom and WANic card variants. Rod has written a patch for this and the patch works. Without the patch, the cards lose packets. John has not gotten a copy of this patch nor integrated it into the current version of the sr driver, unfortunately. The patch is for 1.34.2.2 of the driver that comes in FreeBSD 4.3 and unfortunately Rod got it completed after John made more changes. I don't think Rod has reved it to the current rev. The second bug only appears on WANic 405's and is triggered by high volume rates on both interfaces simultaneously. Rod has been unable to isolate the problem but he and I
RE: FYI
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass Sent: Sunday, October 14, 2001 7:23 PM To: Jim Bryant Cc: Ted Mittelstaedt; [EMAIL PROTECTED]; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alfred Shippen Subject: Re: FYI Also--understand that the replacement for the 400 and 405 is a multi-interface card (supports all of the wiring specs instead of just 1), and costs virtually the same (or less as a reseller or in volume) than the 400/405 did. And if you want to sell these to FreeBSD users then make your Linux driver source (not the SAND stuff) available so that we can mod it into our own driver. Many other companies do this and as a matter of fact, we (meaning FreeBSD) have even found bugs in crummy Linux drivers that have been reported back to Linux and helped those manufacturers better their products. No offense, but once Imagestream stopped selling WANic400's you ceased being an entity of interest to FreeBSD, as you no longer sell any products that run under it. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com Doug On Sun, 14 Oct 2001, Jim Bryant wrote: No offense to you or your sales partners, but the way I see it, this means that tons of these will be available for a song on eBay soon, and will be in the hands of a lot of FreeBSD and Linux people [not all of which can afford top-of-the-line all of the time]. Doug Hass wrote: Ted, We're SBS' worldwide distributor. Others who resell them buy them from us or from one of our distributors. In any case, I can ASSURE you without a doubt that the WANic 400 series and the entire RISCom/N2 series are end of life as of the end of September. If you have questions, feel free to contact me at your convenience. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
And if you want to sell these to FreeBSD users then make your Linux driver source (not the SAND stuff) available so that we can mod it into our own driver. Many other companies do this and as a matter of fact, we (meaning FreeBSD) have even found bugs in crummy Linux drivers that have been reported back to Linux and helped those manufacturers better their products. I'm not going to get dragged into an OS war. Both Linux and FreeBSD have their share of crummy drivers and features. That discussion is honestly beyond the scope of a discussion of ImageStream's SAND architecture and the WANic 400 series. We are bound by third party agreements and are not allowed to release any more free code (legally) than we already have. If we were not restricted by SBS, Trillium, and Rockwell (among others), we would release all of the code under GPL or lGPL. These agreements do NOT prevent us from working with developers to support other platforms, though. It only prevents the free release of portions of the code. That being said, we're always interested in supporting a wide variety of platforms. Without the SAND architecture, though, there really is little hope of having FreeBSD support for the WANic 520 series cards (or other cards, for that matter). If there are developers in the community interested in porting SAND and the various hardware modules (for the 520 series and other cards) to FreeBSD, we'll be happy to work with them and support that effort. It is in ALL of our interests to have the widest support for standards-based technologies as possible. No offense, but once Imagestream stopped selling WANic400's you ceased being an entity of interest to FreeBSD, as you no longer sell any products that run under it. I'll reiterate what I've said to you privately: ImageStream DID NOT make the decision to discontinue the 400 series or the RISCom/N2 series. This decision rested solely with SBS. However, FreeBSD users are NOT without options: 1) FreeBSD users can still get the WANic 400 and RISCom cards from the second hand market, as another person mentioned. 2) WANic 400 series cards are still available in quantity. If the market for FreeBSD is as large as you claim, then you or someone else in the community should have no problem snapping up a quantity of these cards and reselling them to interested parties. I'll go one step further: If anyone contacts me about the WANic 400 series, mentions that they are for FreeBSD, I promise to give an extra 15% discount over and above our normal volume discounts just to illustrate my desire to support the FreeBSD community. 3) Virtually ALL of our customers, save for OEMs making their own products, purchase complete routers. Going this route would eliminate the need to have FreeBSD support, as any user would have a standalone router. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
On Mon, Oct 15, 2001 at 08:53:14AM -0500, Doug Hass wrote: We are bound by third party agreements and are not allowed to release any more free code (legally) than we already have. If we were not restricted by SBS, Trillium, and Rockwell (among others), we would release all of the code under GPL or lGPL. These agreements do NOT prevent us from working with developers to support other platforms, though. It only prevents the free release of portions of the code. Would your agreements allow you to provide resources to a small number of developers (under NDA and all that of course) to produce drivers that you would then release in binary form (eg a kernel module) under a free license? If you cannot release the source code to your drivers, can you release hardware programming specifications (again, perhaps under NDA) that allowed someone to develop an independant free licensed driver? -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Would your agreements allow you to provide resources to a small number of developers (under NDA and all that of course) to produce drivers that you would then release in binary form (eg a kernel module) under a free license? It sure would. If you cannot release the source code to your drivers, can you release hardware programming specifications (again, perhaps under NDA) that allowed someone to develop an independant free licensed driver? Unfortunately, the API to the cards (the driver development kit, hardware programming specifications or whatever you want to call them) are licensed from several third parties and we are bound by agreement not to make them public. The 400 series cards (and, for that matter, the RISCom/N2 series cards) did not require an API, which is how BSDI and FreeBSD drivers came about in the first place. As I mentioned above, we CAN license the driver code and the DDK for development. This means that you could produce FreeBSD drivers which we could then distribute in a binary form under a free end-user license. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
In a private e-mail, Leo writes: You offered a discount on these boards on the list. If you think there is a real opportunity to sell these to the *BSD crowd, I recomend you take that 15% (or some part of it) and offer to partially fund a driver developer. There are many freelance programmers working on the project who for $1000-$5000 (depending on complexity) could make your driver a reality. A good developer could probably also make them work under OpenBSD and NetBSD in one fell swoop. I'd be happy to pledge the 15% to a driver developer. That's a great idea! It will accomplish two objectives: 1) There will be at least 100 WANic 400 series cards available for purchase to support existing installations (assuming someone out there places the order). 2) ImageStream will pledge 15% of the purchase price of any lots of these 400 series cards toward porting of our SAND architecture to FreeBSD. That's a MINIMUM of $8,100 that ImageStream is willing to pay a developer or group of developers to port the drivers for the rest of the cards. Ted--you've indicated that there is a significant market for the 400 series cards in the community. Why don't you contact me privately and we'll get you an order of the cards so that we can accomplish the above. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass Sent: Monday, October 15, 2001 9:53 AM To: Ted Mittelstaedt Cc: Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alfred Shippen Subject: RE: FYI And if you want to sell these to FreeBSD users then make your Linux driver source (not the SAND stuff) available so that we can mod it into our own driver. Many other companies do this and as a matter of fact, we (meaning FreeBSD) have even found bugs in crummy Linux drivers that have been reported back to Linux and helped those manufacturers better their products. I'm not going to get dragged into an OS war. Both Linux and FreeBSD have their share of crummy drivers and features. That discussion is honestly beyond the scope of a discussion of ImageStream's SAND architecture and the WANic 400 series. I don't believe Ted was trying to start an OS war, he's not that petty of a person. His point, and I hope that I'm not reading this incorrectly, is that FreeBSD not only has fixed problems with drivers released by hardware vendors, but also with drivers given over to us by the Linux group, as that was all that we had to work with when the hardware vendors have refused to provide any help whatsoever. [snip] No offense, but once Imagestream stopped selling WANic400's you ceased being an entity of interest to FreeBSD, as you no longer sell any products that run under it. I'll reiterate what I've said to you privately: ImageStream DID NOT make the decision to discontinue the 400 series or the RISCom/N2 series. This decision rested solely with SBS. However, FreeBSD users are NOT without options: 1) FreeBSD users can still get the WANic 400 and RISCom cards from the second hand market, as another person mentioned. What is wrong with THIS picture? You're telling people to purchase used hardware, instead of purchasing components from your company? *shakes his head* 2) WANic 400 series cards are still available in quantity. If the market for FreeBSD is as large as you claim, then you or someone else in the community should have no problem snapping up a quantity of these cards and reselling them to interested parties. I'll go one step further: If anyone contacts me about the WANic 400 series, mentions that they are for FreeBSD, I promise to give an extra 15% discount over and above our normal volume discounts just to illustrate my desire to support the FreeBSD community. Perhaps a better idea, if I may be so bold, would be to offer samples of the newer cards (520 series, I believe they are) to FreeBSD developers interested in producing drivers, software and utilities for these cards. After all, you are saying that the 400 is EOL. Wouldn't the idea of engineering samples be more beneficial to all involved? 3) Virtually ALL of our customers, save for OEMs making their own products, purchase complete routers. Going this route would eliminate the need to have FreeBSD support, as any user would have a standalone router. This sounds quite argumentative to me. Simply because everyone else is buying a router, there's a refusal to support FreeBSD, since people with true routers would have no need for using FreeBSD as a router engine. It's a vicious cycle that I believe we're seeing here... chicken and the egg, or rather, the driver and the market. Without a proper driver, there won't be a market for this card to be used with FreeBSD. However, without the manufacturer seeing visability in this market, there won't be a driver as it would be a waste of their developers time. --- Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
1) FreeBSD users can still get the WANic 400 and RISCom cards from the second hand market, as another person mentioned. What is wrong with THIS picture? You're telling people to purchase used hardware, instead of purchasing components from your company? *shakes his head* Perhaps you missed the earlier post. Someone posted about purchasing used gear or auction gear to go it on the cheap so to speak. Personally, I think wasting money on used, out-of-warranty, unsupported gear is akin to playing Russian Roulette with your money. I'd buy new every time. 2) WANic 400 series cards are still available in quantity. If the market for FreeBSD is as large as you claim, then you or someone else in the community should have no problem snapping up a quantity of these cards and reselling them to interested parties. I'll go one step further: If anyone contacts me about the WANic 400 series, mentions that they are for FreeBSD, I promise to give an extra 15% discount over and above our normal volume discounts just to illustrate my desire to support the FreeBSD community. Perhaps a better idea, if I may be so bold, would be to offer samples of the newer cards (520 series, I believe they are) to FreeBSD developers interested in producing drivers, software and utilities for these cards. After all, you are saying that the 400 is EOL. Wouldn't the idea of engineering samples be more beneficial to all involved? Those have ALWAYS been available. My phone rings all day. I pick it up, and it's never a BSD developer wanting to order cards and port drivers. :-) All you have to do is ask. Driver source, demo cards, and development tools have been available to the BSD community since 1995. To date, only BSDI took up the effort, and only briefly. Where are all the FreeBSD developers and why aren't they beating down my door for these samples and code? I'll get back to this in a minute. 3) Virtually ALL of our customers, save for OEMs making their own products, purchase complete routers. Going this route would eliminate the need to have FreeBSD support, as any user would have a standalone router. This sounds quite argumentative to me. Simply because everyone else is buying a router, there's a refusal to support FreeBSD, since people with true routers would have no need for using FreeBSD as a router engine. Nope--it's just a matter of laying out the options. There are 4--buy used, buy new in quantity, and buy routers. You can also develop drivers for the new cards (they aren't new--they've been out for 3 years). It's a vicious cycle that I believe we're seeing here... chicken and the egg, or rather, the driver and the market. Without a proper driver, there won't be a market for this card to be used with FreeBSD. However, without the manufacturer seeing visability in this market, there won't be a driver as it would be a waste of their developers time. It's not a vicious cycle at all. Ted has said repeatedly in earlier e-mails that there is a large market for the 400/405 and that discontinuing them was foolish. I've actually proposed a solution that solves both problems. I'll recap for those who missed my earlier message: 1) If the *BSD community has the 400 series cards in such high demand, someone should step up and order them in quantity. This solves the issue with the cards not being available in one and two unit quantities. You'll have a ready supply from someone in the community, and you'll be supporting the community when you buy the cards from them. 2) If someone from the FreeBSD community orders the cards, ImageStream will put up a minimum of $8,100 for a developer or developer group to port drivers for the rest of the cards. Actually, it's 15% of the purchase price of any 400 series cards. The more in demand the current cards are, the more money we'll pledge to make sure that FreeBSd drivers exist for ALL of the cards. My phone number is below. If these cards and the future of the drivers are as important as everyone who has posted says they are, let's move quickly toward a solution. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
-Original Message- From: Andrew C. Hornback [mailto:[EMAIL PROTECTED]] Sent: Monday, October 15, 2001 2:59 PM To: Doug Hass; Ted Mittelstaedt Cc: Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alfred Shippen Subject: RE: FYI -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass Sent: Monday, October 15, 2001 9:53 AM To: Ted Mittelstaedt Cc: Jim Bryant; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alfred Shippen Subject: RE: FYI And if you want to sell these to FreeBSD users then make your Linux driver source (not the SAND stuff) available so that we can mod it into our own driver. Many other companies do this and as a matter of fact, we (meaning FreeBSD) have even found bugs in crummy Linux drivers that have been reported back to Linux and helped those manufacturers better their products. I'm not going to get dragged into an OS war. Both Linux and FreeBSD have their share of crummy drivers and features. That discussion is honestly beyond the scope of a discussion of ImageStream's SAND architecture and the WANic 400 series. I don't believe Ted was trying to start an OS war, he's not that petty of a person. been there, done that. :-) No, it's not an OS war, just trying to illustrate why making source available is a Good Thing. His point, and I hope that I'm not reading this incorrectly, is that FreeBSD not only has fixed problems with drivers released by hardware vendors, but also with drivers given over to us by the Linux group, as that was all that we had to work with when the hardware vendors have refused to provide any help whatsoever. correct. [snip] No offense, but once Imagestream stopped selling WANic400's you ceased being an entity of interest to FreeBSD, as you no longer sell any products that run under it. I'll reiterate what I've said to you privately: ImageStream DID NOT make the decision to discontinue the 400 series or the RISCom/N2 series. This decision rested solely with SBS. However, FreeBSD users are NOT without options: 1) FreeBSD users can still get the WANic 400 and RISCom cards from the second hand market, as another person mentioned. What is wrong with THIS picture? You're telling people to purchase used hardware, instead of purchasing components from your company? *shakes his head* I'll point out that the 1000 cards closed out is not used hardware, it's brand new stuff that's never been opened. This is quite common in the hardware industry. The difficulty is finding out who that highest bidder was and if they are going to use those 1000 cards for themselves or are going to sell them off in dribs and drabs over the next 10 years. 2) WANic 400 series cards are still available in quantity. If the market for FreeBSD is as large as you claim, then you or someone else in the community should have no problem snapping up a quantity of these cards and reselling them to interested parties. I'll go one step further: If anyone contacts me about the WANic 400 series, mentions that they are for FreeBSD, I promise to give an extra 15% discount over and above our normal volume discounts just to illustrate my desire to support the FreeBSD community. Perhaps a better idea, if I may be so bold, would be to offer samples of the newer cards (520 series, I believe they are) to FreeBSD developers interested in producing drivers, software and utilities for these cards. After all, you are saying that the 400 is EOL. Wouldn't the idea of engineering samples be more beneficial to all involved? Just about every hardware vendor is happy to provide samples to developers, anyone working on this would get plenty of support. 3) Virtually ALL of our customers, save for OEMs making their own products, purchase complete routers. Going this route would eliminate the need to have FreeBSD support, as any user would have a standalone router. This sounds quite argumentative to me. Simply because everyone else is buying a router, there's a refusal to support FreeBSD, since people with true routers would have no need for using FreeBSD as a router engine. No company is going to support a product that has no market, and it's reasonable to ask who would buy these cards since Cisco's are so cheap on the seconds market. It's a vicious cycle that I believe we're seeing here... chicken and the egg, or rather, the driver and the market. Without a proper driver, there won't be a market for this card to be used with FreeBSD. However, without the manufacturer seeing visability in this market, there won't be a driver as it would be a waste of their developers time. This is the truth for commercial projects. Open Source drivers, on the other hand, operate somewhat differently. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide
RE: FYI
There are other vendors that sell the WanIC than Imagestream. I realize that you see yourself as the only supplier but this isn't true. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass Sent: Friday, October 12, 2001 3:11 PM To: [EMAIL PROTECTED]; Ted Mittelstaedt; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Alfred Shippen Subject: Re: FYI I'm providing this to the people whose addresses appear in the original messages. My apologies if this gets cross-posted or sent multiple times to the same place. As I mention below, the WANic 400 series cards and all of the RISCom/N2 series cards are now End Of Life, and only available in special quantity builds. If anyone reading this message needs further information, please contact me directly and I can go into further depth about the EOL cards mentioned below and their replacements in the SBS line. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 On Fri, 12 Oct 2001, Doug Hass wrote: The WANic 400 series is definitely EOL. The cards are available in quantities of 100+ only by special order. The RISCom/N2 series cards are also EOL. This is a recent decision--it went into effect as of September 21st. Closeout quantities have already been sold to other companies, so the cards are only available by special order. The WANic 521/522 have replaced these cards, and should be used instead. There are no drivers for FreeBSD, however. Doug On Sat, 13 Oct 2001, Alfred Shippen wrote: This guy is local to you and is under the misapprehension that the Risc/400 series is not a discontinued item. I dont know if you want to follow them up or not. My customer (Bytecraft) is fine by this and has passed on the comments to me. Cheers - Original Message - From: Ted Mittelstaedt [EMAIL PROTECTED] To: MurrayTaylor [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 12, 2001 3:07 PM Subject: RE: Imagestream WanIC-520 interface cards The WANic 5xx's use an incompatible chipset and the driver will not work with them. I thnk your supplier is feeding you a line of bullshit. SBS Communications has posted no plans whatsover to discontinue or change the WANic line. They are fully aware that the 405's have open source drivers and are furthermore used in embedded systems too. The WANic 5xx series of cards sell for more money and so naturally your supplier is most interested in maximizing his margin and would prefer to push you into a more expensive card. With the increase in CPU power all of the go-fast hardware on the higher-level cards is less important. Consider that the Hitachi controller chip used on the WANic 405 is the SAME chip that Cisco uses in it's 25xx series of routers, and the Cisco 2501 is the most used router in the world and has the most installed units. SBS Communications is STILL selling the RISCom series of cards which is the predecessor to the WANic, uses the same controller, these are ISA cards that have a design that's over 10 years old. You tell your supplier that since the 405 is being phased out that he should sell you a bunch of them at closeout prices. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of MurrayTaylor Sent: Thursday, October 11, 2001 4:49 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Imagestream WanIC-520 interface cards As the WanIC-405 is being phased out (according to my supplier down under here in OZ), has any development / testing been done on the apparent replacement, the WanIC-521 (522, 524 ... ) range I am especially interested in its compatibility with its predecessor which I am using very successfully for frame relay under Netgraph. I'm trying to get compatability info from the supplier here, but we are a long way down the food chain ;-( Tia Murray Taylor Bytecraft Systems Pty Ltd [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED
RE: FYI
Ted, We're SBS' worldwide distributor. Others who resell them buy them from us or from one of our distributors. In any case, I can ASSURE you without a doubt that the WANic 400 series and the entire RISCom/N2 series are end of life as of the end of September. If you have questions, feel free to contact me at your convenience. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 On Sun, 14 Oct 2001, Ted Mittelstaedt wrote: There are other vendors that sell the WanIC than Imagestream. I realize that you see yourself as the only supplier but this isn't true. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Doug Hass Sent: Friday, October 12, 2001 3:11 PM To: [EMAIL PROTECTED]; Ted Mittelstaedt; MurrayTaylor; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Alfred Shippen Subject: Re: FYI I'm providing this to the people whose addresses appear in the original messages. My apologies if this gets cross-posted or sent multiple times to the same place. As I mention below, the WANic 400 series cards and all of the RISCom/N2 series cards are now End Of Life, and only available in special quantity builds. If anyone reading this message needs further information, please contact me directly and I can go into further depth about the EOL cards mentioned below and their replacements in the SBS line. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 On Fri, 12 Oct 2001, Doug Hass wrote: The WANic 400 series is definitely EOL. The cards are available in quantities of 100+ only by special order. The RISCom/N2 series cards are also EOL. This is a recent decision--it went into effect as of September 21st. Closeout quantities have already been sold to other companies, so the cards are only available by special order. The WANic 521/522 have replaced these cards, and should be used instead. There are no drivers for FreeBSD, however. Doug On Sat, 13 Oct 2001, Alfred Shippen wrote: This guy is local to you and is under the misapprehension that the Risc/400 series is not a discontinued item. I dont know if you want to follow them up or not. My customer (Bytecraft) is fine by this and has passed on the comments to me. Cheers - Original Message - From: Ted Mittelstaedt [EMAIL PROTECTED] To: MurrayTaylor [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 12, 2001 3:07 PM Subject: RE: Imagestream WanIC-520 interface cards The WANic 5xx's use an incompatible chipset and the driver will not work with them. I thnk your supplier is feeding you a line of bullshit. SBS Communications has posted no plans whatsover to discontinue or change the WANic line. They are fully aware that the 405's have open source drivers and are furthermore used in embedded systems too. The WANic 5xx series of cards sell for more money and so naturally your supplier is most interested in maximizing his margin and would prefer to push you into a more expensive card. With the increase in CPU power all of the go-fast hardware on the higher-level cards is less important. Consider that the Hitachi controller chip used on the WANic 405 is the SAME chip that Cisco uses in it's 25xx series of routers, and the Cisco 2501 is the most used router in the world and has the most installed units. SBS Communications is STILL selling the RISCom series of cards which is the predecessor to the WANic, uses the same controller, these are ISA cards that have a design that's over 10 years old. You tell your supplier that since the 405 is being phased out that he should sell you a bunch of them at closeout prices. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of MurrayTaylor Sent: Thursday, October 11, 2001 4:49 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Imagestream WanIC-520 interface cards As the WanIC-405 is being phased out (according to my supplier down under here in OZ), has any development / testing been done on the apparent replacement, the WanIC-521 (522, 524 ... ) range
Re: FYI
No offense to you or your sales partners, but the way I see it, this means that tons of these will be available for a song on eBay soon, and will be in the hands of a lot of FreeBSD and Linux people [not all of which can afford top-of-the-line all of the time]. Doug Hass wrote: Ted, We're SBS' worldwide distributor. Others who resell them buy them from us or from one of our distributors. In any case, I can ASSURE you without a doubt that the WANic 400 series and the entire RISCom/N2 series are end of life as of the end of September. If you have questions, feel free to contact me at your convenience. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
No offense taken--if I was in a position to need the 400 series cards, I'd be snapping up all the used and auction lots I could. Nortel just auctioned off about 1000 of them, so I'd expect that there will be a glut on the used market. If money is the only concern, those cards should be available on the secondary market for next-to-nothing for a long time. If performance, features and form factor are more important, there are better chipsets available on current cards. Both approaches have their merits. Doug On Sun, 14 Oct 2001, Jim Bryant wrote: No offense to you or your sales partners, but the way I see it, this means that tons of these will be available for a song on eBay soon, and will be in the hands of a lot of FreeBSD and Linux people [not all of which can afford top-of-the-line all of the time]. Doug Hass wrote: Ted, We're SBS' worldwide distributor. Others who resell them buy them from us or from one of our distributors. In any case, I can ASSURE you without a doubt that the WANic 400 series and the entire RISCom/N2 series are end of life as of the end of September. If you have questions, feel free to contact me at your convenience. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
Also--understand that the replacement for the 400 and 405 is a multi-interface card (supports all of the wiring specs instead of just 1), and costs virtually the same (or less as a reseller or in volume) than the 400/405 did. Doug On Sun, 14 Oct 2001, Jim Bryant wrote: No offense to you or your sales partners, but the way I see it, this means that tons of these will be available for a song on eBay soon, and will be in the hands of a lot of FreeBSD and Linux people [not all of which can afford top-of-the-line all of the time]. Doug Hass wrote: Ted, We're SBS' worldwide distributor. Others who resell them buy them from us or from one of our distributors. In any case, I can ASSURE you without a doubt that the WANic 400 series and the entire RISCom/N2 series are end of life as of the end of September. If you have questions, feel free to contact me at your convenience. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI
I'm providing this to the people whose addresses appear in the original messages. My apologies if this gets cross-posted or sent multiple times to the same place. As I mention below, the WANic 400 series cards and all of the RISCom/N2 series cards are now End Of Life, and only available in special quantity builds. If anyone reading this message needs further information, please contact me directly and I can go into further depth about the EOL cards mentioned below and their replacements in the SBS line. Regards, Doug - Doug Hass ImageStream Internet Solutions [EMAIL PROTECTED] http://www.imagestream.com Office: 1-219-935-8484 Fax: 1-219-935-8488 On Fri, 12 Oct 2001, Doug Hass wrote: The WANic 400 series is definitely EOL. The cards are available in quantities of 100+ only by special order. The RISCom/N2 series cards are also EOL. This is a recent decision--it went into effect as of September 21st. Closeout quantities have already been sold to other companies, so the cards are only available by special order. The WANic 521/522 have replaced these cards, and should be used instead. There are no drivers for FreeBSD, however. Doug On Sat, 13 Oct 2001, Alfred Shippen wrote: This guy is local to you and is under the misapprehension that the Risc/400 series is not a discontinued item. I dont know if you want to follow them up or not. My customer (Bytecraft) is fine by this and has passed on the comments to me. Cheers - Original Message - From: Ted Mittelstaedt [EMAIL PROTECTED] To: MurrayTaylor [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 12, 2001 3:07 PM Subject: RE: Imagestream WanIC-520 interface cards The WANic 5xx's use an incompatible chipset and the driver will not work with them. I thnk your supplier is feeding you a line of bullshit. SBS Communications has posted no plans whatsover to discontinue or change the WANic line. They are fully aware that the 405's have open source drivers and are furthermore used in embedded systems too. The WANic 5xx series of cards sell for more money and so naturally your supplier is most interested in maximizing his margin and would prefer to push you into a more expensive card. With the increase in CPU power all of the go-fast hardware on the higher-level cards is less important. Consider that the Hitachi controller chip used on the WANic 405 is the SAME chip that Cisco uses in it's 25xx series of routers, and the Cisco 2501 is the most used router in the world and has the most installed units. SBS Communications is STILL selling the RISCom series of cards which is the predecessor to the WANic, uses the same controller, these are ISA cards that have a design that's over 10 years old. You tell your supplier that since the 405 is being phased out that he should sell you a bunch of them at closeout prices. Ted Mittelstaedt [EMAIL PROTECTED] Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of MurrayTaylor Sent: Thursday, October 11, 2001 4:49 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Imagestream WanIC-520 interface cards As the WanIC-405 is being phased out (according to my supplier down under here in OZ), has any development / testing been done on the apparent replacement, the WanIC-521 (522, 524 ... ) range I am especially interested in its compatibility with its predecessor which I am using very successfully for frame relay under Netgraph. I'm trying to get compatability info from the supplier here, but we are a long way down the food chain ;-( Tia Murray Taylor Bytecraft Systems Pty Ltd [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FYI: RSA Donated to the public domain
"Jeroen C. van Gelderen" wrote: Warner Losh wrote: In message [EMAIL PROTECTED] Warner Losh writes: : RSA Security Releases RSA Encryption Algorithm into Public Domain Note that other information at the site says that RSAREF isn't released into the public domain. Its use is still governed by copyright law, so we'll have to use the international version of RSAREF if we want to get RSA into -current. RSAREF was only neccessary whilst the patent was enforced. Now that RSA is released[1] we can use the OpenSSL RSA implementation which is better. [1] The press release talk about RSADSI "waiving its rights to enforce the RSA patent for any development activities" This is very cunning as the patent never actually covered development. Instead it covers usage and sales of products incorporating RSA, both of which are not explicitly allowed for in the press release. Better be careful, better get written approval! No, it explicity said they were placing the RSA algorithm "in the public domain." That has some very specific legal meanings, which boil down to "you can do whatever you want with it, but you can't sue us over it because it's not ours anymore, it's everyones." -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI: RSA Donated to the public domain
On Thu, 7 Sep 2000, Peter Wemm wrote: Mike Silbersack wrote: Ok, now I have a question. Using STARTTLS with sendmail is obviously OK for us, since sendmail got the export liscense. However, AFAIK, qmail and postfix have obtained no such permission. Postfix has done the BXA hoop thing too. It is fully exportable (and reexportable) and has a TLS etc implementation. Cheers, -Peter Excellent, glad that 2/3 MTAs are done. Now, on to qmail. I'm assuming that Bernstein won't go through the hassle of getting approval, especially since I don't know where the snuffle trial is currently at in appeals. However, the TLS patch for qmail at http://www.esat.kuleuven.ac.be/~vermeule/qmail/tls.patch patches cleanly, and works great. Like OpenSSH / etc, it uses OpenSSL for all crypto work. Which of the following options would be legal: 1. Have the port fetch the patch from the .be site, patch qmail, and finish building it. 2. Include a (possibly modified) version of the patch in the ports tree, which would be applied when building qmail. (The port makefile would also wish to call the patched qmail makefile to create a CA during the build process as well. I'm not sure if that has additional implications.) I'm assuming #1's good, since that's how the OpenSSH port worked. Would #2 be any different? Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI: RSA Donated to the public domain
Mike Silbersack wrote: On Wed, 6 Sep 2000, Warner Losh wrote: http://www.rsasecurity.com/news/pr/000906-1.html RSA Security Releases RSA Encryption Algorithm into Public Domain Ok, now I have a question. Using STARTTLS with sendmail is obviously OK for us, since sendmail got the export liscense. However, AFAIK, qmail and postfix have obtained no such permission. Postfix has done the BXA hoop thing too. It is fully exportable (and reexportable) and has a TLS etc implementation. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI: RSA Donated to the public domain
In message [EMAIL PROTECTED] Warner Losh writes: : RSA Security Releases RSA Encryption Algorithm into Public Domain Note that other information at the site says that RSAREF isn't released into the public domain. Its use is still governed by copyright law, so we'll have to use the international version of RSAREF if we want to get RSA into -current. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI: RSA Donated to the public domain
On Wed, 6 Sep 2000, Jeroen C. van Gelderen wrote: [1] The press release talk about RSADSI "waiving its rights to enforce the RSA patent for any development activities" This is very cunning as the patent never actually covered development. Instead it covers usage and sales of products incorporating RSA, both of which are not explicitly allowed for in the press release. Better be careful, better get written approval! All of the pages they've put up on their website seems to disagree with what you've just said. I think you're confusing use of RSA and use of RSAREF/BSAFE, which they're still maintaining control over (as Warner said.) Somehow I rather doubt they're trying to trick people into using RSA for the next week, and then going on a mass lawsuit spree. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI: RSA Donated to the public domain
On Wed, 6 Sep 2000, Mike Silbersack wrote: Somehow I rather doubt they're trying to trick people into using RSA for the next week, and then going on a mass lawsuit spree. Ugh, please forgive my poor English. It's before noon. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI: RSA Donated to the public domain
On Wed, 6 Sep 2000, Warner Losh wrote: http://www.rsasecurity.com/news/pr/000906-1.html RSA Security Releases RSA Encryption Algorithm into Public Domain Ok, now I have a question. Using STARTTLS with sendmail is obviously OK for us, since sendmail got the export liscense. However, AFAIK, qmail and postfix have obtained no such permission. So, can we put in the STARTTLS patches for those two MTAs into the ports tree? Since the actual encryption duties are handled by OpenSSL in both cases, I suspect it's in the same boat as OpenSSH, US export-wise. However, I've never been clear on what boat OpenSSH is actually in. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI: RSA Donated to the public domain
Mike Silbersack wrote: On Wed, 6 Sep 2000, Jeroen C. van Gelderen wrote: [1] The press release talk about RSADSI "waiving its rights to enforce the RSA patent for any development activities" This is very cunning as the patent never actually covered development. Instead it covers usage and sales of products incorporating RSA, both of which are not explicitly allowed for in the press release. Better be careful, better get written approval! All of the pages they've put up on their website seems to disagree with what you've just said. I just pointed out that the press release (from which I quoted) doesn't state that use/selling of RSA is allowed now. It seems that the FAQ allows for use and sale. Which document prevails is up in lawyer land... I think you're confusing use of RSA and use of RSAREF/BSAFE, Nope, the press release explicitly (see quote above) talks about the patent (which covers the algorithm, not RSAREF) and I was pointing out just that. which they're still maintaining control over (as Warner said.) Which is not an issue as we don't need RSAREF, not even an international version of RSAREF :-) Somehow I rather doubt they're trying to trick people into using RSA for the next week, and then going on a mass lawsuit spree. You may very well be right but in case you are not, it would be rather nasty if we got harassed, right? RSADSI has not been nice about their IP in the past couple of years and I have no reason to believe they will be now. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI: RSA Donated to the public domain
From the rsa website (the quiz, hey- who can resist a free T-Shirt) there is the following tidbit... With the patent expiration, software developers are now free to develop their own implementation of the RSA algorithm from scratch. However, RSA BSAFE and RSAREF code is still proprietary and subject to licensing. But since there are already other (better?) coded implementations of RSA's algorithms, if those are used we all should be golden. Correct? -=Jim=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI: RSA Donated to the public domain
On Wed, 6 Sep 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Warner Losh writes: : RSA Security Releases RSA Encryption Algorithm into Public Domain Note that other information at the site says that RSAREF isn't released into the public domain. Its use is still governed by copyright law, so we'll have to use the international version of RSAREF if we want to get RSA into -current. There's no reason why we would want to continue to use RSAREF, except perhaps for source code compatability with something that was written to link against it. The OpenSSL implementation is much better, and basically we just have to build it by default now. I'm not sure whether it's okay to build a shim for OpenSSL which translates the RSAREF API into the native one (the reverse of the OpenSSL - RSAREF code which currently exists), but it would be mildly useful for those legacy apps. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FYI: RSA Donated to the public domain
Somehow I rather doubt they're trying to trick people into using RSA for the next week, and then going on a mass lawsuit spree. No idea about RSA motives, but "Submarice patents" are a well known strategem. AFAIR owners of compress.c registered it, then published it, only years later tried to extract money for it ( Jean Luc Gailly wrote the more efficient gzip, under GPL, we all abandoned compress :-) Julian - Julian Stacey http://bim.bsn.com/~jhs/ Munich Unix Consultant. Free BSD Unix with 3600 packages sources. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
