>> - Some boxes have "less than optimal" IP implementations, and just can't
>>   deal with them.  For example, some older Annexes would crash upon getting
>>   packets with IP options set.
>
>If we have demonstrable cases of current or widespread implementations
>that crash or otherwise misbehave in the presence of timestamps, we
>should at least investigate as to whether this condition can be
>detected and worked around. Have demonstrable cases and packet traces
>would be nice.

I've never seen the Annex behavior that I talked about; I just remember
hearing about it on current-users (my Annex at home works just fine).
My understanding was it was along the lines of: You telnet to the Annex,
and "poof!", the machine crashes.  Kinda hard to get a packet trace from
that :-)  But like I said, I may have gotten the details wrong.

>> - IP options interact badly with some versions of PPP when VJ header
>>   compression is enabled.  For example, Telebit Netblazers will eat packets
>>   that have IP options set if you use PPP and VJ header compression.
>
>I was aware that in some cases RFC1323 destroyed the optimality
>of VJ compression; I was not aware that it caused Netblazers to
>_eat_ packets. Is this demonstable and reproducible? Do we have
>packet traces of what happens? Has someone yelled at Telebit?

Actually, it more along the lines of: "chews them up, and spits out the
mangled carcass" :-).  You got a packet, but it was pretty mangled.

In answer to your questions: Yes, yes, and yes.

Telebit's response was: "Well, since there is a workaround (turn off VJ
header compression), it's not a high-priority bug.  It might get fixed in
the next release, might not".  Turns out the bug has been known about for
a while.

Sigh.

>> I would try two things:
>> 
>> - Turn off VJ header compression on the PPP connection
>> - Turn off rfc1323 via sysctl.
>
>The reverse order is probably preferrable. While dialup PPP links
>may be "long", they are very rarely "fat", and as such RFC1323
>should be rarely necessary. VJ "compression", on the other hand, is
>quite often useful.

Well, I was trying to help him diagnose the problem -- if he could pinpoint
the problem down to VJ header compression, it would help him figure out
where the problem lies more specifically, and who to complain to :-)

--Ken