[Ltsp-discuss] Serial port redirection

[Peter Astrand]

Hi. I'm trying to find a generic serial port redirection solution for a
Linux terminal server environment. I'd like a solution based on RFC2217.
I'm particularly interested in syncing Palm Pilot PDAs.

I've found these two servers:

* ser2net
* sredird

Both looks fine. Clients seems to be rare, though. C-Kermit seems to be
the only common client. However, I'd like to be able provide "virtual"
serial port devices on the terminal servers (something like
/dev/xterminals/1/ttyS0). After much searching, I've found
"cyclades-serial-client" (http://www.coker.com.au/cyclades/). This package
has a few problems, though:

* The software is hard to find.

* No public CVS repository

* Pretty much assumes you are using a Cyclades terminal server

* The author (***@coker.com.au) does not answer mail or accept patches


I've tried cyclades-serial-client both with sredird and ser2net, with some
applications, but it doesn't work very good:

sredird + cyclades-ser-cli + pilot-link
---------------------------------------
I'm able to use "pilot-xfer -l" to list a few databases, but then the
transmissions ends prematurely with errors.


ser2net + cyclades-ser-cli + pilot-link
---------------------------------------
"pilot-xfer" is unable to establish an connection. cyclades-ser-cli
complains about "Unimplemented command 1" etc. Later, it says "Buffer
overflow".


ser2net/sredird + Kermit
------------------------
Kermit has built-in RFC2217 support, but it doesn't work for me:

---
C-Kermit>set host localhost:4911
DNS Lookup... Trying 127.0.0.1... Reverse DNS Lookup... (OK)
localhost.localdomain connected on port 4911
C-Kermit>set speed 2400
localhost.localdomain:4911, 2400 bps
C-Kermit>connect
Connecting to host localhost.localdomain:4911
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
,
Communications disconnect
---

Kermit disconnects me as soon as I type any character.


Comments? Has anyone successfully used the cyclades-serial-client package
with sredird or ser2net? cyclades-serial-client is included in Debian, so
I think it's a bit strange that it has never been tried with a Linux
RFC2217 server before.

[Peter Astrand]

Post by Peter Astrand
Hi. I'm trying to find a generic serial port redirection solution for a
Linux terminal server environment. I'd like a solution based on RFC2217.
I'm particularly interested in syncing Palm Pilot PDAs.

...

Post by Peter Astrand
ser2net/sredird + Kermit
------------------------
---
C-Kermit>set host localhost:4911
DNS Lookup... Trying 127.0.0.1... Reverse DNS Lookup... (OK)
localhost.localdomain connected on port 4911
C-Kermit>set speed 2400
localhost.localdomain:4911, 2400 bps
C-Kermit>connect
Connecting to host localhost.localdomain:4911
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
,
Communications disconnect
---

Well, this was my fault: I didn't understand how Kermit worked. When using
"set carrier-watch off", things worked much better.

* BUT: When using Kermit as a RFC2217 client for transferring files with
ZMODEM, I get "Bad CRC" pretty much all the time. This happens *both* with
the sredird, ser2net and Tactical Softwares Dialout/Server for Windows.
The problem seems to go away if I transfer files without "0xff" bytes(!)
This looks like a Kermit bug to me. I'll guess I have to talk to the
Kermit folks about this.


* 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.


Some more test cases:

* minicom + cyclades-serial-client + sredird:
Works

* pilot-link + cyclades-serial-client + sredird:
Does not work (see my previous mail)

* pilot-link + cyclades-serial-client + Dialout/Server:
Works perfectly.

* photopc + cyclades-serial-client + sredird:
Does not work. I get "excessive retries".

* photopc + cyclades-serial-client + Dialout/Server:
Works perfectly.

So, the combination of sredird + cyclades-serial-client does not work
correctly.

Also, I tried running "Contract I.T. Communications Analyzer" on a Windows
machine. One physical port was connected to a Linux machine via a null
modem cable. This machine ran sredird. One virtual port was created with
Tactical Softwares Dialout software, connecting to sredird. Communications
Analyzer indicated 90% Byte Error Rate! Since cyclades-serial-client was
not involved in this test, I would say that it looks like sredird is doing
something wrong.


If *anyone* has any ideas of how to solve these problem, please let me
know. I'm starting to run out of time and patience...


(Which mailing list is best for this topic?)

[Jeffrey Altman]

Its not a Kermit bug; If you pass the socket file descriptor to an
external program
the external program must understand telnet protocol. Otherwise, it
can't send the
correct data format.

Post by Peter Astrand

Post by Peter Astrand
Hi. I'm trying to find a generic serial port redirection solution for a
Linux terminal server environment. I'd like a solution based on RFC2217.
I'm particularly interested in syncing Palm Pilot PDAs.

...

Post by Peter Astrand
ser2net/sredird + Kermit
------------------------
---
C-Kermit>set host localhost:4911
DNS Lookup... Trying 127.0.0.1... Reverse DNS Lookup... (OK)
localhost.localdomain connected on port 4911
C-Kermit>set speed 2400
localhost.localdomain:4911, 2400 bps
C-Kermit>connect
Connecting to host localhost.localdomain:4911
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
,
Communications disconnect
---

Well, this was my fault: I didn't understand how Kermit worked. When using
"set carrier-watch off", things worked much better.
* BUT: When using Kermit as a RFC2217 client for transferring files with
ZMODEM, I get "Bad CRC" pretty much all the time. This happens *both* with
the sredird, ser2net and Tactical Softwares Dialout/Server for Windows.
The problem seems to go away if I transfer files without "0xff" bytes(!)
This looks like a Kermit bug to me. I'll guess I have to talk to the
Kermit folks about this.
* 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.
Works
Does not work (see my previous mail)
Works perfectly.
Does not work. I get "excessive retries".
Works perfectly.
So, the combination of sredird + cyclades-serial-client does not work
correctly.
Also, I tried running "Contract I.T. Communications Analyzer" on a Windows
machine. One physical port was connected to a Linux machine via a null
modem cable. This machine ran sredird. One virtual port was created with
Tactical Softwares Dialout software, connecting to sredird. Communications
Analyzer indicated 90% Byte Error Rate! Since cyclades-serial-client was
not involved in this test, I would say that it looks like sredird is doing
something wrong.
If *anyone* has any ideas of how to solve these problem, please let me
know. I'm starting to run out of time and patience...
(Which mailing list is best for this topic?)

[Corey Minyard]

Post by Jeffrey Altman
Its not a Kermit bug; If you pass the socket file descriptor to an
external program
the external program must understand telnet protocol. Otherwise, it
can't send the
correct data format.

No, it *is* a kermit bug. When kermit sends an 0xff character, it needs
to escape it per the standard telnet protocol. It's obviously not doing
this.

-Corey

Post by Jeffrey Altman

Post by Peter Astrand

Post by Peter Astrand
Hi. I'm trying to find a generic serial port redirection solution for a
Linux terminal server environment. I'd like a solution based on
RFC2217. I'm particularly interested in syncing Palm Pilot PDAs.

...

Post by Peter Astrand
ser2net/sredird + Kermit
------------------------
---
C-Kermit>set host localhost:4911
DNS Lookup... Trying 127.0.0.1... Reverse DNS Lookup... (OK)
localhost.localdomain connected on port 4911
C-Kermit>set speed 2400
localhost.localdomain:4911, 2400 bps
C-Kermit>connect
Connecting to host localhost.localdomain:4911
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
,
Communications disconnect
---

Well, this was my fault: I didn't understand how Kermit worked. When
using "set carrier-watch off", things worked much better.
* BUT: When using Kermit as a RFC2217 client for transferring files with
ZMODEM, I get "Bad CRC" pretty much all the time. This happens *both* with
the sredird, ser2net and Tactical Softwares Dialout/Server for Windows.
The problem seems to go away if I transfer files without "0xff"
bytes(!) This looks like a Kermit bug to me. I'll guess I have to
talk to the
Kermit folks about this.
* 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.
Works
Does not work (see my previous mail)
Works perfectly.
Does not work. I get "excessive retries".
Works perfectly.
So, the combination of sredird + cyclades-serial-client does not work
correctly.
Also, I tried running "Contract I.T. Communications Analyzer" on a Windows
machine. One physical port was connected to a Linux machine via a null
modem cable. This machine ran sredird. One virtual port was created with
Tactical Softwares Dialout software, connecting to sredird.
Communications
Analyzer indicated 90% Byte Error Rate! Since cyclades-serial-client was
not involved in this test, I would say that it looks like sredird is doing
something wrong.
If *anyone* has any ideas of how to solve these problem, please let me
know. I'm starting to run out of time and patience...
(Which mailing list is best for this topic?)

[Jeffrey Altman]

Post by Corey Minyard

Post by Jeffrey Altman
Its not a Kermit bug; If you pass the socket file descriptor to an
external program
the external program must understand telnet protocol. Otherwise, it
can't send the
correct data format.

No, it *is* a kermit bug. When kermit sends an 0xff character, it
needs to escape it per the standard telnet protocol. It's obviously
not doing this.
-Corey

I agree, the IAC must be quoted. The problem is that when an external
protocol handler is
executed as a child process, Kermit is suspended and the child process
has complete control
over the socket file descriptor.

Kermit is not sitting between the external protocol and the host.

Some versions of sz have a command line flag to handle this situation
such that IAC (0xff) are
not sent but are instead escaped within the zmodem protocol.

Jeffrey Altman

[Corey Minyard]

Ah, I missed that. Ideally, something (i would think kermit) should sit
between the program and the socket to make it transparent. But yes, I
see what you are saying.

Thanks,

-Corey

Post by Jeffrey Altman

Post by Corey Minyard

Post by Jeffrey Altman
Its not a Kermit bug; If you pass the socket file descriptor to an
external program
the external program must understand telnet protocol. Otherwise, it
can't send the
correct data format.

No, it *is* a kermit bug. When kermit sends an 0xff character, it
needs to escape it per the standard telnet protocol. It's obviously
not doing this.
-Corey

I agree, the IAC must be quoted. The problem is that when an external
protocol handler is
executed as a child process, Kermit is suspended and the child process
has complete control
over the socket file descriptor.
Kermit is not sitting between the external protocol and the host.
Some versions of sz have a command line flag to handle this situation
such that IAC (0xff) are
not sent but are instead escaped within the zmodem protocol.
Jeffrey Altman

[Jeffrey Altman]

Ideally that would be true. However, the mechanisms for doing so are
not portable to all platforms on which C-Kermit still compiles. Please
remember that C-Kermit works on platforms that existed before "select()"
was invented.

Jeffrey Altman

Post by Corey Minyard
Ah, I missed that. Ideally, something (i would think kermit) should
sit between the program and the socket to make it transparent. But
yes, I see what you are saying.
Thanks,
-Corey

[Corey Minyard]

It would be fairly trivial to write such a program, though. You could
pass it the actual program you want, and it could make the protocol
transparent.

-Corey

Post by Jeffrey Altman
Ideally that would be true. However, the mechanisms for doing so are
not portable to all platforms on which C-Kermit still compiles.
Please remember that C-Kermit works on platforms that existed before
"select()" was invented.
Jeffrey Altman

Post by Corey Minyard
Ah, I missed that. Ideally, something (i would think kermit) should
sit between the program and the socket to make it transparent. But
yes, I see what you are saying.
Thanks,
-Corey

[Jeffrey Altman]

That would not help you. Its not simply a question of mapping escaping
the IAC. You must be prepared to process and respond to telnet option
negotiations during the file transfer. This is especially true with the
Remote Com Port option since the host is likely to be sending flow
control and signal status messages to the client.

This change really does need to be added to C-Kermit. Unfortunately, as
I am no longer employed by Columbia to work on Kermit this is very very
very low on my stack.

Jeffrey Altman

Post by Corey Minyard
It would be fairly trivial to write such a program, though. You could
pass it the actual program you want, and it could make the protocol
transparent.
-Corey

[Jeffrey Altman]

Post by Peter Astrand
* 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

[Corey Minyard]

Post by Jeffrey Altman

Post by Peter Astrand
* 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

[Jeffrey Altman]

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

Post by Corey Minyard

Post by Jeffrey Altman

Post by Peter Astrand
* 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.

[Corey Minyard]

Post by Jeffrey Altman
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.

True. But if I had been lucky and had a terminal server, I would not
have written ser2net :).

