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. > -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
