Serial port redirection

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 (russell@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 Åstrand		www.thinlinc.com
Cendio			www.cendio.se
Teknikringen 3		Phone: +46-13-21 46 00
583 30 Linköping


-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 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. 
...
> 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
> ---

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?)

-- 
Peter Åstrand		www.thinlinc.com
Cendio			www.cendio.se
Teknikringen 3		Phone: +46-13-21 46 00
583 30 Linköping






-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Re: Serial port redirection

[Corey Minyard]

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

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

-Corey

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


[-- Attachment #2: ser2net-com-option.diff --]
[-- Type: text/plain, Size: 2075 bytes --]

? .libs
? Makefile
? Makefile.in
? aclocal.m4
? config.cache
? config.log
? config.status
? configure
? libtool
? ser2net
? .deps/controller.P
? .deps/dataxfer.P
? .deps/devcfg.P
? .deps/readconfig.P
? .deps/selector.P
? .deps/ser2net.P
? .deps/telnet.P
? .deps/utils.P
Index: ChangeLog
===================================================================
RCS file: /cvsroot/ser2net/ser2net/ChangeLog,v
retrieving revision 1.36
diff -u -r1.36 ChangeLog
--- ChangeLog	14 Oct 2003 20:52:13 -0000	1.36
+++ ChangeLog	4 Dec 2003 17:31:04 -0000
@@ -1,4 +1,11 @@
 
+2003-12-04  Corey Minyard <minyard@acm.org>
+
+	* dataxfer.c: Have the telnet option responses use the 1xx
+	responses to the com port control options.  I believe this is
+	wrong, but it is consistent with other products already in the
+	field.
+
 2003-10-14  Corey Minyard <minyard@acm.org>
 
 	* configure.in: Moved to version 2.0.
Index: dataxfer.c
===================================================================
RCS file: /cvsroot/ser2net/ser2net/dataxfer.c,v
retrieving revision 1.28
diff -u -r1.28 dataxfer.c
--- dataxfer.c	14 Oct 2003 20:52:13 -0000	1.28
+++ dataxfer.c	4 Dec 2003 17:31:04 -0000
@@ -2000,7 +2000,7 @@
 	}
 	get_rate_from_baud_rate(val, &val);
 	outopt[0] = 44;
-	outopt[1] = 1;
+	outopt[1] = 101;
 	*((uint32_t *) (outopt+2)) = htonl(val);
 	telnet_send_option(&port->tn_data, outopt, 6);
 	break;
@@ -2030,7 +2030,7 @@
 	    }
 	}
 	outopt[0] = 44;
-	outopt[1] = 2;
+	outopt[1] = 102;
 	outopt[2] = val;
 	telnet_send_option(&port->tn_data, outopt, 3);
 	break;
@@ -2061,7 +2061,7 @@
 		val = 1; /* NONE */
 	}
 	outopt[0] = 44;
-	outopt[1] = 3;
+	outopt[1] = 103;
 	outopt[2] = val;
 	telnet_send_option(&port->tn_data, outopt, 3);
 	break;
@@ -2088,7 +2088,7 @@
 		val = 1; /* 1 stop bit. */
 	}
 	outopt[0] = 44;
-	outopt[1] = 4;
+	outopt[1] = 104;
 	outopt[2] = val;
 	telnet_send_option(&port->tn_data, outopt, 3);
 	break;
@@ -2210,7 +2210,7 @@
 	}
 
 	outopt[0] = 44;
-	outopt[1] = 5;
+	outopt[1] = 105;
 	outopt[2] = val;
 	telnet_send_option(&port->tn_data, outopt, 3);
 	break;

Re: Serial port redirection

[Peter Astrand]

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

It's a good start, but it's not enough. cyclades-ser-cli doesn't finished 
the initialization; it seems to be waiting for ACKs for the 
SET-MODEMSTATE-MASK op. 


> >* 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 Åstrand		www.thinlinc.com
Cendio			www.cendio.se
Teknikringen 3		Phone: +46-13-21 46 00
583 30 Linköping

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Serial port redirection

[Corey Minyard]

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

My mailer screwed up, so this might be a dup.

