RFC 2217

Telnet Com Port Control Option

πŸ“… published October 1997, from ietf

Telnet Com Port Control Option πŸ’–

Okay bestie, so this is RFC 2217, titled Telnet Com Port Control Option πŸŽ€. It was written by G. Clark at Cisco Systems, Inc. πŸ‘‘ It's in the Experimental category, dated October 1997 πŸ¦‹. The header doesn't list anything it obsoletes or updates, so that's a no-drama situation ✨.

Quick heads up on the status: this is an Experimental Protocol for the Internet community. It is NOT an Internet standard, and the authors are literally asking for feedback and suggestions for improvement 🫢. Distribution is unlimited 🌈.


Introduction 🌸

The whole point of this memo is to let people use modems attached to a network for outbound dialing πŸ“žβœ¨.

Table of Contents 🧚

Here's the official table of contents, kept exactly as the original has it πŸ’…:

1. Negotiation of the Com Port
   Control Option Protocol          ..................   5
2. Com Port Configuration Commands  ..................   6
     Version
     Baud Rate
     Data Bit Size
     Parity
     Stop Bit size
3. Special Com Port Control Commands .................   8
     XON/XOFF Flow Control
     HARDWARE Flow Control
     BREAK Signal
     DTR Signal
     RTS Signal
  4. Notification of Com Port and     ..................    12
     Modem Line Changes
  5. Flow Control                     ..................    13
  6. Security Considerations          ..................    13
  7. Author's Address                 ..................    14
  8. Reference Section                ..................    14

Discussion πŸ’œ

Okay, so the Telnet protocol is basically an interactive, character-oriented communications session πŸ’¬. It was first designed so a client could set up a session with a remote login service running on a host [5] πŸ–₯️✨.

Lots of new business stuff needs people to connect to remote services to grab or drop off information πŸ“‚. Honestly, those remote services are mostly reached over an async dial-up connection πŸ“žπŸ˜­. This new class of functions includes:

  • dial-up connections to the Internet
  • connecting to bulletin boards
  • connecting to internal and external databases
  • sending and receiving faxes

This whole category needs an interactive, character-oriented session over an async modem, and people call that outbound modem dialing πŸ”₯.

To avoid the cost of installing and maintaining extra phone lines that barely get used per person, a bunch of manufacturers added the ability to start a Telnet session straight to the outbound ports on popular access servers and routers 🧚. From here on, those are just called access servers πŸ’–.

BUT, and this is a big but 😀, the current Telnet protocol definitions aren't enough for this use. Three new areas of functionality need to be added to Telnet to properly support outbound modem dialing:

  • Com port configuration: The client needs to be able to send com port configuration info to the access server connected to the outbound modem. This makes sure the data going in and out of the modem is formatted correctly at the byte level πŸŽ€.
  • Modem line and signal notifications: The access server needs to tell the client about any modem line or signal changes, like RLSD changes (carrier detect) πŸ“Ά. This info is vital because lots of client software uses it to figure out whether a session with the remote service has been set up πŸ’…. RLSD changes are also used for signaling in Class I faxing [6] πŸ“ .
  • Flow control that doesn't interfere: The client and access server need flow control that doesn't mess with the flow control already used between the client and the remote service 🫢. RFC 1372 "Telnet Remote Flow Control Option" [2] can't do this job, because it relies on XON/XOFF style characters. Those can show up as normal traffic in the client and remote service session, so it's giving confusion πŸ’€.

Even though this doc is mostly about outbound modem dialing, the protocol works for any serial device attached to an access server 🌈. Some examples:

  • serial printers
  • plotters
  • monitoring devices like pipe line monitors or medical monitors
  • general office equipment like photo-copiers and cash registers

Definition of Terms ⭐

Let's get the vocab straight, bestie πŸ“š:

  • Access Server: Any network device that accepts Telnet sessions, passes the data it receives to a com port, and passes data from the com port back to the client through the Telnet session πŸ–₯️.
  • Baud Rate: For this document, baud rate means the communication of data in bits per second πŸ”’.
  • Client: Any network device that starts a Telnet session to an access server πŸ’».
  • Outbound: Data going from the modem attached to the access server out to a remote service ➑️.
  • Inbound: Data going from the remote service to the modem attached to the access server ⬅️.
  • Remove Service: Any service that accepts dial-up connections, including fax machines πŸ“ .

Illustration πŸ¦‹

