RFC 2217
Telnet Com Port Control Option
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:
- SET-BAUDRATE
- SET-DATASIZE
- SET-PARITY
- 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
- ietf: rfc2217 1997-10
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms