Serial console via CU

Hello,

I am trying to access an OpenBSD system that I have just installed via my PcBSD system by the use of a serial cable. I have been trying both minicom and cu but I am obviously doing something wrong... cu -l /dev/cuad0 returns /var/spool/lock/LCK...cuad0 Permission Denied. Can't Open lock file. all ports busy. And when I try to connect through minicom I either get a similar lock error, or minicom will sit at the connection screen with (offline status). I feel like the answer to my problems is a rather simple one, but I do not know where else to look for information. Any help would be greatly appreciated.
 
Thank you mickey, I can't believe I forgot that part.... One problem I am having though, and never did find a good answer on correcting, is if the serial console is interrupted due to an improper exit, and the port becomes locked/busy, how can you reset the serial port?
 
After adding myself to the dialer group I have been experiencing a new problem now as well. I used to use minicom a decent amount in Linux distros so I decided to switch back to it for ease of use and more familiarity. I still cannot connect to my OpenBSD box, when I run minicom (I already ran -s on it and set up the proper Baud, set it to use device /dev/cuad0, and set the initial modem init string to "") it will not connect either. I am lost now.
 
From the cu(1) manual page:
Code:
     The cu utility guards against multiple users connecting to a remote sys-
     tem by opening modems and terminal lines with exclusive access, and by
     honoring the locking protocol used by uucico(8)

...

FILES
     /var/log/aculog         line access log
     /var/spool/lock/LCK..*  lock file to avoid conflicts with uucp(1)

I presume removing the lock file in /var/spool/lock/ should fix such kind of a problem.
 
That does seem to fix the problem if the modem is locked, however if it needs reinitialized then I am without access to the modem. Is there a way to reinitialize it? Thanks
 
z662 said:
I still cannot connect to my OpenBSD box, when I run minicom (I already ran -s on it and set up the proper Baud, set it to use device /dev/cuad0, and set the initial modem init string to "") it will not connect either. I am lost now.

Define "it will not connect".

Do you get some error message, or do you receive no data? The latter could have quite a few reasons, starting with a wrong cable, missing DCD signal, the serial console not being activated on the other end, and quite a few more I could think of.
 
SOrry for the lack of details. Yes it is the latter. Here is a screenshot of the failed connection via minicom. On a further note I can connect via cu but after it says connected, it freezes my terminal and I am unable to do anything, I have to close the terminal and delete the lock file (also why I asked about the reinitialization) I can provide more details as needed. The openBSD box is set to receive serial connections properly as far as I know (the default set up upon installation, however I changed the default Baud to 38400). Thanks
snapshot1.png
 
z662 said:
On a further note I can connect via cu but after it says connected, it freezes my terminal and I am unable to do anything, I have to close the terminal and delete the lock file (also why I asked about the reinitialization)

cu as well as tip are a bit awkward... to exit from a cu session, you need to type on a new line: [CMD=]~.[/CMD]

z662 said:
The openBSD box is set to receive serial connections properly as far as I know (the default set up upon installation, however I changed the default Baud to 38400).

As I said, there are a number of reasons for this, the most likely being:
  • Using a cable with incorrect wiring (RxD/TxD not crossed, missing RTS/CTS and/or DTR/DSR handshake lines, missing DCD line)
  • Wrong serial port setup on one or both ends
Or any combination thereof.

The most basic wiring for a so called Null Modem cable consists of three wires: RxD and TxD, which are crossed between both ends and a GND wire. Such a cable will only function, if you configure both serial ports to completely ignore modem control signals and to do no hardware handshaking (RTS/CTS, DTR/DSR). Otherwise it is quite possible, that the port simply blocks, cause it thinks there is no one on the other end.

You might try something like this, to disable modem control and hardware handshake:
[CMD=]stty < /dev/ttyd0.init clocal -crtscts[/CMD]
[CMD=]stty < /dev/cuad0.init clocal -crtscts[/CMD]

There's also a script in /etc/rc.d/serial, which you may use to set these permanently on each reboot.

But even then it's possible, that the other side still expects to see a DCD signal, and sends nothing.
 
Thanks for the lengthy reply. I tried those commands, er at least the last one. I tried to first one on my client machine and even with sudo it said "permission denied" I kinda assumed it was for the openBSD box at that point since I was under the impression ttyd0 is the incoming port (for the server) However openBSD has no device as ttyd0 (although I would provide the /etc/ttys file if it will help) I then tried the 2nd command on my client machine (PcBSD) and it executed without errors. I was still unable to get anything working in minicom. I then connected with cu and disconnected with your advice. Do you think I should just learn how to use cu or can cu 'connect' like I am experiencing without showing a login screen? I am not really sure what is going on. On a further note, I am rather sure the cable is not to blame, as I used to use this same cable on various computers in a Linux environment. I however never set up a serial connection between 2 BSD boxes hence my trouble. Thank you for all your help thus far.
 