Here's the picture, copied exactly as the original draws it 🎨:

  =====================
  |                   |
  |      CLIENT       |\
  |                   | \ < ---- Local Area /
  =====================  \       Enterprise Network
                          \
                           \
                         =============================
                         |      Telnet Interface     |
                         |                  |        |
                         |                  |        |
                         |  ACCESS SERVER   |        |
                         |                  |        |
                         |                  |        |
                         |     Com Port Interface    |
                         =============================
                                      |
                                      |
                              ==================
                              |                |
                              |      MODEM     |
                              |                |
                              ==================
                                      |
  Access to Remote Service            |
  most commonly Public Switched ----->|
  Network                             |
                                      |
                                      |
                            ======================
  Could be Internet Service |                    |
  Provider, Bulletin Board  |                    |
  or FAX machine            |    REMOTE SERVICE  |
                            |                    |
                            |                    |
                            ======================

Command Names and Codes πŸ”₯

The option uses this code, and here are the command names and codes in both directions:

  Command Names and Codes:
       COM-PORT-OPTION       44

                   Client to Access Server   Access Server to Client
       SIGNATURE            text                      text
       SET-BAUDRATE            1                      101
       SET-DATASIZE            2                      102
       SET-PARITY              3                      103
       SET-STOPSIZE            4                      104
       SET-CONTROL             5                      105
       NOTIFY-LINESTATE        6                      106
       NOTIFY-MODEMSTATE       7                      107
       FLOWCONTROL-SUSPEND     8                      108
       FLOWCONTROL-RESUME      9                      109
       SET-LINESTATE-MASK     10                      110
       SET-MODEMSTATE-MASK    11                      111
       PURGE-DATA             12                      112

Discussion note 🧠: At first, com port configuration commands were only meant to go from the client to the access server πŸ“€. Nobody currently expects the access server to start a com port configuration command. It's really just the notify commands that come from the access server πŸ””. Still, the authors set up different command values so an access server could start a com port configuration later on 🌸.


1. Negotiation of the Com Port Control Option Protocol ✨

So negotiation for this option uses the standard Telnet negotiation mechanism 🀝. There are four commands:

  • IAC WILL COM-PORT-OPTION: The sender is willing to send com port control option commands πŸ“€.
  • IAC WONT COM-PORT-OPTION: The sender refuses to send com port control option commands πŸ™….
  • IAC DO COM-PORT-OPTION: The sender is willing to accept com port control option commands πŸ“₯.
  • IAC DONT COM-PORT-OPTION: The sender refuses to accept com port control option commands πŸ’€.

Typically, a client uses WILL and WONT, and an access server uses DO and DONT πŸ’–. Basically the client is the sender and the server is the receiver, periodt πŸ’….

2. Com Port Configuration Commands ✨

okay so once DO and WILL have been negotiated πŸŽ€, the client can send any of these commands whenever it wants, and as many times as it wants during the Telnet session πŸ’…. every command the client sends to the access server must be acknowledged once the access server has processed it. the ack tells the client what value is actually set on the access server after processing 🫢. it is NOT a receipt confirmation, because that happens down at the TCP layer πŸ™ˆ. the whole point of the ack is to show the value in use, which can be different from what the client asked for. for example, the client might request a baud rate that the access service can't actually provide 😭. if the client doesn't get an ack within a reasonable time (like twice the delay acknowledgment timer), it may resend the command or end the session πŸ’€.

ngl the commands can be sent in any order, but some orders can make the com port config invalid 😬. like, EVEN parity is only valid if the data size is less than 8 bits πŸ™…β€β™€οΈ. so it is recommended that commands go out in this order:

  1. SET-BAUDRATE
  2. SET-DATASIZE
  3. SET-PARITY
  4. SET-STOPSIZE

IAC SB COM-PORT-OPTION SIGNATURE <text> IAC SE

this one can be sent by the client or the access server to swap signature info πŸ¦‹. if it's sent with no <text>, the sender is basically asking the other side for its signature text πŸ‘€. the text can be any characters at all, and there's no required structure. it could have manufacturer info, a version number, or whatever else you want 🌸. if an IAC character shows up in the text, it must be translated to IAC-IAC so it doesn't get confused with the IAC that ends the command 🧚.


IAC SB COM-PORT-OPTION SET-BAUD <value(4)> IAC SE

the client sends this to the access server to set the com port's baud rate πŸš€. the value is four octets (4 bytes) and it's in network standard format πŸ’œ. the value is the baud rate being requested. there's a special case, though: a value of 0 means the client is asking for the current baud rate on the access server πŸ“.

