Mailing List Archive

RE: Line send delay (I've seen the problem)
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.
Infrastructure Management Services
39600 Eureka Drive
Newark, CA 94560
Tel: 510 624-5524
Fax: 510 624-5508
mailto: david.k.harris@siemens.com
www.usa.siemens.com/it-solutions


-----Original Message-----
From: John.Stoffel@taec.toshiba.com
[mailto:John.Stoffel@taec.toshiba.com]
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.

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.
Infrastructure Management Services
39600 Eureka Drive
Newark, CA 94560
Tel: 510 624-5524
Fax: 510 624-5508
mailto: david.k.harris@siemens.com
www.usa.siemens.com/it-solutions

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

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
RE: Line send delay (I've seen the problem) [ In reply to ]
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
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
RE: Line send delay (I've seen the problem) [ In reply to ]
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
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users