Solved Serial console - no shell?

C

cmoerz

I got myself two FTDI based USB adapters with a zero cable; direct cu confirmed that hardware is in working order.
Now, on host A I edited /boot/loader.conf to enable serial console, /etc/ttys to enable a login on /dev/cuaU0 and I do receive a login prompt on host B.
I can even successfully enter my login on the remote side B and receive the motd but after that, nothing happens. And there's nothing in the logs that indicates why the shell isn't getting started.
EDIT: I should probably add, that I can press Ctrl+C at that point, which returns me back to the login prompt. No amount of waiting spawns the shell, unfortunately.

My entry in host A's /etc/ttys:
Code: 
cuaU0 "/usr/libexec/getty std.115200" vt100 on secure
EDIT2: I set the speed in /boot/loader.conf, that's why I modified it here as well for 115200.

What could possibly block the shell from getting started? I even tried binding to ttyU0 on host A, but that didn't produce any login on host B.
 
cmoerz said:
I should probably add, that I can press Ctrl+C at that point, which returns me back to the login prompt.
Click to expand...
What shell are you using? Is there something being started in ~/.profile for example?

You will probably want to set the TERM to xterm, vt100 is really spartan.
 
When I read your thread my immediate question was - why did you set it to cuad ? (call out). I saw you mentioned ttyU0 didn't work for you.
For example using my Prolific cable based on PL2303 chip on host I modified ttys:
Code: 
ttyU0    "/usr/libexec/getty 3wire"    vt100    onifconsole secure
And was able to connect without a problem. I did observe timeout in resizewin(1), maybe that is a problem too. If cables and console are ok yuripv79's approach makes sense - try to truss it out.
 
My first concern is where did you buy these USB Serial TTL adapters?
There are so many fakes. You really need to buy from a reputable source.
I switched from Prolific to FDTI and they are very solid. Fakes will cost you many lost manhours.
If your not spending >$25usd they are most likely fake.

I do not edit /etc/ttys but do edit /boot/loader.conf for serial console on client machine.
 
Also, who is the manufacturer, and what is the product identifier, of your console monitor? How old is it? Is it possible you have a serial modem cable where the read and write lines (pins 2 & 3) are crossed?
 
I thought about crossed RX/TX/GND lines but I don't think you get any input there. Console with no keyboard.
If you can input and see console than lines are probably OK.
Also you usually don't use the PWR signal due to level shifting needed. (Arm)
 
Please share your hardware choices.
Basic Machine Details and FDTI USB-TTL adapters used.

These are what I use. TTL-232R-3v3

I do not think your choice of the words HostA and HostB is best.
Think along the lines of serial server and serial client/s. That is essentially the connection scheme.
 
I was wondering where you got the /etc/ttys instructions.
I see them here:
docs.freebsd.org

Chapter 29. Serial Communications

This chapter covers some of the ways serial communications can be used on FreeBSD
docs.freebsd.org docs.freebsd.org
Do notice everything there is Serial/COM Port related. (ttyu0 and cuau0)
USB ports can float around. You dont want to add them to /etc/ttys in my opinion.

I have no special settings whatsoever on my serial/usb server. Just on clients I enable serial console.
Use the speed setting -s with cu.
 
First a really dumb question: Can the user you're trying to log in as access the machine via ssh or via a virtual terminal? If yes, that excludes problems like massive permissions or password issues.

Next question: Is the user a normal user (not root, not a member of the wheel group, not id==0), or is it root? I remember that there are setting that prevent root (and perhaps other privileged accounts) from logging in over insecure lines; much of this is a remnant from the dark days of modem pools.

cmoerz said:
I can even successfully enter my login on the remote side B and receive the motd
Click to expand...
This proves that the hardware is basically working: Baud rate, stop bits / parity. So far so good.

that I can press Ctrl+C at that point, which returns me back to the login prompt.
Click to expand...
That makes me think that the "shell" (the program that is started by login) is hanging. Perhaps it's actually working perfect, and simply absorbing all input without issuing any output? Perhaps it has changed the baud rate?

Vull said:
Also, who is the manufacturer, and what is the product identifier, of your console monitor? How old is it? Is it possible you have a serial modem cable where the read and write lines (pins 2 & 3) are crossed?
Click to expand...
The fact that they can type username/password and see /etc/motd means that all these problems have been solved. Unless the login process breaks them again.

Phishfry said:
You will find that certain special characters do not work correctly in a serial console.
CTL key is one as is backspace key.
Click to expand...
You probably mean delete becomes backspace. This is a common issue with consoles.

Anyway, here's my debugging suggestion. First the software one: Read the man pages for getty, ttys, login, and login.conf. From there, branch out into the various man pages for auditing and permission setting (for example pam). Just look around, and read the various config files. Perhaps there is some magic in conf that says "this setting prevents root from logging in" or "this setting changes the baud rate or hardware flow control again".

My other suspicion is: The variety of hardware flow control signals can really screw you up. I would try to disable all flow control, and then move on to the next suggestion:

Which is the hardware one: You can buy little boxes that have LEDs for each of the lines on the serial port. I have two or three of them, in both 9- and 25-pin versions. Plug one of those onto the port. Now set the baud rate of the port to REALLY slow (300 baud), so you can actually see each character as it flows by. Watch what the LEDs do when you type the username and password, and see the login and password prompts and the motd. If there is any traffic afterwards (like for example someone changing the baud rate, or break characters being transmitted), you will see it. You can also see the hardware flow control lines.

