I am searching for "readable" telnet negotiation information but I
thought I'd ask here in the meantime in case someone has a reference
or suggestion handy.

I guess my basic question is ... is it possible to put a telnet server
into RAW (?) mode so that it doesn't watch the transfering stream for
re-negotiation requests?

I am having a problem in my application and it looks like a byte is
showing up in the data stream that the originator didn't send.  I am
assuming that the telnet server is adding it as it looks very similar
to a negotiation request.

I am writing a modem simulator for an Apple // emulator (Kegs) and I
have it working pretty well to connect up a telnet session.  I am now
trying XModem transfers over the link and I'm getting errors at the
32K point.  XModem sends 128 byte packets with a 3 byte header and 2
byte tail, for a total packet of 133 bytes.  At the 32K byte mark the
packet size is increasing to 134 bytes, this is packet 254.

The bytes in question (in the packet header) look like:

sent by originator: x01 xFF x00
receiver gets:      x01 xFF xFF x00

I'm not 100% certain telnetd is the culprit but I'm looking for
information to determine that it isn't.

Thanks in advance for any pointers.

--
------------------------------------------------
http://www3.sympatico.ca/dmitton
SPAM Reduction: Remove "x." from my domain.
------------------------------------------------

[ Post a follow-up to this message ]

Doug Mitton <doug_mitton@hotmail.x.com> writes:
quote:

> I am searching for "readable" telnet negotiation information but I
> thought I'd ask here in the meantime in case someone has a reference
> or suggestion handy.


RFC854, http://www.rfc-editor.org/rfc/rfc854.txt, looks pretty
readable to me.
quote:

> I guess my basic question is ... is it possible to put a telnet server
> into RAW (?) mode so that it doesn't watch the transfering stream for
> re-negotiation requests?


I'll let someone else come with a definitive answer, but I doubt it.
I can't remember ever reading about anything like that.
quote:

> I am having a problem in my application and it looks like a byte is
> showing up in the data stream that the originator didn't send.  I am
> assuming that the telnet server is adding it as it looks very similar
> to a negotiation request.
>
> The bytes in question (in the packet header) look like:
>
> sent by originator: x01 xFF x00
> receiver gets:      x01 xFF xFF x00


A 0xff character means that the next character is a telnet command.
To send a literal 0xff, it needs to be escaped with an extra 0xff.
Thus, if the telnet server or client receives such a character as
user/application input, it will add the escaping.
quote:

> I'm not 100% certain telnetd is the culprit but I'm looking for


I'd say that's the case.  Is your program acting as either telnet
server or client?  Otherwise you shouldn't need to worry about these
things.

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

Doug Mitton <doug_mitton@hotmail.x.com> writes:
quote:

> I am searching for "readable" telnet negotiation information but I
> thought I'd ask here in the meantime in case someone has a reference
> or suggestion handy.


RFC854, http://www.rfc-editor.org/rfc/rfc854.txt, looks pretty
readable to me.
quote:

> I guess my basic question is ... is it possible to put a telnet server
> into RAW (?) mode so that it doesn't watch the transfering stream for
> re-negotiation requests?


I'll let someone else come with a definitive answer, but I doubt it.
I can't remember ever reading about anything like that.
quote:

> I am having a problem in my application and it looks like a byte is
> showing up in the data stream that the originator didn't send.  I am
> assuming that the telnet server is adding it as it looks very similar
> to a negotiation request.
>
> The bytes in question (in the packet header) look like:
>
> sent by originator: x01 xFF x00
> receiver gets:      x01 xFF xFF x00


A 0xff character means that the next character is a telnet command.
To send a literal 0xff, it needs to be escaped with an extra 0xff.
Thus, if the telnet server or client receives such a character as
user/application input, it will add the escaping.
quote:

> I'm not 100% certain telnetd is the culprit but I'm looking for


I'd say that's the case.  Is your program acting as either telnet
server or client?  Otherwise you shouldn't need to worry about these
things.

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

mru@kth.se (Måns Rullgård) wrote:
quote:

>Doug Mitton <doug_mitton@hotmail.x.com> writes:
> 
>
>RFC854, http://www.rfc-editor.org/rfc/rfc854.txt, looks pretty
>readable to me.


I had been reading Googled answers to questions, source code snips and
whole source code downloads.  I hadn't looked into RFC's before as
(for some reason) I thought they read like MAN pages ... which can be
rather cryptic.  Yes, the first one I hit was RFC 0008 and it was
completely readable and told me my problem right near the end of the
document.
quote:
 
>
>I'll let someone else come with a definitive answer, but I doubt it.
>I can't remember ever reading about anything like that.


There is a BINARY mode BUT it still allows the xFF monitoring and it
must still be escaped.
quote:
 
>
>A 0xff character means that the next character is a telnet command.
>To send a literal 0xff, it needs to be escaped with an extra 0xff.
>Thus, if the telnet server or client receives such a character as
>user/application input, it will add the escaping.
> 
>
>I'd say that's the case.  Is your program acting as either telnet
>server or client?  Otherwise you shouldn't need to worry about these
>things.


My program is acting as a client to the Kegs emulator AND a client to
telnetd, I am simply "crossing" the sockets so the 2 can talk to each
other; that is an old Apple // terminal emulator program can now
actually get out on the internet as a telnet client.

I have modified my program to capture xFF bytes and escape/unescape as
required BUT the Xmodem protocol is still claiming a malformed header
when the transfer hits packet 254.  So, I'm off to take a look at
Xmodem specs.

Thanks for the response and the link to RFC's!
--
------------------------------------------------
http://www3.sympatico.ca/dmitton
SPAM Reduction: Remove "x." from my domain.
------------------------------------------------

[ Post a follow-up to this message ]

mru@kth.se (Måns Rullgård) wrote:
quote:

>Doug Mitton <doug_mitton@hotmail.x.com> writes:
> 
>
>RFC854, http://www.rfc-editor.org/rfc/rfc854.txt, looks pretty
>readable to me.


I had been reading Googled answers to questions, source code snips and
whole source code downloads.  I hadn't looked into RFC's before as
(for some reason) I thought they read like MAN pages ... which can be
rather cryptic.  Yes, the first one I hit was RFC 0008 and it was
completely readable and told me my problem right near the end of the
document.
quote:
 
>
>I'll let someone else come with a definitive answer, but I doubt it.
>I can't remember ever reading about anything like that.


There is a BINARY mode BUT it still allows the xFF monitoring and it
must still be escaped.
quote:
 
>
>A 0xff character means that the next character is a telnet command.
>To send a literal 0xff, it needs to be escaped with an extra 0xff.
>Thus, if the telnet server or client receives such a character as
>user/application input, it will add the escaping.
> 
>
>I'd say that's the case.  Is your program acting as either telnet
>server or client?  Otherwise you shouldn't need to worry about these
>things.


My program is acting as a client to the Kegs emulator AND a client to
telnetd, I am simply "crossing" the sockets so the 2 can talk to each
other; that is an old Apple // terminal emulator program can now
actually get out on the internet as a telnet client.

I have modified my program to capture xFF bytes and escape/unescape as
required BUT the Xmodem protocol is still claiming a malformed header
when the transfer hits packet 254.  So, I'm off to take a look at
Xmodem specs.

Thanks for the response and the link to RFC's!
--
------------------------------------------------
http://www3.sympatico.ca/dmitton
SPAM Reduction: Remove "x." from my domain.
------------------------------------------------

[ Post a follow-up to this message ]