: :Joseph Garcia wrote: : > It connects and I can log in and enter commands. The problem pops up : > when receiving a lot of data quickly from the device (i.e. when I'm : > writing the configuration to the terminal). : :Maybe I'm completely missing the point here, but your :description sounds like it could be a problem with :flow control or handshaking. Dit you try to enable :it on your serial port? stty(1) has several options :for that (note that you must apply them to the lock- :state device or initial-state device, otherwise they :might be reset on the next open of the actual device; :see sio(4) for details). : :Just an idea. Sorry if the problem is somewhere else. : :Best regards : Oliver
Probably wouldn't be a good idea to program a cisco to use hardware flow control on the console port. I have a cisco too and telnet is basically the way to go. You just set up the firewall rules to only allow connections from a single internal host. Cisco's can also talk TFTP. So, e.g. with my little cisco ! copy tftp://blah.blah.blah.blah/some/path/filename running-config ! ! Primary incoming filter for T1 [ config commands ] And I just cut-and-pate the copy line into the cisco and it pulls the config via TFTP. -- The 16550A can't do hardware flow control (CTS/RTS based flow control) in hardware, it's actually done by the interrupt handler in the driver. Well, that is, the 16550A *has* a hardware flow control mode, but it was implemented incorrectly 25 years ago and it has never been fixed, ever. Nobody uses it because of that. Serial ports are being used less and less. I use a modem only very occassionally these days. I haven't had any problem running PPP over the modem at 19200 but I know for a fact that there *ARE* interrupt latency issues in DragonFly that have not been addressed that could well be responsible for lost characters on a tty. While I want to fix the latency issues, it's near dead last on my list of important things to do. I someone else wants to investigate the latency issues DragonFly does have a utility called pctrack (man pctrack) which works with kernels compiled with DEBUG_PCTRACK. This utility is a very low level utility and would be difficult to use by a non-programmer, and even then it would be difficult to use. It tries to record the PC as of when a statistics clock interrupt occurs. The idea is that areas of code which entail very long interrupt latencies will record the PC as of the crit_exit() that finally allowed interrupts to be processed again. Unfortunately it doesn't work as well as I would like and more often then not the PC's recorded are not useful in helping track down latency issues. -Matt