Here's another patch, relative to 2.0 of ser2net.  Hopefully it fixes 
this problem.

-Corey

Peter Astrand wrote:

>
>> I've attached a ser2net patch for this.  Could you try it out?
>
>
> It's a good start, but it's not enough. cyclades-ser-cli doesn't 
> finished the initialization; it seems to be waiting for ACKs for the 
> SET-MODEMSTATE-MASK op.
>
>> >* 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.
>
>
>


[-- Attachment #2: ser2net.diff --]
[-- Type: text/plain, Size: 12815 bytes --]

? .libs
? Makefile
? Makefile.in
? aclocal.m4
? config.cache
? config.log
? config.status
? configure
? libtool
? ser2net
? ser2net-2.0.tar.gz
? ser2net-2.1.tar.gz
? .deps/controller.P
? .deps/dataxfer.P
? .deps/devcfg.P
? .deps/readconfig.P
? .deps/selector.P
? .deps/ser2net.P
? .deps/telnet.P
? .deps/utils.P
Index: ChangeLog
===================================================================
RCS file: /cvsroot/ser2net/ser2net/ChangeLog,v
retrieving revision 1.36
diff -u -r1.36 ChangeLog
--- ChangeLog	14 Oct 2003 20:52:13 -0000	1.36
+++ ChangeLog	5 Dec 2003 20:58:02 -0000
@@ -1,4 +1,27 @@
 
+2003-12-04  Corey Minyard <minyard@acm.org>
+
+	* dataxfer.c: Add responses for all the telnet com port
+	control commands that we handle.
+
+	* telnet.c: Fixed IAC processing in suboption to be able
+	to handle a stream of IACs properly.
+
+2003-12-04  Corey Minyard <minyard@acm.org>
+
+	* configure.in: Moved to version 2.1.
+
+	* dataxfer.c: Have the telnet option responses use the 1xx
+	responses to the com port control options.  I believe this is
+	wrong, but it is consistent with other products already in the
+	field.
+
+	* dataxfer.c, ser2net.c, telnet.h: Added support for setting the
+	use of Cisco IOS baud rates instead of RFC 2217 ones, by command
+	option.
+
+	* selector.c, ser2net.c: Cleaned up some compile warnings.
+	
 2003-10-14  Corey Minyard <minyard@acm.org>
 
 	* configure.in: Moved to version 2.0.
Index: configure.in
===================================================================
RCS file: /cvsroot/ser2net/ser2net/configure.in,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- configure.in	14 Oct 2003 15:29:39 -0000	1.16
+++ configure.in	5 Dec 2003 15:19:41 -0000	1.17
@@ -1,5 +1,5 @@
 AC_INIT(ser2net.c)
-AM_INIT_AUTOMAKE(ser2net, 2.0)
+AM_INIT_AUTOMAKE(ser2net, 2.1)
 AC_PROG_CC
 AM_PROG_LIBTOOL
 AC_ARG_WITH(uucp-locking,
Index: controller.c
===================================================================
RCS file: /cvsroot/ser2net/ser2net/controller.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- controller.c	14 Oct 2003 15:29:39 -0000	1.15
+++ controller.c	5 Dec 2003 15:17:55 -0000	1.16
@@ -17,7 +17,6 @@
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
-#include <termios.h>
 #include <sys/types.h>
 #include <sys/time.h>
 #include <sys/socket.h>
Index: dataxfer.c
===================================================================
RCS file: /cvsroot/ser2net/ser2net/dataxfer.c,v
retrieving revision 1.28
diff -u -r1.28 dataxfer.c
--- dataxfer.c	14 Oct 2003 20:52:13 -0000	1.28
+++ dataxfer.c	5 Dec 2003 20:58:05 -0000
@@ -1878,26 +1878,30 @@
 static struct baud_rates_s {
     int real_rate;
     int val;
+    int cisco_ios_val;
 } baud_rates[] =
 {
-    { 50, B50 },
-    { 75, B75 },
-    { 110, B110 },
-    { 134, B134 },
-    { 150, B150 },
-    { 200, B200 },
-    { 300, B300 },
-    { 600, B600 },
-    { 1200, B1200 },
-    { 1800, B1800 },
-    { 2400, B2400 },
-    { 4800, B4800 },
-    { 9600, B9600 },
-    { 19200, B19200 },
-    { 38400, B38400 },
-    { 57600, B57600 },
-    { 115200, B115200 },
-    { 230400, B230400 },
+    { 50, B50, -1 },
+    { 75, B75, -1 },
+    { 110, B110, -1 },
+    { 134, B134, -1 },
+    { 150, B150, -1 },
+    { 200, B200, -1 },
+    { 300, B300, 3 },
+    { 600, B600 , 4},
+    { 1200, B1200, 5 },
+    { 1800, B1800, -1 },
+    { 2400, B2400, 6 },
+    { 4800, B4800, 7 },
+    { 9600, B9600, 8 },
+    /* We don't support 14400 baud */
+    { 19200, B19200, 10 },
+    /* We don't support 28800 baud */
+    { 38400, B38400, 12 },
+    { 57600, B57600, 13 },
+    { 115200, B115200, 14 },
+    { 230400, B230400, 15 },
+    /* We don't support 460800 baud */
 };
 #define BAUD_RATES_LEN ((sizeof(baud_rates) / sizeof(struct baud_rates_s)))
 
@@ -1906,9 +1910,16 @@
 {
     int i;
     for (i=0; i<BAUD_RATES_LEN; i++) {
-	if (rate == baud_rates[i].real_rate) {
-	    *val = baud_rates[i].val;
-	    return 1;
+	if (cisco_ios_baud_rates) {
+	    if (rate == baud_rates[i].cisco_ios_val) {
+		*val = baud_rates[i].val;
+		return 1;
+	    }
+	} else {
+	    if (rate == baud_rates[i].real_rate) {
+		*val = baud_rates[i].val;
+		return 1;
+	    }
 	}
     }
 
@@ -1921,7 +1932,16 @@
     int i;
     for (i=0; i<BAUD_RATES_LEN; i++) {
 	if (baud_rate == baud_rates[i].val) {
-	    *val = baud_rates[i].real_rate;
+	    if (cisco_ios_baud_rates) {
+		if (baud_rates[i].cisco_ios_val < 0)
+		    /* We are at a baud rate unsopported by the
+		       enumeration, just return zero. */
+		    *val = 0;
+		else
+		    *val = baud_rates[i].cisco_ios_val;
+	    } else {
+		*val = baud_rates[i].real_rate;
+	    }
 	    return;
 	}
     }
@@ -1983,12 +2003,17 @@
 	break;
 
     case 1: /* SET-BAUDRATE */
-	if (len < 6)
-	    return;
+	if (cisco_ios_baud_rates) {
+	    if (len < 3)
+		return;
+	    val = option[2];
+	} else {
+	    if (len < 6)
+		return;
+	    val = ntohl(*((uint32_t *) (option+2)));
+	}
 
-	val = 0;
 	if (tcgetattr(port->devfd, &termio) != -1) {
-	    val = ntohl(*((uint32_t *) (option+2)));
 	    if ((val != 0) && (get_baud_rate(val, &val))) {
 		/* We have a valid baud rate. */
 		cfsetispeed(&termio, val);
@@ -1997,12 +2022,19 @@
 	    }
 	    tcgetattr(port->devfd, &termio);
 	    val = cfgetispeed(&termio);
+	} else {
+	    val = 0;
 	}
 	get_rate_from_baud_rate(val, &val);
 	outopt[0] = 44;
-	outopt[1] = 1;
-	*((uint32_t *) (outopt+2)) = htonl(val);
-	telnet_send_option(&port->tn_data, outopt, 6);
+	outopt[1] = 101;
+	if (cisco_ios_baud_rates) {
+	    outopt[2] = val;
+	    telnet_send_option(&port->tn_data, outopt, 3);
+	} else {
+	    *((uint32_t *) (outopt+2)) = htonl(val);
+	    telnet_send_option(&port->tn_data, outopt, 6);
+	}
 	break;
 
     case 2: /* SET-DATASIZE */
@@ -2030,7 +2062,7 @@
 	    }
 	}
 	outopt[0] = 44;
-	outopt[1] = 2;
+	outopt[1] = 102;
 	outopt[2] = val;
 	telnet_send_option(&port->tn_data, outopt, 3);
 	break;
@@ -2061,7 +2093,7 @@
 		val = 1; /* NONE */
 	}
 	outopt[0] = 44;
-	outopt[1] = 3;
+	outopt[1] = 103;
 	outopt[2] = val;
 	telnet_send_option(&port->tn_data, outopt, 3);
 	break;
@@ -2088,7 +2120,7 @@
 		val = 1; /* 1 stop bit. */
 	}
 	outopt[0] = 44;
