Yet another (hopefully not so) stupid question on telnet - TCP-IP

This is a discussion on Yet another (hopefully not so) stupid question on telnet - TCP-IP ; Hi all, I need to write a few lines of code in order to talk to legacy stuff through a TELNET session. I've read the documentation (RFCs) and my understanding is that the only thing I have to deal with ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Yet another (hopefully not so) stupid question on telnet

  1. Yet another (hopefully not so) stupid question on telnet

    Hi all,

    I need to write a few lines of code in order to talk to legacy stuff
    through a TELNET session. I've read the documentation (RFCs) and my
    understanding is that the only thing I have to deal with is IAC (and
    all the rules behind). So, my first implementation was based on a dummy
    client that just recognize IAC and associated commands (and do nothing
    with it), thinking this was enough... bad move!!! It seems some servers
    do not like this, so I'm going to send WON'T and DON'T when I receive
    DO and WILL, but I'm still wondering... (the server is sending some
    commands I don't understand in the context of the connection life).

    (1) if a TELNET client or server just do nothing with IAC... is it
    "bad" ? (is it mandatory to answer back to TELNET command) ?
    (2) can the negociation occur at any time (not just at the begining) ?
    (my understanding is yes... but in practical ?)

    Thanks!

    /Thomas


  2. Re: Yet another (hopefully not so) stupid question on telnet

    In article <1156723641.508555.181830@h48g2000cwc.googlegroups. com>,
    "Little Thomas" wrote:

    > Hi all,
    >
    > I need to write a few lines of code in order to talk to legacy stuff
    > through a TELNET session. I've read the documentation (RFCs) and my
    > understanding is that the only thing I have to deal with is IAC (and
    > all the rules behind). So, my first implementation was based on a dummy
    > client that just recognize IAC and associated commands (and do nothing
    > with it), thinking this was enough... bad move!!! It seems some servers
    > do not like this, so I'm going to send WON'T and DON'T when I receive
    > DO and WILL, but I'm still wondering... (the server is sending some
    > commands I don't understand in the context of the connection life).
    >
    > (1) if a TELNET client or server just do nothing with IAC... is it
    > "bad" ? (is it mandatory to answer back to TELNET command) ?
    > (2) can the negociation occur at any time (not just at the begining) ?
    > (my understanding is yes... but in practical ?)


    If you read RFC 1123, you'll see that some options are no longer
    optional, all implementations are required to support them. For
    instance:

    3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858

    On a host that never sends the Telnet command Go Ahead (GA),
    the Telnet Server MUST attempt to negotiate the Suppress Go
    Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or
    Server Telnet MUST always accept negotiation of the Suppress Go
    Ahead option.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: Yet another (hopefully not so) stupid question on telnet

    Oups... it seems I forgot to read some RFCs... =(
    So the good news is I now know there is mandatory behavior, the bad
    news is I still don't know why some servers are sending me some strange
    noise...

    /Thomas

    Barry Margolin wrote:
    > In article <1156723641.508555.181830@h48g2000cwc.googlegroups. com>,
    > "Little Thomas" wrote:
    >
    > > Hi all,
    > >
    > > I need to write a few lines of code in order to talk to legacy stuff
    > > through a TELNET session. I've read the documentation (RFCs) and my
    > > understanding is that the only thing I have to deal with is IAC (and
    > > all the rules behind). So, my first implementation was based on a dummy
    > > client that just recognize IAC and associated commands (and do nothing
    > > with it), thinking this was enough... bad move!!! It seems some servers
    > > do not like this, so I'm going to send WON'T and DON'T when I receive
    > > DO and WILL, but I'm still wondering... (the server is sending some
    > > commands I don't understand in the context of the connection life).
    > >
    > > (1) if a TELNET client or server just do nothing with IAC... is it
    > > "bad" ? (is it mandatory to answer back to TELNET command) ?
    > > (2) can the negociation occur at any time (not just at the begining) ?
    > > (my understanding is yes... but in practical ?)

    >
    > If you read RFC 1123, you'll see that some options are no longer
    > optional, all implementations are required to support them. For
    > instance:
    >
    > 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
    >
    > On a host that never sends the Telnet command Go Ahead (GA),
    > the Telnet Server MUST attempt to negotiate the Suppress Go
    > Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or
    > Server Telnet MUST always accept negotiation of the Suppress Go
    > Ahead option.
    >
    > --
    > Barry Margolin, barmar@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***



  4. Re: Yet another (hopefully not so) stupid question on telnet

    Be careful of loops! That is, if the server sends
    IAC DO TRANSMIT-BINARY
    and you react with
    IAC WONT TRANSMIT-BINARY
    then the server will react with
    IAC DONT TRANSMIT-BINARY
    if you then send
    IAC WONT TRANSMIT-BINARY
    then the server will react with
    IAC DONT TRANSMIT-BINARY
    ....etc...

    For each option which you implement, you MUST remember the state that the
    option is current in, and only send back a reponse to the server if the
    server sent something that changed the state of the option.

    For each option which you do NOT implement, you MUST send back a WONT/DONT
    if the server attempts a DO/WILL respectively. You MUST NOT send back
    anything if the server sends DONT/WONT because options start as being
    unset.

    Hence, using the above example, if you don't support TRANSMIT-BINARY:

    The server sends
    IAC DO TRANSMIT-BINARY
    you react with
    IAC WONT TRANSMIT-BINARY
    the server sends
    IAC DONT TRANSMIT-BINARY
    you now send nothing.

    Now, let's consider an option which you do implement, such as SUPPRESS-GA.
    Here's how that goes:

    The server sends
    IAC WILL SUPPRESS-GA
    you react with
    IAC DO SUPPRESS-GA

    If the server subsequently sends a second
    IAC WILL SUPPRESS-GA
    you now send nothing.

    If the server subsequently sends
    IAC WONT SUPPRESS-GA
    then you MUST send
    IAC DONT SUPPRESS-GA
    because it is changing the state of SUPPRESS-GA from on to off. If the
    server subsequently sends a second
    IAC WONT SUPPRESS-GA
    you now send nothing.


    Now, let's consider an option which you implement, but the server does
    not:

    You send
    IAC DO RANDOMLY-LOSE
    and the server reacts with
    IAC WONT RANDOMLY-LOSE
    you must now respond with
    IAC DONT RANDOMLY-LOSE


    MANY novice programmers implement TELNET protocol incorrectly. It is
    quite difficult to get correct until you remember the basic principles:

    1) All options start as being NOT set.

    2) ALWAYS send a response to any command that changes the state of an
    option (whether set to not set, or not set to set).

    3) NEVER respond to a command that does not change the state of an option
    (set to set, or not set to not set).


    If your implementation initiates the change in an option, a way to get
    this right is to change your state of the option immediately upon your
    sending the command to initiate the state change. That way, the server's
    response to confirm the change will be seen by you as "no change" (and
    thus you do not response) and the server's response to reject the change
    will be seen by you as "change" (and thus you have to respond).

    Lest someone say "that isn't right", no less a personage than Jon Postel
    personally reviewed this strategy and my implementation in multiple PDP-10
    TELNET clients and servers and pronounced it good.

    -- Mark --

    http://panda.com/mrc
    Democracy is two wolves and a sheep deciding what to eat for lunch.
    Liberty is a well-armed sheep contesting the vote.

  5. Re: Yet another (hopefully not so) stupid question on telnet


    Thanks Mark! As I only need to support SGA, I will keep in mind your
    recommandation... On the other hand I still don't understand the
    response I got from one server... I've got FF FF (IAC IAC) which should
    mean data = 255, but this seems wrong... don't know why I'm getting
    this... I'll take a look.

    Mark Crispin wrote:
    > Be careful of loops! That is, if the server sends
    > IAC DO TRANSMIT-BINARY
    > and you react with
    > IAC WONT TRANSMIT-BINARY
    > then the server will react with
    > IAC DONT TRANSMIT-BINARY
    > if you then send
    > IAC WONT TRANSMIT-BINARY
    > then the server will react with
    > IAC DONT TRANSMIT-BINARY
    > ...etc...


    Thanks!

    /Thomas


  6. Re: Yet another (hopefully not so) stupid question on telnet

    Mark Crispin writes:
    > Be careful of loops! That is, if the server sends
    > IAC DO TRANSMIT-BINARY
    > and you react with
    > IAC WONT TRANSMIT-BINARY
    > then the server will react with
    > IAC DONT TRANSMIT-BINARY
    > if you then send
    > IAC WONT TRANSMIT-BINARY
    > then the server will react with
    > IAC DONT TRANSMIT-BINARY


    Besides the bug you're citing, the server's also broken if it does
    that -- the second IAC WONT doesn't imply a change of state (we were
    already in the "off" state for the option due to the DONT), so it
    shouldn't send IAC DONT again.

    I think that in this case you need _two_ bugs to cause the behavior
    you're describing.

    > MANY novice programmers implement TELNET protocol incorrectly. It is
    > quite difficult to get correct until you remember the basic principles:


    You left out the case where the server sends "IAC WILL" (rather than
    "IAC DO") for some option because it wants you to turn some feature
    on. If you don't understand the feature, you must send "IAC DONT" in
    reply to the "IAC WILL," and the peer will send "IAC WONT."

    It's symmetrical.

    (Other than that, your advice is very good.)

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  7. Re: Yet another (hopefully not so) stupid question on telnet

    On Tue, 5 Sep 2006, James Carlson wrote:
    > I think that in this case you need _two_ bugs to cause the behavior
    > you're describing.


    Correct; it usually requires two broken implementations to have a loop.
    However, I have seen loops that only involved one broken implementation.
    I forget the details, but I was quite impressed at the talent ;-) that
    went into getting it that badly broken.

    It was something absurd, such as a server that insisted upon negotiating
    IAC DO SUPRESS-GA or IAC DO ECHO to the client, and then not taking no for
    an answer (clients do not send GAs, nor echo) by sending it again in
    response to the WONT. But it's been at least 20 years since I saw that.

    > You left out the case where the server sends "IAC WILL" (rather than
    > "IAC DO") for some option because it wants you to turn some feature
    > on. If you don't understand the feature, you must send "IAC DONT" in
    > reply to the "IAC WILL," and the peer will send "IAC WONT."
    > It's symmetrical.


    Correct.

    -- Mark --

    http://staff.washington.edu/mrc
    Science does not emerge from voting, party politics, or public debate.
    Si vis pacem, para bellum.

+ Reply to Thread