From cross+conserver@distal.com Sun Dec 2 19:25:18 2007 Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by underdog.stansell.org (8.14.1/8.14.1) with ESMTP id lB33P88E002298 for ; Sun, 2 Dec 2007 19:25:13 -0800 (PST) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA10.westchester.pa.mail.comcast.net with comcast id L3Js1Y00J1HzFnQ0500q00; Mon, 03 Dec 2007 03:25:07 +0000 Received: from mail.distal.com ([69.244.75.197]) by OMTA14.westchester.pa.mail.comcast.net with comcast id L3R51Y00G4FQVEl0300000; Mon, 03 Dec 2007 03:25:07 +0000 X-Authority-Analysis: v=1.0 c=1 a=ytUvyDOX-ssA:10 a=7eSIOHLcp7riwiBFkGQA:9 a=bOCLpTVomE6615hCXeP0i_SnwngA:4 a=WuK_CZDBSqoA:10 Received: from [IPv6:2001:5c0:956b:20:214:51ff:fe65:d77e] (magrathea.distal.com [IPv6:2001:5c0:956b:20:214:51ff:fe65:d77e]) (authenticated bits=0) by mail.distal.com (8.14.1/8.14.1) with ESMTP id lB33P3XZ028366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Dec 2007 22:25:05 -0500 (EST) In-Reply-To: <20071118210322.GA448@underdog.stansell.org> References: <20071118210322.GA448@underdog.stansell.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chris Ross Subject: Re: To ask a familiar question: auto-login of console connections Date: Sun, 2 Dec 2007 22:25:45 -0500 To: Bryan Stansell X-Mailer: Apple Mail (2.752.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.distal.com [IPv6:2001:5c0:956b:20::ae25]); Sun, 02 Dec 2007 22:25:05 -0500 (EST) X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 209.182.219.30 Cc: Conserver Users's Mailing List X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2007 03:25:19 -0000 On Nov 18, 2007, at 16:03, Bryan Stansell wrote: > that's exactly what will happen if you add the initcmd stuff to your > console definition (or what it inherits). it works for all types of > consoles. conserver will make the initial tcp connection, then > fork off > the initcmd (pointing it's stdin/stdout to that file descriptor) > and then > continue to do it's normal stuff when it exits. Alright. I've finally gotten a couple hours to work on this. I started by working with perl's Expect.pm, but since I'm not all that familiar with it, I eventually gave up because I couldn't get it to work. It would work alright if I used Expect->spawn("telnet A.B.C.D NN"), but I never could get it to work with STDIN and STDOUT, the way it should work when run as an initcmd. So, I dropped back to plain boring perl. I'm just reading lines from STDIN, and when I see the prompts I want, I'm printing things to STDOUT. However, it doesn't seem to be working. As far as I can tell, the things I print to STDOUT aren't getting passed across the socket (in this case, a connection "type host") Do you have any suggestions of useful ways to get debugging information out of the conserver process about the I/O of the initcmd, et al? Thanks... - Chris From cross+conserver@distal.com Sun Dec 2 20:31:28 2007 Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by underdog.stansell.org (8.14.1/8.14.1) with ESMTP id lB34VL40002887 for ; Sun, 2 Dec 2007 20:31:26 -0800 (PST) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id L3Vg1Y00A0S2fkC0A02s00; Mon, 03 Dec 2007 04:31:26 +0000 Received: from mail.distal.com ([69.244.75.197]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id L4XP1Y00J4FQVEl0800000; Mon, 03 Dec 2007 04:31:25 +0000 X-Authority-Analysis: v=1.0 c=1 a=ytUvyDOX-ssA:10 a=1_JYQeDQQkgkPRXtZcsA:9 a=waeS4gzhMaaCD4tbINEXWcq1uesA:4 a=WuK_CZDBSqoA:10 Received: from [IPv6:2001:5c0:956b:20:214:51ff:fe65:d77e] (magrathea.distal.com [IPv6:2001:5c0:956b:20:214:51ff:fe65:d77e]) (authenticated bits=0) by mail.distal.com (8.14.1/8.14.1) with ESMTP id lB34VGHO006505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Dec 2007 23:31:18 -0500 (EST) In-Reply-To: References: <20071118210322.GA448@underdog.stansell.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chris Ross Subject: Re: To ask a familiar question: auto-login of console connections Date: Sun, 2 Dec 2007 23:31:59 -0500 To: Bryan Stansell X-Mailer: Apple Mail (2.752.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.distal.com [IPv6:2001:5c0:956b:20::ae25]); Sun, 02 Dec 2007 23:31:18 -0500 (EST) X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 209.182.219.30 Cc: Conserver Users's Mailing List X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2007 04:31:29 -0000 On Dec 2, 2007, at 22:25, Chris Ross wrote: > So, I dropped back to plain boring perl. I'm just reading > lines from STDIN, and when I see the prompts I want, I'm > printing things to STDOUT. However, it doesn't seem to be > working. As far as I can tell, the things I print to STDOUT > aren't getting passed across the socket (in this case, a > connection "type host") Okay. I'm not totally sure what happened. I think it was a buffering problem. I think I was buffering the output, and it wasn't getting sent. I tripped across fixing it, and now have it working using select, sysread, and syswrite. Someday, I may get back to trying to use Expect to do it in what is likely a more "right way," but. Thanks for the pointer that it could be done! - Chris From perlch@bluewin.ch Sat Dec 8 08:32:11 2007 Received: from mail19.bluewin.ch (mail19.bluewin.ch [195.186.18.65]) by underdog.stansell.org (8.14.1/8.14.1) with ESMTP id lB8GW4uk023752 for ; Sat, 8 Dec 2007 08:32:10 -0800 (PST) Received: from [192.168.1.33] (81.62.208.108) by mail19.bluewin.ch (Bluewin 7.3.121) id 471B450000D09AE4 for users@conserver.com; Sat, 8 Dec 2007 16:32:03 +0000 Message-ID: <475AC703.50802@bluewin.ch> Date: Sat, 08 Dec 2007 17:32:03 +0100 From: perlch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: users@conserver.com Subject: Line send delay Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 209.182.219.30 X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2007 16:32:12 -0000 Hi all Is it possible to set a "send line delay" on conserver. This option allows the user to set the number of milliseconds that conserver pauses after sending a carriage return. I have problem, if I want do configure a cisco router, because in some cases(commands) I must wait 250ms. Any help is appreciated, Martin From stoffj@taec.toshiba.com Thu Dec 13 10:42:20 2007 Received: from mailhost.taec.toshiba.com (mailhost.taec.toshiba.com [209.243.128.33]) by underdog.stansell.org (8.14.1/8.14.1) with ESMTP id lBDIgDoP007272 for ; Thu, 13 Dec 2007 10:42:19 -0800 (PST) Received: from localhost.localdomain (IDENT:U2FsdGVkX1+6wYgH9jA/nojEXgdqC+QvrK4FL2nopIc@sekrit.taec.toshiba.com [209.243.166.44]) by mailhost.taec.toshiba.com (8.12.7/8.12.7) with ESMTP id lBDIg7P2021102; Thu, 13 Dec 2007 10:42:08 -0800 (PST) Received: from localhost.localdomain (sekrit [127.0.0.1]) by localhost.localdomain (8.13.1/8.12.11) with ESMTP id lBDIg8Wc014664; Thu, 13 Dec 2007 13:42:08 -0500 Received: (from stoffj@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id lBDIfwlI014660; Thu, 13 Dec 2007 13:41:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18273.31990.541979.173023@gargle.gargle.HOWL> Date: Thu, 13 Dec 2007 13:41:58 -0500 From: "John Stoffel" To: perlch Subject: Re: Line send delay In-Reply-To: <475AC703.50802@bluewin.ch> References: <475AC703.50802@bluewin.ch> X-Mailer: VM 7.19 under Emacs 22.1.2 X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 209.182.219.30 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 18:42:21 -0000 perlch> Is it possible to set a "send line delay" on conserver. I don't think so. perlch> This option allows the user to set the number of milliseconds perlch> that conserver pauses after sending a carriage return. This should be more of an issue with your terminal than with conserver. perlch> I have problem, if I want do configure a cisco router, because perlch> in some cases(commands) I must wait 250ms. This is news to me. what exactly happens if you don't wait? And what happens if you use a direct serial connection to the router and configure it? More details please. John From david.k.harris@siemens.com Thu Dec 13 16:05:41 2007 Received: from usnwk220srv.usa.siemens.com (usnwksmtp02e.usa.siemens.com [12.46.135.31]) by underdog.stansell.org (8.14.1/8.14.1) with ESMTP id lBE05Wvo010043 for ; Thu, 13 Dec 2007 16:05:38 -0800 (PST) Received: from usnwk206a.ww017.siemens.net ([155.45.111.74]) by usnwk220srv.usa.siemens.com with InterScan Messaging Security Suite; Thu, 13 Dec 2007 16:05:34 -0800 Received: from USNWK102MSX.ww017.siemens.net ([155.45.111.56]) by usnwk206a.ww017.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Dec 2007 16:05:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Line send delay (I've seen the problem) Date: Thu, 13 Dec 2007 16:05:29 -0800 Message-ID: <2461A50AD2345646B1C4B3D7BA40B8E2037CB5C4@USNWK102MSX.ww017.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Line send delay (I've seen the problem) Thread-Index: Acg90CZHYnPx9VvwR+SKZJCX6igD/gACrwegAAKGSmA= From: "Harris, David (IT Solutions US)" To: X-OriginalArrivalTime: 14 Dec 2007 00:05:30.0540 (UTC) FILETIME=[0A0BA6C0:01C83DE5] X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 209.182.219.30 X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 00:05:42 -0000 I agree with John, that problem should be mitigated by the controlling (script-sending) host. But, it would be nice if there were a way to tell a Console Server port to slow the outbound traffic (from the console server to the attached serial console), so that many different admins using different clients wouldn't all have to learn how to solve this problem individually. Of course, the inbound traffic (from the serial attached console to the console server) should not be 'paced', as that would reduce the capacity of how much you could log in a given time window. So far, I can't find a way to do this on the console servers. I guess this is another 'feature request' to be considered by the Console Server manufacturers... and they'll only add it if we (their customers) ask for it. Even if you don't need it today, you might need it later. ;-) Best regards, -Z- David 'Zonker' Harris Silicon Valley Service Delivery Center, Network Operations Siemens IT Solutions and Services, Inc.=20 Infrastructure Management Services 39600 Eureka Drive Newark, CA 94560 Tel: 510 624-5524 Fax: 510 624-5508 mailto: david.k.harris@siemens.com=20 www.usa.siemens.com/it-solutions =20 -----Original Message----- From: John.Stoffel@taec.toshiba.com [mailto:John.Stoffel@taec.toshiba.com]=20 Sent: Thursday, December 13, 2007 1:35 PM To: Harris, David (IT Solutions US) Subject: Re: Line send delay (I've seen the problem) In this situation you should then use expect to do your cisco programming, even if yopu use conserver as the transport. =20 Fixing it at the conserver level is using a wrench for a soldering gun! John ----- Original Message ----- From: "Harris, David (IT Solutions US)" [david.k.harris@siemens.com] Sent: 12/13/2007 11:28 AM PST To: John Stoffel Subject: RE: Line send delay (I've seen the problem) I have seen this, especially with older Cisco gear, but also with current gear on 'some' commands. The problem is that the Cisco device needs time to 'think' for some of the commands (setting up internal tables, parsing Access Control List commands into a firewall fabric, etc.)... If you throw the next lines in before the device has finished thinking, it misses your command, or it misses some characters. The Cisco doesn't seem to buffer all the input, so that's the root of the problem... when the system thinks, it seems to not buffer the next characters until its ready to listen again. (I haven't looked to see if they invoke hardware or software flow control when you are pasting in a bunch of lines like that.) The symptom is that the configs don't paste well (the same symptoms occur when you do an ASCII upload of a config script). The 'field fix' includes pacing the lines (wait after each carriage return), or adding an extra linefeed or two (padded with space characters) after the problem commands in your scripts. But the problem remains on Cisco gear even with current versions, which is why Cisco can sell their configuration tools for Big Bucks. ;-) -Z- David 'Zonker' Harris Silicon Valley Service Delivery Center, Network Operations Siemens IT Solutions and Services, Inc.=20 Infrastructure Management Services 39600 Eureka Drive Newark, CA 94560 Tel: 510 624-5524 Fax: 510 624-5508 mailto: david.k.harris@siemens.com=20 www.usa.siemens.com/it-solutions =20 -----Original Message----- From: users-bounces@conserver.com [mailto:users-bounces@conserver.com] On Behalf Of John Stoffel Sent: Thursday, December 13, 2007 10:42 AM To: perlch Cc: users@conserver.com Subject: Re: Line send delay perlch> Is it possible to set a "send line delay" on conserver. I don't think so. perlch> This option allows the user to set the number of milliseconds perlch> that conserver pauses after sending a carriage return. This should be more of an issue with your terminal than with conserver. perlch> I have problem, if I want do configure a cisco router, because perlch> in some cases(commands) I must wait 250ms. This is news to me. what exactly happens if you don't wait? And what happens if you use a direct serial connection to the router and configure it? More details please. John _______________________________________________ users mailing list users@conserver.com https://www.conserver.com/mailman/listinfo/users From stoffj@taec.toshiba.com Fri Dec 14 07:35:54 2007 Received: from mailhost.taec.toshiba.com (mailhost.taec.toshiba.com [209.243.128.33]) by underdog.stansell.org (8.14.1/8.14.1) with ESMTP id lBEFZkLb027691 for ; Fri, 14 Dec 2007 07:35:52 -0800 (PST) Received: from localhost.localdomain (IDENT:U2FsdGVkX19xBOqhUyvL/qiIqFeLAiIGscnDtVVjaHE@sekrit.taec.toshiba.com [209.243.166.44]) by mailhost.taec.toshiba.com (8.12.7/8.12.7) with ESMTP id lBEFZgP2000468; Fri, 14 Dec 2007 07:35:43 -0800 (PST) Received: from localhost.localdomain (sekrit [127.0.0.1]) by localhost.localdomain (8.13.1/8.12.11) with ESMTP id lBEFZhfP032398; Fri, 14 Dec 2007 10:35:43 -0500 Received: (from stoffj@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id lBEFZcpf032395; Fri, 14 Dec 2007 10:35:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18274.41674.400276.541469@gargle.gargle.HOWL> Date: Fri, 14 Dec 2007 10:35:38 -0500 From: "John Stoffel" To: "Harris, David (IT Solutions US)" Subject: RE: Line send delay (I've seen the problem) In-Reply-To: <2461A50AD2345646B1C4B3D7BA40B8E2037CB5C4@USNWK102MSX.ww017.siemens.net> References: <2461A50AD2345646B1C4B3D7BA40B8E2037CB5C4@USNWK102MSX.ww017.siemens.net> X-Mailer: VM 7.19 under Emacs 22.1.2 X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 209.182.219.30 Cc: users@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 15:35:56 -0000 David> I agree with John, that problem should be mitigated by the David> controlling (script-sending) host. This is really the only place that this can be handled, since the problem is NOT that the speed of sending the data is too fast, it's that the device on the other end doesn't buffer it's input properly when it's doing it's own processing, so you can overrun it. This is not a new problem at all, it's been around for ages and trying to fix it in Conserver isn't the right place. David> But, it would be nice if there were a way to tell a Console David> Server port to slow the outbound traffic (from the console David> server to the attached serial console), so that many different David> admins using different clients wouldn't all have to learn how David> to solve this problem individually. Fine, drop you conserver to 300 baud, I'm sure that would be slow enough. *grin* David> Of course, the inbound traffic (from the serial attached David> console to the console server) should not be 'paced', as that David> would reduce the capacity of how much you could log in a given David> time window. But what if my conserver host can't log data that fast? Shouldn't we have the ability to slow down the receiving side as well, so that many different admins using different servers wouldn't all have to learn how to solve this problem individually? Ok, so I'm being a smartass here. But the issue is the same to my mind. David> So far, I can't find a way to do this on the console David> servers. I guess this is another 'feature request' to be David> considered by the Console Server manufacturers... and they'll David> only add it if we (their customers) ask for it. Even if you David> don't need it today, you might need it later. ;-) For this specific problem, just use expect, it's the real solution, since you need to implement a hand-shaking like process here. -> send input <- wait for response -> send more input <- wait again... There's nothing in here that conserver can help with, it's just the wrong place to try to slow things down. Really, look at expect first. John From tschei@bluewin.ch Mon Dec 17 14:38:42 2007 Received: from mail30.bluewin.ch (mail30.bluewin.ch [195.186.19.70]) by underdog.stansell.org (8.14.1/8.14.1) with ESMTP id lBHMcY9d000179 for ; Mon, 17 Dec 2007 14:38:40 -0800 (PST) Received: from ps23zhb.bluewin.ch (195.186.18.203) by mail30.bluewin.ch (Bluewin 7.3.121) id 476670BE0003EC8B for users@conserver.com; Mon, 17 Dec 2007 22:38:32 +0000 Received: from ps23zhb (localhost [127.0.0.1]) by ps23zhb.bluewin.ch (Postfix) with ESMTP id 64422E9D for ; Mon, 17 Dec 2007 22:38:32 +0000 (GMT) Message-ID: <13382845.924981197931112407.JavaMail.webmail@ps23zhb.bluewin.ch> Date: Mon, 17 Dec 2007 22:38:32 +0000 (GMT) From: "tschei@bluewin.ch" To: users@conserver.com Subject: RE: Line send delay (I've seen the problem) MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-FXIT-IP: 85.1.189.164 X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 209.182.219.30 X-BeenThere: users@conserver.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tschei@bluewin.ch List-Id: Conserver Users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2007 22:38:43 -0000 Dear All, following your conversation about the send line delay issue, I feel very much "at home" when linking this issue to CISCO devices. It appears, that the "send line delay" or "send character delay" function is very well known in Windows utilities like Hyperterm or SecureCRT (closed source). The cut & paste feature is really great on CISCO, as long as you don't have configs or ACL's so long that they fill the buffer on the router/switch and mess up the device into an unknown state that needs a reset of the system. This case disables conserver as reliable solution to do updates or maintenance on remote accessed systems, because you always have to worry. In my opinion it would be a great enhancement to get an option inside conserver to enable/disable the delay when needed. It doesen't matter, if an update would take a couple of minutes longer, if somebody could rely on the fact, that there wasn't an overflow preventing a successful upgrade. Thanks for your thoughts, Joerg