Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Serial console

Status
Not open for further replies.

watom7

Programmer
Oct 7, 2010
7
FR
Hello,

I've got a home server running ubuntu 10.0.4. It have no monitor or keyboard. So I want to access it from a serial console. (I use SSH currently but if something goes wrong, I need to be able to do something... so serial console seems a fine thing).
OK, so on the server, I tell grub to output everything on ttyS0 and opened a getty on ttyS0.

On the client side (Laptop running Ubuntu 10.0.4 with pl2303 USB to Serial adapter) I use Minicom.

Home server restart :
I see grub menu, linux kernel messages, login prompt.
But, I can't do anything : In grub or at the login prompt, no key press is recognized by the server.
I've got write permission to /dev/ttyUSB0.
I tried a different getty (mgetty) with no success.
I stopped the getty on ttyS0 on the server. And run minicom.

From the server's minicom, if I type something, it appear on the client screen.
From the client's minicom, if I type something, some garbage appear on the server screen : ????????????????????? (One of this things for each char typed).

If I short-circuit pin 2 and 3 of the client serial port, it echoed what I type.

The two serial ports are connected with a nullmodem cable. (seems to be a full handshaking cable).

Of course, same serial port config for both minicom, grub and getty.

Hope I'm understandable enough. (English not my primary language).
Can somebody help me make this *$*#! serial console working right ?
I'm on it for 10 hours now with no success...

Edit : I nearly forgot to tell you I had to update the standard ubuntu kernel to 2.6.34-020634rc1-generic because there was a bug in the pl2303 driver in the stock kernel (2.6.32-25-generic) which prevented me from doing anything (even receiving).
 
The only thing that comes to mind is to make sure you've got the settings on the client matching those on the getty - e.g. 8-n-1, and especially the port speed.
 
I've double checked. Same settings client and server side.
Moreover, why everything can be OK one way (server to client) and not the other... ?
It puzzled me...
 
Have you pinned out the cable with a tester to make sure it's a full-handshake null modem? Pins 2 and 3 are transmit and receive, so if you manually cross those it will echo back to you what you send.
 
I've crossed pin 2 and 3, on the server serial port, on the client serial port.
I've done it again with the cable attached to server port and same thing to client port.
It echo back what I send.

However, I haven't tested the cable because it can't be opened and I haven't got a multimeter to test it. It's just written "full-handshake null modem cable" on it.

Maybe there is some code out there to test what cable I have for sure ?
 
Do you have any gender changers or worse, 15 - 9 pin adapters in the line? The pin out number scheme changes with both. My experience is that you can get away with the gender changer as long as you keep things consistent. A 15 pin serial connection doesn't use the same pins as a 9 pin and this can mess things up.

Seeing as you have shorted pins 2-3 on both ends and it works there are only a few things that can be at issue: a configuration setting, such as baud rate, parity, stop bits, etc, the cables, too long of a run, or a grounding issue.

The next thing I would definitely try is the null modem. I would even suggest eliminating it and using paper clips or wires to jumper your own (swap pins 2,3 and connect the ground.
 
Thanks for your help.
This thing is driving me crazy !
Today, after unplugging and replugging the USB to serial adapter on the laptop (client), the serial connection stop working in both ways... I receive garbage now...
I try setserial to be sure everything (baud rate, parity etc.) are ok both ways. (Previously, I let minicom do it).
Setserial don't work on the laptop. I suppose it don't work with USB to serial adapter.
So I used stty.
Here is the output of stty -a on both serial ports.

----------Server stty
speed 38400 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke


------------Client stty
speed 38400 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

Everything seems identical... But minicom to minicom transmision fail both ways.
If I try a hexdump -C /dev/ttyS0 on the server and then on the laptop cat /etc/resolv.conf > /dev/ttyUSB0, I receive only garbage on the server. (ff mostly and some 7f fb)

If I do the reverse thing (send from the server to the client), I receive nonsense data but not always the same chars.

Have an Idea about stty parameters to use ?
As for making my own cable... humm... have you got Mc Gyver number ? 'cause I've no idea how to do something reliable, even for testing.

PS : no gender changers in the way or 15 - 9 pin adapters
 
I agree that the configurations look the they should be matching. One thing that jumps out at me is the "ff mostly and some 7f fb" comment. To me, this suggests an electrical signal problem rather than a data configuration. If I recall correctly, RS-232 (serial) operates 0-12V, relative to ground. There are limits both on the maximum allowed voltage swing and the minimum required swing on the receiving and transmitting end.

How long are the cables you are working with and are the two systems connected to the same (line) power source?
 
Serial cable is 2m long and the USB to serial adapter include a USB cable of 1.5m.
The two computers are connected to the same power source.
Any idea ?
 
I have been following this thread here and on LQ. Unfortunately they don't seem to have many more suggestions either.

I am not certain what the problem is. It doesn't sound like there is anything 'wrong' with your setup and it sounds like the hardware is functional on each end. Yet, when you connect them together, things go awry. The configurations look compatible, so this shouldn't be an issue.

At this point, I would try to look at the signals with an oscilloscope (slow the baud rate down to 9600 which gives you a nice character per division ratio on the display. Another thing to try would be a packet sniffer like a Frontline. If your investigation says that it is electrical, perhaps using some RS-485 isolators may do the trick.

Last, but not least, perhaps the guys at might have somem additional suggestions. A lot of them are old timers who have been around since the 'serial' days and may remember some hacks and tricks to try. I would suggest the circuit engineering forum given your problem and knowing the guys who hang out there.
 
Thank you Noway2 for your tips.
However, I haven't got an oscilloscope and an Isolator is high priced.
It's just a home server running on a 200$ hardware you know. Don't want to buy an extra 50$ Isolator...
So I'll try first BadBigBen solution and will ask tomorrow for a refund of the USB to Serial adaptor.
I found other post on kernel mailing list of users having similar problem with lastest pl2303.
Will ask for a FTDI based adapter with a half hand-shaking null modem cable (read somewhere it's quicker for VT102 emulation) and report back to you.
 
It certainly wouldn't be the first time I have heard of a USB to serial adapter not work. One thing to consider is that they may be written around windows, meaning it works with windows and no further testing was done. Unfortunately, there are a tremendous number of standards non-compliant pieces of hardware out there that do just that.

Perhaps you should check on a HW compatibility list before selecting another model.

 
Have changed my adapter to a FTDI based one.
Everything works perfectly !
Maybe the prolific driver is faulty or the unit I had.
I don't know.
Thank you everybody for your help.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top