-	outopt[1] = 4;
+	outopt[1] = 104;
 	outopt[2] = val;
 	telnet_send_option(&port->tn_data, outopt, 3);
 	break;
@@ -2210,29 +2242,43 @@
 	}
 
 	outopt[0] = 44;
-	outopt[1] = 5;
+	outopt[1] = 105;
 	outopt[2] = val;
 	telnet_send_option(&port->tn_data, outopt, 3);
 	break;
 
     case 8: /* FLOWCONTROL-SUSPEND */
 	tcflow(port->devfd, TCIOFF);
+	outopt[0] = 44;
+	outopt[1] = 108;
+	telnet_send_option(&port->tn_data, outopt, 2);
 	break;
 
     case 9: /* FLOWCONTROL-RESUME */
 	tcflow(port->devfd, TCION);
+	outopt[0] = 44;
+	outopt[1] = 109;
+	telnet_send_option(&port->tn_data, outopt, 2);
 	break;
 
     case 10: /* SET-LINESTATE-MASK */
 	if (len < 3)
 	    return;
 	port->linestate_mask = option[2];
+	outopt[0] = 44;
+	outopt[1] = 110;
+	outopt[2] = port->linestate_mask;
+	telnet_send_option(&port->tn_data, outopt, 3);
 	break;
 
     case 11: /* SET-MODEMSTATE-MASK */
 	if (len < 3)
 	    return;
 	port->modemstate_mask = option[2];
