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
Eygene Ryabinkin writes: > "Dag-Erling Smørgrav" writes: > > Eygene Ryabinkin 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
Tue, Jun 02, 2009 at 01:28:34PM +0200, Dag-Erling Sm??rgrav wrote:
> Eygene Ryabinkin 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 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
Eygene Ryabinkin 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
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
Fri, May 29, 2009 at 06:53:22PM +0200, Dag-Erling Sm??rgrav wrote:
> Bruce Evans 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
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
Bruce Evans writes:
> Dag-Erling Smørgrav 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
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 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
On Tuesday 26 May 2009 23:20:01 Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav 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
Eygene Ryabinkin 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
Oliver Pinter 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
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 wrote: > Eygene Ryabinkin 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
Wed, May 27, 2009 at 06:44:35PM +0200, Dag-Erling Sm??rgrav wrote:
> Eygene Ryabinkin 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
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
---
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 2>&1
+ ret=$?
+ if [ "$ret" -eq "$6" ] ; then
+ ech
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Bruce Evans 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
Eygene Ryabinkin 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
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
Eygene Ryabinkin 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
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
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
---
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
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
---
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 ni_startdir.
*/
-#define RDONLY 0x200 /* l
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Eygene Ryabinkin writes: > "Dag-Erling Smørgrav" writes: > > (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. 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. > 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. 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 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
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
---
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 /* has allocated path
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Eygene Ryabinkin 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
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 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
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
---
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 points */
-#define NO
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Dag-Erling Smørgrav 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 Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Dag-Erling Smørgrav 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
[moving from security@ to hack...@]
Jakub Lach 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: 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]"
FYI: 3Ware 9650 can cause data corruption
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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FYI: Petition against Verisign net abuse at petitiononline.com
To: ICANN We internet users, who either own domain names or have an interest in the domain name system, wish to object to the Verisign Sitefinder system. ... http://www.petitiononline.com/icanndns/ -Andrew- -- ___ | -Andrew J. Caines- Unix Systems Engineer [EMAIL PROTECTED] | | "They that can give up essential liberty to obtain a little temporary | | safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 | ___ [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
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]"
FYI: NetBSD mmap Improvements
taken from wine HQ: http://www.winehq.com/?issue=186#NetBSD mmap Improvements "On NetBSD (upcoming 1.6.2, and 1.7/2.0-current), there is a new extension flag MAP_TRYFIXED that essentially simulates current Linux mmap behavior: try the mmap() hint first, without clobbering mapped pages, even if the hint falls within traditionally "protected" malloc heap space. If the fixed mapping fails, the block is still mapped at a relocated address, as if mmap were called with no flags set. With this patch, mmapping PE files on NetBSD becomes an order of magnitude faster, as the vfork()-and-mincore() silly walk is avoided altogether. I've implemented the patch as forward-looking, allowing other platforms to add MAP_TRYFIXED to gain the same benefit. (This mmap flag name does not appear to be used in any divergent fashion on any other platform, per my research when picking the flag's name.) " __ 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 - 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 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 - 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
FYI - Just got a kernel panic - RELENG_4
supped as of ~ 1:40pm EST today The panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x5b4984c8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02714a9 stack pointer = 0x10:0xd5d3ecf4 frame pointer = 0x10:0xd5d3ecf8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 34411 (tar) interrupt mask = net tty bio cam trap number = 12 panic: page fault Current kldstat (shouldn't be different from the one during the panic) $ kldstat Id Refs AddressSize Name 16 0xc010 2c6d78 kernel 21 0xc1286000 a000 ntfs.ko 31 0xc12ca000 7000 linprocfs.ko 41 0xc1341000 2000 green_saver.ko 52 0xc1344000 15000linux.ko 61 0xc138a000 2000 rtc.ko kernel IP info: $ nm -n /kernel ... c0271394 T vm_page_unhold c02713b0 T vm_page_insert c0271430 T vm_page_remove c02714f8 T vm_page_lookup c0271554 T vm_page_rename c02715ac T vm_page_unqueue_nowakeup c02715f4 T vm_page_unqueue c027166c T _vm_page_list_find ... cvs tag of file containing "offending" function: * $FreeBSD: src/sys/vm/vm_page.c,v 1.147.2.19 2003/08/09 16:21:21 luoqi Exp $ Attached is the dmesg of the session that led to the panic, as well as my kernel configuration file (LAPTOP). I don't see anything very peculiar about it... How else can I help? Thanks, Marc. -- Marc Ramirez Blue Circle Software Corporation 513-688-1070 (main) 513-382-1270 (direct) http://www.bluecirclesoft.com http://www.mrami.com (personal)# # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.53 2003/03/25 23:33:44 jhb Exp $ machine i386 cpu I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU ident LAPTOP maxusers0 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. options USER_LDT # To make an SMP kernel, the next two are neede
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
FYI: FreeBSD and Intel/ICP Vortex Raid-Controllers
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
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
SBS WANic (was FYI)
I don't doubt that. As I mentioned, there are several factors that I need to check into, especially our agreements with SBS. tim On Fri, 19 Oct 2001, Doug Hass wrote: > 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
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
> 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
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
- 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
> 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
> 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
Doug Hass wrote: > 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... Let's take GPL'ed code as an example (it's just an example; it is not the only license that makes it hard to distribute full systems using the code). Code in the boot path can't be GPL'ed. This is because of the GPL's "poison pill" restrictions against BSD licensed code: 1) All code linked against GPL'ed code becomes GPL'ed Most of the code, we couldn't change the license if we wanted to, so this is a non-starter. 2) No additional restrictions There is still a lot of code (this is not a bad thing) that contains the 4 clause license, which means it includes the "claim credit" clause, which means that if you mention features or use of the code, you have to include the copyright in advertising materials so that you aren't claiming you wrote the feature (e.g., if you included PSC's SYN? cache, and said you had a SYN cache, then you'd have to admit that you didn't write it, PSC did). This is sometimes incorrectly called the "advertising clause" -- it isn't, though, since you don't have to mention features or use of the software in your advertising. Outside the boot path, the code can be loaded as a loadable module, so there's a lot more leeway as far as licensing. But if you wanted to replace the driver for the disk controller you are using, or the file system you are using or something else critical to the boot path (e.g. an ethernet driver, if you are net-booting), then there is the problem that it is no longer legal to distribute the code, under the GPL. Netscape, similarly, restricts the distribution of binaries for Netscape, except by themselves or licensees -- which is why we have both ports and packages, instead of just packages, and why some ports download intact binaries from their distributors. > 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. The driver for these cards could be GPL'ed, and not impact FreeBSD. These drivers will not find themselves in the boot path. It also means that they could be binary-only... so long as they were kept up to date with kernel changes. The problems with a binary-only driver are somewhat more and less annoying at the same time: a binary driver that does not place license restrictions on redistribution or on the code it links with is no problem for the project. But there is not currently a lot of infrastructure for adding such drivers easily, and they can quickly become "stale", with evolution of the kernel code -- and the fact that the source isn't public means that it's impossible to intentionally avoid changing a kernel interface out from under it, to ensure the binary compatability is maintained between versions of the kernel. Doing this would also mean that the driver code could not be shared with other, similar devices. Perhaps this is the intent; if so, one should be certain that the trade-offs are worth it. It would probably be worthwhile to consider abstracting, as completely as possible, the code that can't be distributed as source code, and to make the code that depends on kernel interfaces public, so that the glue code could be changed by the FreeBSD community, as the FreeBSD kernel changes, without needing to chnage the core code, distributed as a shared object file. -- Terry 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
>-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
>-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
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 -- - bill fumerola / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] - my anger management counselor can beat up your self-affirmation therapist 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 10:20 AM >To: Mike Smith >Cc: Ted Mittelstaedt; Leo Bicknell; Jim Bryant; MurrayTaylor; >[EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: FYI > >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.) > That is not my point of view and if you read my mail you will see that and I will thank you very much not to go around saying that. To repeat: I said that "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." and "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" This is very far from saying that FreeBSD only accepts BSD licensed code, period. 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. > >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. FreeBSD is not a commercial product and there is no pressure for it to steal all the market share away from all the other UNIX and UNIX-like vendors. It's been proven by Microsoft rather well I think that the majority of computer users in the market will fight their way to junk and push the good stuff aside in their stampede. Even you must admit that if Imagestream had 80% of the router market that it would in no way, shape or form resemble what it is today. You would turn into Cisco. It's unavoidable, and just how life works. (this is not to infer that Cisco is junk, BTW, just that they are a big and often unresponsive company) >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. > The Cyclades Cyclom-Y boards are supported by the "cy" driver in FreeBSD. This was not written by Cyclades. OK - so it's not a RAS card, but where was Cyclades? >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... > It's a shame that so much misinformation is spread over the BSD license. Just ask yourself - why is it that the BSD license is such an object of controversy? People talk about the GPL being controversial? Sheesh! All the license says is to give away code for free. What a revolutionary idea! Most ironic is that it seems like 1/4 of the GPL advocates out there who are making noise about it want us all lined up against the wall and shot for saying that!!! 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: 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
>-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: 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
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
FYI: Cyclades PC300, PC400
some snipping done: >Date: Tue, 16 Oct 2001 17:21:55 -0700 (PDT) >From: Cyclades Technical Support <[EMAIL PROTECTED]> >To: Len Conrad <[EMAIL PROTECTED]> >Subject: Re: PC400 >X-Virus-Scanned: by VirusGate.MEIway.com >X-RCPT-TO: <[EMAIL PROTECTED]> > >Hi Len, > My answers are below. >Regards, > >Al Roth > >On Mon, 15 Oct 2001, Len Conrad wrote: > > > Hi Al, > > > > ok, so the PC400 can support "clear-channel", ie, non-channelized > > operation, it seems? > > > > >These are primarily limitations in FreeBSD. > > >There are many more options available in Linux, including Frame > > >Relay support. > > > > oh, I see. It's your FreeBSD driver that isn't as sophisticated as your > > Linux driver? > >Actually, the problem is in the FreeBSD support, not the driver > > > > > You FreeBSD support for the PC400 includes FreeBSD 4.4? > > > >There currently is not a FreeBSD driver for PC400. > > > In the case where I use two or more PC400's to accept, say, 4 T1's, is > > there any outbound loadbalancing where the 4 T1's are going to the same > > upstream, who in turn is doing downstream-load balancing? This load > > balanced, multi-T1 setup seems to be the common way to go above 1.5 > > mbits/sec without going to a full or fractionalized DS3. > > > >Load balancing is an OS issue, not a driver issue. In the case of Linux >2.4.4 and greater, we are able to support MultiLink PPP, so multiple T1 >lines can be combined to increase bandwidth. -- So they've got some FreeBSD support, but say its weaker driver is due to FreeBSD. h Len 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
> 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
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
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
* 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. 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. 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 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
> 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. The point I was trying to make here is that there *is* no such attitude. > Three of the > largest manufacturers in these segments (SBS, Cyclades, and Ariel) all > support Linux and NT, but do not have BSD support. ... yet Linux has a far more entrenched and outspoken "GPLed code or bust" attitude than this mythical "BSD-licensed code or bust" attitude that you allude to. > 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... We do try; before I left BSDi this was one of my goals. We certainly don't try to exclude them, just the opposite; we've provided support for companies developing in-house drivers. We have a module architecture that makes writing, maintaining and deploying binary-only drivers a snap. > 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. 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
> > 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
> 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
> 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
- 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 wit
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 Joh
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
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: T1 boards (was FYI)
Howdy, SBEI have recently put up a new FreeBSD 4.x driver up at ftp://ftp.sbei.com/pub/OpenSource/FreeBSD/FreeBSD_4.3.tar.gz for their wanADAPT range of cards, so they're no longer out of date. Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: T1 boards (was FYI)
On Wed, Oct 17, 2001 at 11:00:30AM +1100, Chris Knight wrote: > The SBE Inc wanADAPT-1T1E1 is USD$750. The driver works fine on FreeBSD 4.x. > I have provided them with feedback on their documentation and a patch for > BPF support and they are keen on getting the driver incorporated into the > FreeBSD source tree. That would be a fine thing, I think. It sounds like Netgraph support is a must for a large number of people though. I wonder if someone is interested in adding that. Do you have a price for a v.35 card? Some of us still have piles of external CSU's around. :-) -- 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: T1 boards (was FYI)
Howdy, The SBE Inc wanADAPT-1T1E1 is USD$750. The driver works fine on FreeBSD 4.x. I have provided them with feedback on their documentation and a patch for BPF support and they are keen on getting the driver incorporated into the FreeBSD source tree. Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Leo Bicknell > Sent: Wednesday, 17 October 2001 10:47 > To: Len Conrad > Cc: [EMAIL PROTECTED] > Subject: 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 > 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
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
>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, 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
> 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
>-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
> 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
> 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 unmistakab
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
>-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 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
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
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: [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
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
> 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
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
> 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
>-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
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
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
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
