> Below Holger describes what he believes to be an outstanding bug in
> Linux'es TCP/IP implimation which he claims is holding up deployment of
> T/TCP. Any comments?
Sounds to me like Holger was going to be providing the TCP/IP for Amiga
until they switched OS, but thats a guess and probably just as out of order
and uncalled for as his flames ...
> workarounds in Miami is that Linux sends bogus RST packets in response
> to ACK packets after a while if a connection was created with a packet
> that has the SYN+FIN flags set and contains data. The workaround
Its not a bug either
> SYN+FIN+data packets). The response I received from the Linux group at
> the time was that SYN+FIN+data packets are illegal anyway, because
> T/TCP is "experimental". Of course that argument is false, because
They are undefined, and invalid frames.
> SYN+FIN+data packets by themselves have nothing to do with T/TCP and
> are not forbidden by RFC 793, i.e. Linux is supposed to handle this
They are undefined by RFC793 - you sent data into an undefined window. This
was beaten to death several years ago on various tcp lists.
> lack therefore) of T/TCP. See Stevens' "TCP/IP Illustrated Volume 3"
> for more information on this issue.
RFC1644 says T/TCP is experimental and _should_not_be_implemented_ in
a production system
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
