On 06/24/2011 05:13 PM, Sam Varshavchik wrote:
Mike Wright writes:
> Yesterday I installed putty and selecting "serial" gets me nowhere, so
> for spits and giggles I chose "ssh" and entered the hostname of the
> target machine. It asked for my login name, presented my key and,
> voilá, I'm logged into the remote machine.
>
> That step alone verifies that com port hardware, flow rates and
> handshakes, and null modem cable all work.
I dont't see how it does. ssh doesn't know anything about serial ports,
AFAIK. Furthermore, I'm unable to figure out how ssh, or anything else,
would have the knowledge to map some arbitrary hostname to a specific
serial port on my machine.
Thanks for your help, Sam. (I remember you from way back on my days on
the qmail and inter7 lists).
After a week at this my head is scrambled. I misunderstood and thought
putty was another serial application and all the other stuff went over
that. Jeez. Where was my head. TCP has ports, not serial.
More than likely, ssh connected to your machine via TCP/IP, thus
proving
nothing.
I repeat the following line. Hit me with a clueX4.
> Does anybody else have any clues here; I obviously don't :/
This should not be a difficult problem to solve.
1) Verify that you have both serial ports wired correctly. Presumably,
you have a "null modem" adapter wired in, to cross the appropriate pins.
I used to do serial port hacking, and I used to remember all the pinouts
by heart. Don't remember them anymore, but I still remember the logical
names.
2) Run minicom on both machines, set them to to the same
speed/parity/stop settings, but turn off flow control, and turn off
echo. Use 9600bps, it's a reliable failsafe. It's possible that older
hardware may not support higher speeds. It's possible that your
null-modem adaptor does not cross the RTS/CTS and DTR/DSR pins, so
hardware flow control will not work. If they're set to the same speed,
anything you type on one machine, in minicom, should show up in the
other one's screen, and vice versa.
3) If you're not getting any response from minicom, and you have them at
the same speed/parity/stop setting, and no flow contorl, there could
only be two reasons for that:
A) Your null-modem adapter is not a null-modem adapter.
B) One or the other minicom opened the wrong serial port device. If your
machine has two serial ports, it's a trial and error which one is ttyS0,
and which one is ttyS1. Even if your server has one serial port visible,
it's entirely possible that your motherboard's chipset actually has two
UARTs, but only one of them is wired to an actual serial port, so even
if you have only one serial port sticking out, it may very well be
ttyS1, rather than ttyS0.
After much mucking about I got one machine to echo gibberish to the
other, even though both have the same settings. One echoes even though
echo is set to off.
Sunday I'll go buy two connectors and wire my own 3-wire null modem
cable: ground, tx, rx. I'm tending to agree with you that something in
the cable chain is messed up. The motherboard has a header to com
adapter that could also be a source of trouble.
Thanks again.
Well, you also mentioned Xen, and if one of your machines is a virtual
machine, it's possible that Xen is not connecting your VM's logical
serial port to your actual hardware serial port. I don't know much about
Xen, so you'll need to try to dig through its documentation to see if it
says anything about supporting serial ports.
Xen domain0. No virtuals
If in doubt, get rid of Xen temporarily, and run minicom natively on
both hosts, and get them talking to each other. Once you've proven that
you have the serial ports wired correctly, then bring Xen into the
picture, and try to get it working with Xen.