z662 said:
I tried those commands, er at least the last one. I tried to first one on my client machine and even with sudo it said "permission denied" I kinda assumed it was for the openBSD box at that point since I was under the impression ttyd0 is the incoming port (for the server)

In general, each port has two device files: A 'call-in' device (often named tty...) and a 'call-out' device (often named cua...). The difference being, that a call-in device blocks until the presence of a hardware carrier detect (DCD) signal is sensed, which a call-out device doesn't. You would use a call-in device to run getty(8) on the server side. Call-out devices are what you use for programs like cu(1), tip(1), minicom, or whatever to establish a connection to a remote host.

z662 said:
However openBSD has no device as ttyd0 (although I would provide the /etc/ttys file if it will help) I then tried the 2nd command on my client machine (PcBSD) and it executed without errors. I was still unable to get anything working in minicom. I then connected with cu and disconnected with your advice.

I guess OpenBSD uses another naming scheme for the device files. You did set up your OpenBSD box, to run a serial console or getty(8) on that port, didn't you?

You might also try to run cu or minicom on both sides and see if text that you type on one side arrives on the other and vice versa.

z662 said:
Do you think I should just learn how to use cu or can cu 'connect' like I am experiencing without showing a login screen? I am not really sure what is going on.

Did you hammer the ENTER key several times after connecting with cu? Without modem control lines the other side has no possibility to know that you are there, other than you typing some keys.

Which terminal emulator you use is totally up to your liking. If you are using X11, you might as well give comms/seyon a try.
 
mickey said:
I guess OpenBSD uses another naming scheme for the device files. You did set up your OpenBSD box, to run a serial console or getty(8) on that port, didn't you?

Yes it does seem to use a different naming scheme unfortunately for me at this time. I did set up OpenBSD to run a serial console (through the initial installer it auto sets it up, and when I went into /etc/ttys it shows that ttyC[0-3] ttyC4, and tty00 are set as vt220 on secure. All others are set as either vt220 off secure or unknown off. Not really sure what all that means...

mickey said:
You might also try to run cu or minicom on both sides and see if text that you type on one side arrives on the other and vice versa.

Did you hammer the ENTER key several times after connecting with cu? Without modem control lines the other side has no possibility to know that you are there, other than you typing some keys.

I did that, neither seemed to work, however I installed seyon and launched it via seyon -modems /dev/cuad0 and interestingly enough when I clicked on the shell button, it presented me the results of my PC's response (was talking to the pc and not the server) I am sure this is due to me not yet knowing how to use seyon properly, however I wasn't sure if that was information that may be relevant.
 
z662 said:
Yes it does seem to use a different naming scheme unfortunately for me at this time. I did set up OpenBSD to run a serial console (through the initial installer it auto sets it up, and when I went into /etc/ttys it shows that ttyC[0-3] ttyC4, and tty00 are set as vt220 on secure. All others are set as either vt220 off secure or unknown off. Not really sure what all that means...

I presume tty00 is what you should be going for.

The other settings: well off means erm off :p The secure/insecure determines whether the root user is allowed to log in on that line, and vt220 is the terminal type being used. The entry should also contain the speed which is used to run the corresponding port.

You may find it useful to read:

http://www.openbsd.org/faq/faq7.html#SerCon
http://old.nabble.com/Serial-console-only-works-if-set-tty-com0-is-specified-in-boot.conf-td21757534.html
http://www.openbsd.org/cgi-bin/man.cgi?query=cua&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

You should stick to the default speed of 9600 bps on both sides, until you get a working setup. You may try to increase it, once it works at all.

Carefully read through the above links and make sure you have everything set up correctly.

Try if you can make a connection using cu(1) on both sides like this:

OpenBSD box:
$ cu -l /dev/cua00 -s 9600 -t

PcBSD box:
$ cu -l /dev/cuad0 -s 9600 -t

Then try to type some characters on both sides, and see whether they arrive on the other side.
 
Alright I will try those tonight, I am pretty busy today but I want to make sure I dedicate the proper amount of time to resolve this issue and not skim over any details. Thanks a lot mickey, Ill post my results.
 
Well I figured it out, the hard way. OpenBSD makes it near impossible to mess up, and I somehow managed to do so. I noticed that I accidentally plugged in my serial cable into port2 of the server, obviously screwing up the works considering that when I installed OpenBSD it asks you which console to set the default to and I picked the 1st port. Lesson learned, don't make assumptions. Anyhow, I had to reinstall the system because in the process of these changes I modified the /etc/ttys to an invalid setup and locked myself out of the system to the point that even single user mode would not mount nor run fsck_ffs and when I ran vim I was also unable to modify changes....still confused on exactly why modifying something like /etc/ttys would hinder single user mode. Regardless upon the new installation of the server after selecting the right serial port this time, cu -l /dev/cuad0 automatically displays the console output without any modifications needed. Thanks mickey for all your help and I apologize for that one stupid mistake causing problems. 'Twas a good learning experience however!
 
Back
Top