So Cisco uses a enumeration? Do you think it is possible to make them
compatible and do both in ser2net, or is it a non-issue?

Post by Jeffrey Altman
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.

Also true. It seemed silly to have it this way.

-Corey

[Jeffrey Altman]

Post by Corey Minyard

Post by Jeffrey Altman
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.

True. But if I had been lucky and had a terminal server, I would not
have written ser2net :).
So Cisco uses a enumeration? Do you think it is possible to make them
compatible and do both in ser2net, or is it a non-issue?

Clients can use heuristics to determine which should be used. Servers
must choose one; but I would make a configurable option.

(The clock is off by one day 4 hours and 12 minutes. This causes your
e-mail to get lost way down in my queue.)

[alvin]

Post by Peter Astrand

Post by Peter Astrand
Hi. I'm trying to find a generic serial port redirection solution for a
Linux terminal server environment. I'd like a solution based on RFC2217.
I'm particularly interested in syncing Palm Pilot PDAs.

...

Post by Peter Astrand
ser2net/sredird + Kermit
------------------------
---
C-Kermit>set host localhost:4911
DNS Lookup... Trying 127.0.0.1... Reverse DNS Lookup... (OK)
localhost.localdomain connected on port 4911
C-Kermit>set speed 2400
localhost.localdomain:4911, 2400 bps
C-Kermit>connect
Connecting to host localhost.localdomain:4911
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
,
Communications disconnect
---