Discussion: okay the baud rates we use today are super spread out 🌈, and the first version of this option used an index-based baud rate table. after a lot of back and forth with a bunch of groups, they decided the actual baud rate should be sent instead ✨. two big reasons: 1) it cuts down on how often the option needs updating as faster baud rates show up πŸ”₯, and 2) it gives way more flexibility when picking baud rates πŸ’….

IAC SB COM-PORT-OPTION SET-DATASIZE <value> IAC SE

the client sends this to set the data bit size on the access server, and it can also be used to ask what the current data bit size is πŸŽ€. the value is one octet (byte) and it's an index into this table:

    Value       Data Bit Size
      0           Request Current Data Bit Size
      1           Available for Future Use
      2           Available for Future Use
      3           Available for Future Use
      4           Available for Future Use
      5           5
      6           6
      7           7
      8           8
      9-127       Available for Future Use
Discussion: there are only eight possible values for data bit size 🀯. only four were ever used historically, and only two are commonly used today πŸ¦‹. the command-value format is recommended so it stays consistent with the other commands 🫢. it also keeps the number of commands in the protocol down and leaves room for future expansion 🌸.

IAC SB COM-PORT-OPTION SET-PARITY <value> IAC SE

the client sends this to set the parity on the access server 🧚. it can also be used to ask for the current parity πŸ‘€. the value is one octet (byte) and it's an index into this table:

     Value      Parity [1]
       0           Request Current Data Size
       1           NONE
       2           ODD
       3           EVEN
       4           MARK
       5           SPACE
       6-127       Available for Future Use
Discussion: only five parity values are commonly used today πŸ’–. the command-value format is recommended so it stays consistent with the other commands πŸ’….

IAC SB COM-PORT-OPTION SET-STOPSIZE <value> IAC SE

the client sends this to set the number of stop bits 🌈. it can also be used to ask what the current stop bit size is ✨. the value is one octet (byte) and it's an index into this table:

    Value      Stop Bit Size
      0           Request Current Data Size
      1           1
      2           2
      3           1.5
      4-127       Available for Future Use
Discussion: stop bit 1.5 is only supported by most com port hardware when the data size is set to 5 bits 😭. it's not commonly used πŸ’€.

3. Special Com Port Control Commands ✨

okay so the client can send this command to the access server literally any time during the Telnet session, and as many times as it wants πŸ’…. every command the client sends gets acknowledged with a confirmation of the command AND the actual value that got set 🫢. the client should expect a response within a reasonable time (like twice the delay acknowledgment timer). the client may wish to resend any command that didn't get acknowledged, or just terminate the session 😭

SET-CONTROL

IAC SB COM-PORT-OPTION SET-CONTROL <value> IAC SE

the client sends this to the access server to set special com port options. it can also be sent just to query the current option value πŸ” the value is one octet (byte), and it's an index into the value table below πŸŽ€

    Value      Control Commands
      0           Request Com Port Flow Control Setting
                    (outbound/both)
      1           Use No Flow Control (outbound/both)
      2           Use XON/XOFF Flow Control (outbound/both)
      3           Use HARDWARE Flow Control (outbound/both)
      4           Request BREAK State
      5           Set BREAK State ON
      6           Set BREAK State OFF
      7           Request DTR Signal State
      8           Set DTR Signal State ON
      9           Set DTR Signal State OFF
     10           Request RTS Signal State
     11           Set RTS Signal State ON
     12           Set RTS Signal State OFF
     13           Request Com Port Flow Control Setting (inbound)
     14           Use No Flow Control (inbound)
     15           Use XON/XOFF Flow Control (inbound)
     16           Use HARDWARE Flow Control (inbound)
     17           Use DCD Flow Control (outbound/both)
     18           Use DTR Flow Control (inbound)
     19           Use DSR Flow Control (outbound/both)
     20-127       Available for Future Use

Discussion: flow control options got split into inbound and outbound so we can fully use the existing programming interfaces and what the access server can already do ✨

Discussion: the outbound values set flow control for BOTH outbound and inbound πŸ‘‘ if inbound is going to be set separately (or CAN be), do that AFTER setting the outbound value, bestie πŸ™ˆ

Discussion: if the access server can't set inbound flow control differently from outbound, it should ignore the inbound flow control commands and set the flow control option based on the outbound commands only πŸ’€

SET-LINESTATE-MASK

IAC SB COM-PORT-OPTION SET-LINESTATE-MASK <value> IAC SE

