Subject: Re: Linux ip codeReply-to: (fwd)
To: None <current-users@NetBSD.ORG>
From: Darren Reed <>
List: current-users
Date: 05/06/1995 03:52:14
Personally, I don't much like the tone of this guy's reply and think that
this is probably typical of why the bug existed in the first place.

But, he makes some interesting allegations...does anyone want to do
anything about them ?  (I would, but for time)


In some mail from Alan Cox, they said:
> From Sat May  6 03:06:23 EST 1995
> Message-Id: <>
> From: (Alan Cox)
> Subject: Re: Linux ip codeReply-to:
> To: (Juha Luoma)
> Date: Fri, 5 May 95 16:59:13 GMT
> Cc:
> In-Reply-To: <>; from "Juha Luoma" at May 5, 95 07:05:15 am
> X-Mailer: ELM [version 2.4dev PL17]
> > Oh, btw, if you're using Linux because of the IPFIREWALL stuff it has
> > built in, think again.  It is *NOT* being done correctly here.  Maybe
> > someone should sit down and take a good close look at Linux for us...
> Works beautifully from 1.2.1 upwards. Prior to that we used the BSD firewall
> code without Ugen's final improvements and Jos Vos debugging. Its now a lot
> better than the FreeBSD2.0 one and a bit better than FreeBSD current.
> > Now, since people (who typically run Linux) have been so stubborn about
> > there not being a bug, I'll cut and paste the segment so you can see for
> > yourselves.  The bug is, as far as I'm concerned, plain to see.  Maybe
> > Linux does something that I'm missing...but I doubt it.
> He is missing the fact the extra space will be readable for all cases and
> that at this point reading it will do no harm. If it worries you just
> 	||skb->len<ntohs(iph->tot_len)
> to that if he lists. I'll put it into 1.2.9/1.3.0 to keep people happy.
> > Maybe Linux should get a clue and just import as much as they can of the
> > TCP/IP code from 4.4-Lite.
> We don't want to import
> o	Broken connect()/bind() on RAW sockets
> o	Abominable unconnected UDP performance
> o	Prehistoric chained buffer packet management systems
> o	Broken UDP error handling.
> o	Easily Spoofable sequence numbering
> o	Slow performance (Linux pre-1.3 is already doing >70Mbyte/second
> 	UDP over ATM)

Does anyone want to comment on any of these ?

Can they be fixed ?  Is there any reason not to fix them ?
(Providing someone understands what he means).

> nor the FreeBSD code with files that say "You can't modify this until I
> find the official boilerplate" and about ten people needing contains software
> from XXXX credits.
> For the Linux community BSD networking offers very little but some better
> TCP algorithms which themselves can be bettered (and will be).

Again, comments ?

> > We are going to some *nix operating system in rather critical applications.
> > We have already tested Linux, but are not sure if it is reliable enough. 
> > Your comments?
> ----
> It runs our firewall runs various others. Since you can render any Linux or
> BSD system unusable from a remote site, you don't want to worry about
> denial of service attack in any case. [This also goes for all BSD stacks and
> almost all others]. Its hard to evaluate reliability of Linux, BSD or
> most Unix systems because nobody has ever subjected them to detailed
> analysis and peer review of code. The B level secure Xenix was probably
> the only exception.
> Both are fine systems. Both Linux and FreeBSD current use the same packet
> filter code (near enough). From a security point of view sendmail, nfs,
> and other security holes are far more significant. For both sets of systems
> we have found hardware is critical for reliability much more than anything
> else. (no bad NE2000 clones, avoid some clone adaptec controllers, buy
> at least some kind of power supply smoothing etc). People run internet
> providers on both systems, but I know of nothing beyond this level of
> "If it fails we get serious hassle and have to reboot" degree of reliability.
> For a system with commercial support something like BSD/OS may be of 
> interest. OK it costs money but its written by the people who wrote
> 4.4BSD (NetBSD and FreeBSD is basically people who picked BSD up afterwards).
> BTW: For filtering there is at least one commercial filter product for
> Linux. See I can't comment on
> its quality.
> Alan