Mark Murray wrote:
> Terry Lambert writes:
> > Mark Murray wrote:
> > > Will it be runnable (as in tested), rather than a compile-only fix?
> >
> > Is "tested" a requirement fo code to be committed or to have it
> > stay in the tree?
>
> Both.
Cool. Then I have a long list of things that can be fixed
or removed.
This whole thing about netns started 3 days ago.
How many days after code is questioned does someone have to fix
it before it is it OK to dike it out?
> > Be careful of your answer, unless you are willing to remove all
> > code that does not meet that criteria...
>
> Be careful of your interpretation of my answer. State _all_ your
> premises, and be careful not to use any undeclared ones. Do not hold
> me to any premise that I have not agreed to.
>
> All broken code needs to be fixed XOR removed. All fixes need to be
> tested. All code in the tree needs to be tested often to ensure that
> it is not broken.
Let' start wth the libalias/natd incremental checksum update code;
the code is based on RFC1141, instead of RFC1624. As a result,
it get updated incorrectly occasionally, because it's using two's
complement instead of one's complement math. Per RFC1642:
RFC 1141 yields an updated header checksum of -0 when it should be
+0. This is because it assumed that one's complement has a
distributive property, which does not hold when the result is 0 (see
derivation of [Eqn. 2]).
People see this as hands on FTP installs, etc., going through
FreeBSD based NAT's.
It's very obvious ad easy to repeat:
1) Put a printf in tcp_input.c that compalins when the
checksum is incorect.
2) Do a CVSup from that machine through a FreeBSD NAT
How long can this remain unfixed before the code is diked out,
and the checksum is recalculated fully, instead?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