this is how the client sets a bit mask for sending the NOTIFY-LINESTATE option (see section 4) πŸ¦‹ when the LINESTATE changes on the access server, the access server does an "AND" of the new LINESTATE with the LINESTATE-MASK. if the result isn't zero, the access server sends that "AND" result as the value in a NOTIFY-LINESTATE com port option. if more than one bit satisfies the LINESTATE-MASK, only ONE NOTIFY-LINESTATE gets sent, with all the satisfying bits in it 🧚 the SET-LINESTATE-MASK can be any combination of the bits below. they're the same bit values used in NOTIFY-LINESTATE, and they're based on the most popular UART (com port control chip) in use [1] 🌸

    Bit Position     Value     Meaning
       7              128         Time-out Error
       6               64         Transfer Shift Register Empty
       5               32         Transfer Holding Register Empty
       4               16         Break-detect Error
       3                8         Framing Error
       2                4         Parity Error
       1                2         Overrun Error
       0                1         Data Ready

Discussion: a SET-LINESTATE-MASK value of 0 stops the access server from sending NOTIFY-LINESTATE options to the client πŸ™…β€β™€οΈ

Discussion: a SET-LINESTATE-MASK value of 255 lets the access server send a NOTIFY-LINESTATE option to the client every single time the LINESTATE changes on it πŸ”₯

Discussion: the initial LINESTATE-MASK at the access server is 0 πŸ“

Discussion: the client doesn't have to send a new SET-LINESTATE-MASK after getting a NOTIFY-LINESTATE. the LINESTATE-MASK on the access server sticks around until the client sets it again, or it gets reset at the start of a new Telnet session πŸ’œ

SET-MODEMSTATE-MASK

IAC SB COM-PORT-OPTION SET-MODEMSTATE-MASK <value> IAC SE

same energy here, but for NOTIFY-MODEMSTATE πŸ’– the client uses this to set a bit mask for sending that option (see section 4). when the MODEMSTATE changes on the access server, it does an "AND" of the new MODEMSTATE with the MODEMSTATE-MASK. if the result isn't zero, the access server sends the "AND" result as the value in a NOTIFY-MODEMSTATE com port option. if more than one bit satisfies the MODEMSTATE-MASK, only ONE NOTIFY-MODEMSTATE gets sent, with all the satisfying bits 🫧 the SET-MODEMSTATE-MASK can be any combo of the bits below. they're the same ones used in NOTIFY-MODEMSTATE, and they're based on the most popular UART (com port control chip) in use [1] 🌈

    Bit Position     Value     Meaning
       7              128        Receive Line Signal Detect
                                 (also known as Carrier Detect)
       6               64        Ring Indicator
       5               32        Data-Set-Ready Signal State
       4               16        Clear-To-Send Signal State
       3                8        Delta Receive Line Signal Detect
       2                4        Trailing-edge Ring Detector
       1                2        Delta Data-Set-Ready
       0                1        Delta Clear-To-Send

Discussion: a SET-MODEMSTATE-MASK value of 0 stops the access server from sending NOTIFY-MODEMSTATE options to the client πŸ™…β€β™€οΈ

Discussion: a SET-MODEMSTATE-MASK value of 255 lets the access server send a NOTIFY-MODEMSTATE option to the client every time the MODEMSTATE changes on it ⭐

Discussion: the initial MODEMSTATE-MASK at the access server is 255 🌟

Discussion: the client doesn't have to send a new SET-MODEMSTATE-MASK after receiving a NOTIFY-MODEMSTATE. the MODEMSTATE-MASK on the access server stays put until the client sets it, or it gets reset at the start of a new Telnet session πŸŽ€

PURGE-DATA

IAC SB COM-PORT-OPTION PURGE-DATA <value> IAC SE

the client sends this to tell the access server to IMMEDIATELY clear all the data from the buffer or buffers that the value points to 🧹 the value is one octet (byte), and it's an index into this table:

    Value      Purge Data Buffer
      0           Available for Future Use
      1           Purge access server receive data buffer
      2           Purge access server transmit data buffer
      3           Purge both the access server receive data
                    buffer and the access server transmit data
                    buffer
      4-127       Available for Future Use

4. Notification of Com port and Modem Line Changes ✨

okay this part is the access server's turn to talk πŸ—£οΈ it can send these commands to the client any time, and as many times as it likes during the Telnet session. the access server should send the right command to the client as soon as the com port or modem line change happens πŸ’… the client does NOT send a response to these, so no reply needed, bestie 🫢

NOTIFY-LINESTATE

IAC SB COM-PORT-OPTION NOTIFY-LINESTATE <value> IAC SE