Well, this was my fault: I didn't understand how Kermit worked. When using
"set carrier-watch off", things worked much better.
* BUT: When using Kermit as a RFC2217 client for transferring files with
ZMODEM, I get "Bad CRC" pretty much all the time. This happens *both* with
the sredird, ser2net and Tactical Softwares Dialout/Server for Windows.
The problem seems to go away if I transfer files without "0xff" bytes(!)
This looks like a Kermit bug to me. I'll guess I have to talk to the
Kermit folks about this.
* 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.
Works
Does not work (see my previous mail)
Works perfectly.
Does not work. I get "excessive retries".
Works perfectly.
So, the combination of sredird + cyclades-serial-client does not work
correctly.
Also, I tried running "Contract I.T. Communications Analyzer" on a Windows
machine. One physical port was connected to a Linux machine via a null
modem cable. This machine ran sredird. One virtual port was created with
Tactical Softwares Dialout software, connecting to sredird. Communications
Analyzer indicated 90% Byte Error Rate! Since cyclades-serial-client was
not involved in this test, I would say that it looks like sredird is doing
something wrong.
If *anyone* has any ideas of how to solve these problem, please let me
know. I'm starting to run out of time and patience...
(Which mailing list is best for this topic?)

have you taken a look at comserv. I ran it up and did a few simple tests
on my Xyplex terminal server. It did not do what I wanted and I put it
aside for later use.

http://www.bsdhome.com/comserv/

[Corey Minyard]

I've attached a ser2net patch for this. Could you try it out?

-Corey

Post by Peter Astrand
* 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.

[Peter Astrand]

have you taken a look at comserv. I ran it up and did a few simple tests
on my Xyplex terminal server. It did not do what I wanted and I put it
aside for later use.
http://www.bsdhome.com/comserv/

Also, there is a package called termpkg
(http://www.linuxlots.com/~termpkg/). The problem with all these packages
are that they only uses simple pseduo ttys. This means that
ioctls/tcsetattr syscalls won't work (at least not with Linux 2.4; I've
heard that 2.6 fixes this).

To be able to "interpret" ioctl/tcsetattr correctly, one needs to use a
LD_PRELOAD:ed library. It's not pretty, but this is the best solution I've
found for current Linux distros. cyclades-serial-client is the only
package I've found which uses this approach.