Thanks. I actually looked more carefully at my cable and realized that the way it was wired, it really *would* be exactly the same if I reversed it. Then I was further chagrined to realize that the cable works - sometimes. :-(
The wiring diagram I used is the 9-pin to 9-pin picture from this web page: http://service2.symantec.com/SUPPORT/pca.nsf/pfdocs/2001021513251112 I'm really ignorant of much background relating to serial cables - I don't know for certain what function is on each pin in my serial ports, but I'm hoping they match whatever the creators of that page were expecting. :-) I can get the cable working now at 9600 baud most of the time, but if I go above that agetty seems to get confused, as does init, which fails to restart agetty (and there are no messages from init in /var/log/messages indicating its spawning it and killing it). Linus wrote: > I would check your cable to make sure both CTS and DTR are pulled > up by RTS. Given the diagram in the link above, would CTS and DTR be pulled up by RTS? BTW, thanks again! -t. -----Original Message----- From: C. Linus Hicks [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 10:34 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Serial console login / null modem? On Thu, 2002-06-06 at 12:33, Furnish, Trever G wrote: > I'm trying to get a working login on my serial port and I'm running into a > problem that I initially thought was because of a mis-wired null-modem, but > now I think it's because of something I've missed in my linux configuration. > Help??? > > I've tried a commercially made null modem cable and two cables I wired > myself using two different pin-outs, all with exactly the same results. I > can get the login from the server to show up in the terminal window of the > client, but I can't get the text from the client to go back to the server. > If I use terminal programs on both sides, then the "server" can send text to > the terminal window on the client, but the client can't send text back. > > The thing that makes me believe its a configuration problem is (besides > having used three different cables now), if I flip the cable over, the > behavior of DOES NOT CHANGE. That is, I can still send from the server to > the client but not the other way around. I would expect that if it were a > wiring problem, then flipping the cable over would reverse the symptoms. This is not necessarily true. The software on one side (the server) may be ignoring the CTS (clear to send) signal while the software on the client side is not ignoring it. If your client software is using full signalling conventions, it will not actually transmit any data until everything (DTR and CTS are the ones I remember right now) is go. > I'm using a redhat 7.2 system as the server, with /dev/ttyS0. I haven't > changed any devices or other setups - this is just minicom on the server > side talking to hyperterminal on the client side. Minicom can send text to > hyperterminal but hypertrm can't send back. The settings are 9600bps, 8n1, > hardware flow control on both sides. > > Am I missing something? Is there some "allow bidirectional" setting I'm > missing somewhere or that the device file may be missing? I've seen it for > printer ports in the bios but not for serial ports... I would check your cable to make sure both CTS and DTR are pulled up by RTS. Otherwise, you will have to disable CTS detection by your software and that may not be possible in some packages. Linus _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
