TCP/IP Testing help, Round 2

[der Mouse]

>> So when you hit Ctrl-C under a typical Telnet client in Unix, you
>> are sending the equivalent of a 'process' interrupt.
> Most likely an Interrupt Process (0xff 0xf4) sequence, quite possibly
> an Abort Output (0xff 0xf5) and/or a Synch (0xff 0xf2 with the TCP
> urgent pointer pointing just after the 0xf2) as well.

>> [...]
> I'll snoop traffic and try a ^C to see what's really going on - at
> the wire level, at least.

I've now got something to report.

This may well vary according to the telnet client.  The test I did was
with a moderately old NetBSD telnet client.

When I typed ^C, I saw, on the wire (in hex), ff f4 ff fd 06.  This is
IAC IP IAC DO TIMING-MARK.  But I never see IAC WILL TIMING-MARK or IAC
WONT TIMING-MARK coming back, which is probably why the telnet client
hangs - it's expecting one or the other.  (And, in passing, it doesn't
actually hang; I can type and what I type goes out.  But it doesn't
show me anything that comes back, even though data does come back,
presumably waiting for a response to its IAC DO TIMING-MARK.)

I did server-side code for a mud for which we wanted to support telnet
connections.  I had to make the server recognize enough protocol to
refuse to negotiate any options on (IAC DO xxx produced IAC WONT xxx;
IAC WILL xxx produced IAC DONT xxx).  If you could do that much, and
swallow most (all?) of the other IAC xxx commands, telnet will probably
work better to connect to it.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B