+	outopt[0] = 44;
+	outopt[1] = 111;
+	outopt[2] = port->modemstate_mask;
+	telnet_send_option(&port->tn_data, outopt, 3);
 	break;
 
     case 12: /* PURGE_DATA */
@@ -2247,6 +2293,10 @@
 	break;
     purge_found:
 	tcflush(port->devfd, val);
+	outopt[0] = 44;
+	outopt[1] = 112;
+	outopt[2] = option[2];
+	telnet_send_option(&port->tn_data, outopt, 3);
 	break;
 
     case 6: /* NOTIFY-LINESTATE */
Index: selector.c
===================================================================
RCS file: /cvsroot/ser2net/ser2net/selector.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- selector.c	22 Apr 2003 12:36:51 -0000	1.8
+++ selector.c	5 Dec 2003 14:00:10 -0000	1.9
@@ -548,6 +548,7 @@
 	left = elem->left;
     }
 done:
+    return;
 }
 
 static void
@@ -586,6 +587,7 @@
     print_tree(*top, *last);
     check_tree(*top, *last);
 #endif
+    return;
 }
 
 static void
@@ -662,6 +664,7 @@
     print_tree(*top, *last);
     check_tree(*top, *last);
 #endif
+    return;
 }
 
 int
Index: ser2net.8
===================================================================
RCS file: /cvsroot/ser2net/ser2net/ser2net.8,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ser2net.8	14 Oct 2003 20:52:13 -0000	1.11
+++ ser2net.8	5 Dec 2003 14:00:10 -0000	1.12
@@ -36,6 +36,11 @@
 .I \-u
 If UUCP locking is enabled, this will disable the use of UUCP locks.
 .TP
+.I \-b
+Cisco IOS uses a different mechanism for specifying the baud rates
+than the mechanism described in RFC2217.  This option sets the IOS
+version of setting the baud rates.  The default is RFC2217's.
+.TP
 .I \-v
 Prints the version of the program and exits.
 .TP