Good luck, you'll need it! The last time I set up a serial terminal on a Unix machine at home was 25 years ago. We had two Linux machines in a small spare bedroom of our old house, but that room had no heating, and in the winter it was hard to work in there. And some things could only be done on the larger of the two. So I ran a serial line to a VT200 emulator with Tektronix graphics set up in the living room.
 
Wow, thanks for the great inputs.

I'm looking at an FTDI FT232R USB UART; at least, that's what usbconfig says. Bought it on Amazon under the "CableCreation" brand. Made in China, I guess, so could be anything. I didn't consider hardware originally, because I do manage to get a connection, via cu from both sides and I do end up with a login.

The /dev/cuaU0 did make me wonder, too. This morning, I tried a different baud rate, having a similar hunch as ralphbsz. Unfortunately without success. I get through the login, but no shell.

Up to now, I attempted a login with root. You guys brought me to the solution, it appears: if I login with a regular user, it works! I do get a shell. I suppose, something from the old times might be peering its head or root is blocked from login for other reasons.

I was banging my head against the wall, retrying things again and again without changing the one factor that finally did it: the username. Again, big thanks to all of you!
 
Addendum: it was the shell (/bin/sh) that didn't work. After logging in with a regular user, su exposed the same symptoms as previous logins - it never completed with a shell prompt.
I switched the root shell to csh, like for the regular user, and voila: it works for root as well!
Not sure yet, what's causing sh to give up...
 
Phishfry said:
No that is common error for serial console. Ignore it
Click to expand...
Ok, makes sense. It was just a suggestion from my side. Trussing it out would be the best way.

Vull said:
Is it possible you have a serial modem cable where the read and write lines (pins 2 & 3) are crossed?
Click to expand...
cmoerz said:
I got myself two FTDI based USB adapters with a zero cable;
Click to expand...
Yes, if by "zero cable" cmoerz meant null modem cable. But as he's connecting two hosts directly to each other that's what is required.

He already got the motd out of the successful login something else was going on most likely.
cmoerz : glad you found the workaround. Strange though because on my box it's working with /bin/sh too (which makes sense, because why not). trussing it would be probably the best way to figure out what it's waiting on. The only thing that came to my mind (as ^c works) - did you try to execute any command even if you didn't get prompt ? Maybe it's a dummy terminal where you don't see prompt but the shell is actually there.
Small correction from my side: I have 12.3-release on i386 where I use this console.
 
Check for any aliases or other stuff being done by .login or .profile. I've had situations in the past with similar symptoms, root cause was something being started and not completing
 
I'll attempt a truss on /bin/sh; since I can finally can log in, that should work fairly straightforward.
 
cmoerz said:
Not sure yet, what's causing sh to give up...
Click to expand...
I bet it's some well hidden security feature. One of the things I dislike is that there are so many layers that prevent root from logging in via various mechanisms. The BSD-native getty/login process has one (in /etc/ttys), the Linux-derived PAM system has one, sshd has one. Given that there are already more than one, I suspect that there is a few more in places that you have forgotten to configure, because you don't know about them (nor do I).
 
Since we have end of the year let's have some fun: I bet 10EUR the shell was spawned and if he typed id he would have seen the results. I'll donate the money to FreeBSD foundation if I lose.
 
If /bin/sh doesn't work the system wouldn't even boot up. The fact that su also hung means something in the root's .profile or /etc/profile (or files sourced from it). Traditionally root had /bin/csh and toor had /bin/sh as login shell but looks like some bright guy decided to change it.
 
_martin said:
Since we have end of the year let's have some fun: I bet 10EUR the shell was spawned and if he typed id he would have seen the results. I'll donate the money to FreeBSD foundation if I lose.
Click to expand...
I can confirm you lost that one: I did try different commands to no avail. /bin/sh seems to be just stuck after attempting (and failing) to open /root/.editline. At least it's for a good cause :)

Have not dug any deeper yet, after I realized, that I apparently won't be able to do remote debugging with a USB based serial console.
 
bakul said:
If /bin/sh doesn't work the system wouldn't even boot up. The fact that su also hung means something in the root's .profile or /etc/profile (or files sourced from it). Traditionally root had /bin/csh and toor had /bin/sh as login shell but looks like some bright guy decided to change it.
Click to expand...
Yes, sh works fine, generally.

Funny thing is - sh works completely fine on ttyv* and per ssh, but somehow breaks on serial. Might have to do with me f*ing something up in /etc/ttys.

I only managed to get serial access, if I added a getty on /dev/cuaU0 on the "server", which is in my understanding "wrong". Might very well be the root of the whole issue.

I attempted to get a serial console with a USB/FTDI based serial converter. That seems to be contrary to the whole design, because USB isn't available during the initial boot phase and it can't be flagged for debugging purposes. However, dealing with a notebook without a physical serial port, I figured I'll try anyways - until I read a bit more and got smarter in terms of understanding the futility of the undertaking.

Again, big thanks to all of you, for seeing this through. It's a weird issue for sure - at the end it seems to be likely a self inflicted configuration issue.

Happy new year to all of you.
 
You must log in or register to reply here.
Back
Top