the value is one octet (byte) 🧩 it's a bit level composition made from the table below. you can set multiple bit values in one transmission, and they're based on the most popular UART (com port control chip) in use [1] πŸ¦‹

    Bit Position     Value     Meaning
       7              128         Time-out Error
       6               64         Transfer Shift Register Empty
       5               32         Transfer Holding Register Empty
       4               16         Break-detect Error
       3                8         Framing Error
       2                4         Parity Error
       1                2         Overrun Error
       0                1         Data Ready

Discussion: the LINESTATE is the line state of the UART on the access server πŸ’œ

NOTIFY-MODEMSTATE

IAC SB COM-PORT-OPTION NOTIFY-MODEMSTATE <value> IAC SE

the value is one octet (byte) 🌸 it's also a bit level composition from the table below, multiple bit values can go in one transmission, and it's based on the same most popular UART (com port control chip) in use [1] πŸ’–

    Bit Position     Value     Meaning
       7              128        Receive Line Signal Detect
                                 (also known as Carrier Detect)
       6               64        Ring Indicator
       5               32        Data-Set-Ready Signal State
       4               16        Clear-To-Send Signal State
       3                8        Delta Receive Line Signal Detect
       2                4        Trailing-edge Ring Detector
       1                2        Delta Data-Set-Ready
       0                1        Delta Clear-To-Send

5. Flow Control ✨

okay so the client and/or access server can send these commands whenever they want, and as many times as they need, all throughout the Telnet session πŸ’…

FLOWCONTROL-SUSPEND πŸ›‘

IAC SB COM-PORT-OPTION FLOWCONTROL-SUSPEND IAC SE

The sender of this command is requesting that the receiver suspend transmission of both data and commands until the FLOWCONTROL-RESUME is transmitted by the sender. basically a big pause button 😭

FLOWCONTROL-RESUME 🟒

IAC SB COM-PORT-OPTION FLOWCONTROL-RESUME IAC SE

The sender of this command is requesting that the receiver resume transmission of both data and commands. the unpause era has arrived πŸ¦‹

Discussion: Established Telnet sessions start out in a resume state between the client and the access server, and between the access server and the client. so there is no need to send the resume command during session initialization 🌸

Discussion: Multiple concurrent suspend commands may be sent. Secondary suspend commands can be ignored. transmission will resume once a single resume command is sent. one resume to rule them all πŸ‘‘

Discussion: the flow control option is designed to handle client to access server flow control for the Telnet session. this option was added in deference to RFC 1372: Telnet Remote Flow Control Option [2]. RFC 1372 uses a simple character XON/XOFF technology to implement flow control, and that can lead to two problems. first, the flow control characters may be valid data values, which is so not it πŸ’€. second, the flow control characters may be used for end to end flow control (client application to remote dial up service). that's a whole vibe mismatch πŸ™ˆ


6. Security Considerations πŸ”

okay this section is serious bestie, but we're doing it anyway πŸ’œ there are two security issues to discuss: authentication and resetting resources.

Authentication can follow either the Kerberos authentication protocol established in RFC 1411 [3] or the SPX authentication protocol established in RFC 1412 [4].

Once the Telnet session between the client and the access server has been terminated, the access server should ensure the connection to the remote service is disconnected and the com port geometry (baud rate, data size, stop bits, parity, and flow control) is reset to a factory or administrator defined configuration. this ensures the com port is in a known state and ready to receive the next client session. it makes operations more predictable and avoids problems that might come from starting a new session with random com port configurations 🧚


7. Author's Address πŸŽ€

  Glen Clark, Software Architect
  Cisco Systems, Inc.
  170 West Tasman Drive
  San Jose, CA  96134
  USA

  EMail:      glenc@cisco.com
  WEB:        www.cisco.com

8. Reference Section πŸ“š

  • [1] Joe Campbell. C Programmer's Guide to Serial Communications, Second Edition. Indianapolis: SAMS Publishing, 1993. 213-224.
  • [2] Hedrick, C., and D. Borman, "Telnet Remote Flow Control Option", RFC 1372, Cray Research, Inc., October 1992.
  • [3] Borman, D., "Telnet Authentication: Kerberos Version 4", RFC 1411, Cray Research, Inc., January 1993.
  • [4] Alagappan, K., "Telnet Authentication: SPX", RFC 1412, Digital Equipment Corporation, January 1993.
  • [5] D. E. Comer and David Stevens. Internetworking with TCP/IP, Volume III. Prentice Hall, 1993.
  • [6] Andrew Margolis. The FAX Modem Sourcebook. John Wiley & Sons. 1995.
πŸ“¦ where this page comes from