Index: ser2net.c
===================================================================
RCS file: /cvsroot/ser2net/ser2net/ser2net.c,v
retrieving revision 1.10
diff -u -r1.10 ser2net.c
--- ser2net.c	4 Dec 2002 21:15:26 -0000	1.10
+++ ser2net.c	5 Dec 2003 20:58:05 -0000
@@ -22,12 +22,12 @@
 
 /* TODO
  *
- * Add getty support and UUCP locking
  * Add some type of security
  */
 
 #include <stdio.h>
 #include <signal.h>
+#include <stdlib.h>
 #include <string.h>
 #include <syslog.h>
 #include <sys/types.h>
@@ -46,6 +46,7 @@
 #ifdef USE_UUCP_LOCKING
 int uucp_locking_enabled = 1;
 #endif
+int cisco_ios_baud_rates = 0;
 
 selector_t *ser2net_sel;
 
@@ -58,6 +59,7 @@
 #ifdef USE_UUCP_LOCKING
 "  -u - Disable UUCP locking\n"
 #endif
+"  -b - Do CISCO IOS baud-rate negotiation, instead of RFC2217\n"
 "  -v - print the program's version and exit\n";
 
 void
@@ -96,6 +98,10 @@
 	    debug = 1;
 	    break;
 
+	case 'b':
+	    cisco_ios_baud_rates = 1;
+	    break;
+
 	case 'c':
 	    /* Get a config file. */
 	    i++;
@@ -156,6 +162,7 @@
 
 	/* Detach from the calling terminal. */
 	openlog("ser2net", LOG_PID | LOG_CONS, LOG_DAEMON);
