Re: Serial port redirection

[Jeffrey Altman <jaltman@columbia.edu>]

[-- Attachment #1: Type: text/plain, Size: 3333 bytes --]

The reality is RFC is experimental and not authoritative.  The only 
thing that really counts is what Cisco actually shipped in their IOS 
implementation.  Lucky me I actually have a terminal
server that implements it.  If you look at the C-Kermit sources you will 
see that the client is written to accept both values from the server.  
You will also find that Cisco does not send the baudrates as specified 
in the RFC but instead uses an enumeration.

With regards to the comment about the use of separate codes to indicate 
direction, this was written without a good understanding of the Telnet 
Option negotiation.  The reality is that there is no need for a telnet 
protocol option to have separate commands for each direction as the 
option itself must be negotiated separately in each direction.  
Therefore, there is no possibility of confusion.

Jeffrey Altman




Corey Minyard wrote:

> Jeffrey Altman wrote:
>
>> Peter Astrand wrote:
>>
>>> * ser2net is totally incompatible with cyclades-serial-client. This is
>>> because ser2net interprets RFC2217 a bit differently. sredird sends
>>> command "101" as ack for command "1", while ser2net sends "1". 
>>> RFC2217 is
>>> not very explicit about which way is most correct. The ser2net approach
>>> looks better to me, but the sredird one is probably more widely used
>>> (since Cyclades terminal server uses it, for example.) Probably, 
>>> RFC2217
>>> software needs to handle both cases.
>>>
>>>  
>>>
>> ser2net is wrong
>>
>>
> Umm, no.  Cyclades and sredird are wrong.  And it's pretty clear.  
> From RFC2217:
>
>                   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: As initially proposed, com port configuration
>               commands are only sent from the client to the access
>               server.  There is no current vision that the access
>               server would initiate the use of a com port configuration
>               command, only the notify commands. However, to allow for
>               access server initiated com port configurations different
>               command values have been established.
>
> That last sentence of the discussion says it.  The 1xx commands are 
> there to allow the access server to *initiate* com port configuration 
> changes.  Not to ack the changes.  Unless you can point me to 
> something in the manual to say that I am wrong.
>
> I am willing to change this in the spirit of keeping things 
> consistent, though.
>
> -Corey


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3427 bytes --]