+	syslog(LOG_NOTICE, "ser2net startup");
 	if ((pid = fork()) > 0) {
 	    exit(0);
 	} else if (pid < 0) {
Index: ser2net.spec
===================================================================
RCS file: /cvsroot/ser2net/ser2net/ser2net.spec,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ser2net.spec	5 Dec 2003 14:01:01 -0000	1.11
+++ ser2net.spec	5 Dec 2003 15:19:41 -0000	1.12
@@ -1,5 +1,5 @@
 Name:		ser2net
-Version:	2.0
+Version:	2.1
 Release:	1
 License:	GPL
 Summary:	Serial to network proxy
@@ -38,6 +38,8 @@
 
 
 %changelog
+* Tue Dec  5 2003 Corey Minyard <minyard@acm.org>
+- Moved to version 2.1.
 * Tue Oct 14 2003 Corey Minyard <minyard@acm.org>
 - Moved to version 2.0.
 * Tue Apr 22 2003 Corey Minyard <minyard@acm.org>
Index: telnet.c
===================================================================
RCS file: /cvsroot/ser2net/ser2net/telnet.c,v
retrieving revision 1.2
diff -u -r1.2 telnet.c
--- telnet.c	14 Oct 2003 16:09:43 -0000	1.2
+++ telnet.c	5 Dec 2003 20:58:05 -0000
@@ -205,7 +205,7 @@
 		}
 	    } else {
 		/* It's in a suboption, look for the end and IACs. */
-		if (td->telnet_cmd[td->telnet_cmd_pos-1] == 255) {
+	      if (td->suboption_iac) {
 		    if (tn_byte == 240) {
 			/* Remove the IAC 240 from the end. */
 			td->telnet_cmd_pos--;
@@ -219,6 +219,7 @@
 			   character, delete them both */
 			td->telnet_cmd_pos--;
 		    }
+		    td->suboption_iac = 0;
 		} else {
 		    if (td->telnet_cmd_pos > MAX_TELNET_CMD_SIZE)
 			/* Always store the last character
@@ -230,12 +231,15 @@
 	  
 		    td->telnet_cmd[td->telnet_cmd_pos] = tn_byte;
 		    td->telnet_cmd_pos++;
+		    if (tn_byte == 255)
+		      td->suboption_iac = 1;
 		}
 	    }
 	} else if (data[i] == 255) {
 	    td->telnet_cmd[td->telnet_cmd_pos] = 255;
 	    len = delete_char(data, i, len);
 	    td->telnet_cmd_pos++;
+	    td->suboption_iac = 0;
 	} else {
 	    i++;
 	}
Index: telnet.h
===================================================================
RCS file: /cvsroot/ser2net/ser2net/telnet.h,v
retrieving revision 1.2
diff -u -r1.2 telnet.h
--- telnet.h	14 Oct 2003 16:09:43 -0000	1.2
+++ telnet.h	5 Dec 2003 20:58:05 -0000
@@ -52,6 +52,9 @@
 					   telnet_cmd buffer.  If zero,
 					   no telnet command is in
 					   progress. */
+    int            suboption_iac;	/* If true, we are in a
+					   suboption and processing an
+					   IAC. */
 
     /* Outgoing telnet commands.  The output routines should look at
        this *first* to see if they should transmit some data from
@@ -96,5 +99,9 @@
 		 struct telnet_cmd *cmds,
 		 unsigned char *init_seq,
 		 int init_seq_len);
+
+/* Set to true if we are supposed to do CISCO IOS baud rates instead
+   of RFC2217 ones. */
+extern int cisco_ios_baud_rates;
 
 #endif /* _SER2NET_TELNET_H */

Re: Serial port redirection

[Peter Astrand]

> Here's another patch, relative to 2.0 of ser2net.  Hopefully it fixes 
> this problem.

I've tried the latest CVS now. It works better: cyclades-ser-cli now 
initializes correctly. However, I'm not able to sync with pilot-xfer: 
pilot-xfer does not detect when I'm pressing the sync button. With 
sredird, this works (but the communication stops after listing four 
databases.)


-- 
Peter Åstrand		www.thinlinc.com
Cendio			www.cendio.se
Teknikringen 3		Phone: +46-13-21 46 00
583 30 Linköping

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Serial port redirection

[Peter Astrand]

> > Here's another patch, relative to 2.0 of ser2net.  Hopefully it fixes 
> > this problem.
> 
> I've tried the latest CVS now. It works better: cyclades-ser-cli now 
> initializes correctly. However, I'm not able to sync with pilot-xfer: 
> pilot-xfer does not detect when I'm pressing the sync button. With 
> sredird, this works (but the communication stops after listing four 
> databases.)

I've tested photopc as well, with cyclades-ser-cli:

* With sredird, commands like "query" works, but "list" fails. 

* With ser2net, "query" fails after getting the first parameter. 


-- 
Peter Åstrand		www.thinlinc.com
Cendio			www.cendio.se
Teknikringen 3		Phone: +46-13-21 46 00
583 30 Linköping


-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Serial port redirection

[Jeffrey Altman]

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

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.



Peter Astrand wrote:

>>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. 
>>    
>>
>...
>  
>
>>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
>>---
>>    
>>
>
>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?)
>
>  
>

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

Re: Serial port redirection

[Corey Minyard]

Jeffrey Altman wrote:

> 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

>
>
>
>
> Peter Astrand wrote:
>
>>> 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.   
>>
>> ...
>>  
>>
>>> 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
>>> ---
>>>   
>>
>>
>> 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?)
>>
>>  
>>




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Re: Serial port redirection

[Jeffrey Altman]

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

Corey Minyard wrote:

> Jeffrey Altman wrote:
>
>> 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



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

Re: Serial port redirection

[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 wrote:

> Corey Minyard wrote:
>
>> Jeffrey Altman wrote:
>>
>>> 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
>
>




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Re: Serial port redirection

[Jeffrey Altman]

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

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


Corey Minyard wrote:

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

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

Re: Serial port redirection

[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 wrote:

> 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
>
>
> Corey Minyard wrote:
>
>> 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
>>

Re: Serial port redirection

[Jeffrey Altman]

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

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


Corey Minyard wrote:

> 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


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

Re: Serial port redirection

[Jeffrey Altman]

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

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



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

Re: Serial port redirection

[Corey Minyard]

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

Re: Serial port redirection

[Jeffrey Altman]

[-- 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 --]

Re: Serial port redirection

[Corey Minyard]

Jeffrey Altman wrote:

> 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?

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



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Re: Serial port redirection

[Jeffrey Altman]

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

Corey Minyard wrote:

> Jeffrey Altman wrote:
>
>> 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.)



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

Re: Serial port redirection

[Peter Astrand]

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

Perhaps we should make a new, updated RFC? It could include this vital 
information, as well as give advice on how to handle the different cases. 


-- 
Peter Åstrand		www.thinlinc.com
Cendio			www.cendio.se
Teknikringen 3		Phone: +46-13-21 46 00
583 30 Linköping

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Serial port redirection

[Jeffrey Altman]

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

Peter Astrand wrote:

>>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.
>>    
>>
>
>Perhaps we should make a new, updated RFC? It could include this vital 
>information, as well as give advice on how to handle the different cases. 
>  
>

I am willing to do so.  I have a list of other Telnet RFCs which need to 
be updated.  Unfortunately, the IETF has very little interest these days 
in updating the Telnet
protocol.  Now that SSH is around the feeling is that Telnet should fade 
away
and people who want this type of functionality should implement a new 
protocol
on top of SSH. 



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

Re: Serial port redirection

[Peter Astrand]

On Fri, 5 Dec 2003, Jeffrey Altman wrote:

> >Perhaps we should make a new, updated RFC? It could include this vital 
> >information, as well as give advice on how to handle the different cases. 
> >  
> >
> 
> I am willing to do so.  I have a list of other Telnet RFCs which need to
> be updated.  Unfortunately, the IETF has very little interest these days
> in updating the Telnet protocol.  Now that SSH is around the feeling is
> that Telnet should fade away and people who want this type of
> functionality should implement a new protocol on top of SSH.

Actually, we are using telnet+RFC2217 over an SSH TCP tunnel. I think this 
is a pretty clean solution. How could a "better" solution look like?


-- 
Peter Åstrand		www.thinlinc.com
Cendio			www.cendio.se
Teknikringen 3		Phone: +46-13-21 46 00
583 30 Linköping

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Serial port redirection

[Jeffrey Altman]

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

Peter Astrand wrote:

>Actually, we are using telnet+RFC2217 over an SSH TCP tunnel. I think this 
>is a pretty clean solution. How could a "better" solution look like?
>  
>
Two better solutions:

 * TELNET START_TLS + AUTH {SRP, KRB5} + RFC2217

 * SSH + a Remote Serial Port subsystem (yet to be built)




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

Re: Serial port redirection

[Peter Astrand]

> >Actually, we are using telnet+RFC2217 over an SSH TCP tunnel. I think this 
> >is a pretty clean solution. How could a "better" solution look like?
> >  
> >
> Two better solutions:
> 
>  * TELNET START_TLS + AUTH {SRP, KRB5} + RFC2217

But the START_TLS and auth stuff has nothing to do with RFC2217. It's just 
a matter of using several Telnet options at the same time. 


>  * SSH + a Remote Serial Port subsystem (yet to be built)

SSH subsystems are nothing magic: The subsystem process communicates with
sshd via stdin/stdout, just like inetd. For example, the "SSH File
Transfer Protocol" RFC says:

  Even though this protocol is described in the context of the SSH2
  protocol, this protocol is general and independent of the rest of the
  SSH2 protocol suite.

So, the question is, telnet+RFC2217 a "bad" or inappropriate protocol to 
be used with a SSH subsystem? I think not. 


Since sredird is a inetd-type service, it can actually work as a 
subsystem. It works, I've just tested it. Here's what I did:

* Created /tmp/sredir-sshsub:

#!/bin/sh
exec /tmp/sredird 5 /dev/ttyS0 /tmp/LCK..ttyS0


* Added to sshd_config:

Subsystem       sredir  /tmp/sredir-sshsub


* Used ssh and socat to connect:

socat TCP-LISTEN:5555 "EXEC:ssh -s localhost sredir"


* Connected with Kermit:

(/home/peter/) C-Kermit>set host localhost:5555
 DNS Lookup...  Trying 127.0.0.1...  Reverse DNS Lookup... (OK)
 localhost.localdomain connected on port 5555
 Negotiations.. (OK)


So, I think telnet+RFC2217 is a good protocol, even in a SSH environment. 
Thus, it would be useful with an updated spec. 

What remains is perhaps convincing IETF of this. Or, maybe not: We could 
just go ahead and update the spec. 


-- 
Peter Åstrand		www.thinlinc.com
Cendio			www.cendio.se
Teknikringen 3		Phone: +46-13-21 46 00
583 30 Linköping


-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html