Freebsd serial console cu

I have been trying both minicom and cu but I am obviously doing something wrong Can't Open lock file. 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. Is the user you are executing cu with member of the group dialer? Thank you mickey, I can't believe I forgot that part 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 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 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? Click to expand SOrry for the lack of details. The call-out port can be used if the serial cable or the terminal does not support the "Data Carrier Detect" signal. The locking devices are used to lock flags on ports to prevent users or programs changing certain parameters.

Refer to termios 4 , sio 4 , and stty 1 for information on terminal settings, locking and initializing devices, and setting terminal options, respectively.

FreeBSD also supports dumb multi-port serial interface cards, such as the BocaBoard and , as well as more intelligent multi-port cards such as those made by Digiboard. However, the default kernel only looks for the standard COM ports. To see if the system recognizes the serial ports, look for system boot messages that start with uart :.

This file already contains hint. This example determines the settings for the call-in port on COM2 :. This file affects the default settings of serial devices. To change the settings for a device, use stty. By default, the changed settings are in effect until the device is closed and when the device is reopened, it goes back to the default set.

To permanently change the default set, open and adjust the settings of the initialization device. To prevent certain settings from being changed by an application, make adjustments to the locking device. For example, to lock the speed of ttyu5 to bps, type:. Now, any application that opens ttyu5 and tries to change the speed of the port will be stuck with bps. This section describes how to use terminals with FreeBSD.

By using a terminal attached to an unused serial port, a user can log in and run any text program that can normally be run on the console or in an xterm window. Many terminals can be attached to a FreeBSD system. An older spare computer can be used as a terminal wired into a more powerful computer running FreeBSD.

This can turn what might otherwise be a single-user computer into a powerful multiple-user system. Dumb terminals are specialized hardware that connect to computers over serial lines. They are called "dumb" because they have only enough computational power to display, send, and receive text.

No programs can be run on these devices. Instead, dumb terminals connect to a computer that runs the needed programs. There are hundreds of kinds of dumb terminals made by many manufacturers, and just about any kind will work with FreeBSD.

Some high-end terminals can even display graphics, but only certain software packages can take advantage of these advanced features. Dumb terminals are popular in work environments where workers do not need access to graphical applications.

Since a dumb terminal has just enough ability to display, send, and receive text, any spare computer can be a dumb terminal. All that is needed is the proper cable and some terminal emulation software to run on the computer. This configuration can be useful. There are at least two utilities in the base-system of FreeBSD that can be used to work through a serial connection: cu 1 and tip 1. For example, to connect from a client system that runs FreeBSD to the serial connection of another system:.

Ports are numbered starting from zero. X terminals are the most sophisticated kind of terminal available. Instead of connecting to a serial port, they usually connect to a network like Ethernet.

Instead of being relegated to text-only applications, they can display any Xorg application. This section describes how to configure a FreeBSD system to enable a login session on a serial terminal. It assumes that the system recognizes the serial port to which the terminal is connected and that the terminal is connected with the correct cable. The getty process is responsible for reading a login name and starting the login program. For example, the first virtual console, ttyv0 , has an entry in this file, allowing logins on the console.

This file also contains entries for the other virtual consoles, serial ports, and pseudo-ttys. If the terminal is connected to another port, add an entry for the port. The first entry configures a Wyse connected to COM2. The second entry configures an old computer running Procomm terminal software emulating a VT terminal. The computer is connected to the sixth serial port on a multi-port serial card.

The second field tells getty to initialize and open the line, set the line speed, prompt for a user name, and then execute the login program. The optional getty type configures characteristics on the terminal line, like bps rate and parity. In almost all cases, the getty types that start with std will work for hardwired terminals as these entries ignore parity.

There is a std entry for each bps rate from to Refer to gettytab 5 for more information. When setting the getty type, make sure to match the communications settings used by the terminal. For this example, the Wyse uses no parity and connects at bps. The computer uses no parity and connects at bps. The third field is the type of terminal. For dial-up ports, unknown or dialup is typically used since users may dial up with practically any type of terminal or software.

For this example, the Wyse uses the real terminal type while the computer running Procomm is set to emulate a VT The fourth field specifies if the port should be enabled. To enable logins on this port, this field must be set to on. The final field is used to specify whether the port is secure. Marking a port as secure means that it is trusted enough to allow root to login from that port. Insecure ports do not allow root logins.

For security reasons, it is recommended to change this setting to insecure. Since init is always the first process run on a system, it always has a process ID of 1. If everything is set up correctly, all cables are in place, and the terminals are powered up, a getty process should now be running on each terminal and login prompts should be available on each terminal.

Even with the most meticulous attention to detail, something could still go wrong while setting up a terminal. Here is a list of common symptoms and some suggested fixes. If no login prompt appears, make sure the terminal is plugged in and powered up. If it is a personal computer acting as a terminal, make sure it is running terminal emulation software on the correct serial port. Make sure the cable is connected firmly to both the terminal and the FreeBSD computer.

Make sure it is the right kind of cable. Make sure the terminal and FreeBSD agree on the bps rate and parity settings. After, I wanted to try a normal user, I writed some devfs rules to give permissions to a wheel user "seaman". This user is inside the dialer and usb groups. Also this solution never worked. Hello all!

I put here additional info and behaviors I found: when I use cu , two processes are spawned at the same time: Code:. S omething new, this time I rebooted my system, without loading X, I login to the shell as root and I used the same cu command and I get: Code:. Have you solved the problem? I have the same problem and i could not get it to work. Update Might Help I am experiencing the same issues, prolific driver does go on and off line randomly under 8.

Thread starter rhish Start date Mar 21, But then, if I want to close down the serial connection without closing my ssh session I need to be able to shut down and exit out of the cu session on cuau0 , during the ssh session I opened it from.

Which, gets a bit tricky at times. And if someone else tries to access the port it's busy. I need to close down cu properly , within the original ssh session I opened it from. Maybe I'm missing somethign simple? What is the proper way to shutdown and exit out of a cu session? Re: Closing cu from within an ssh session? Untested, but ssh 1 allows changing the escape character. Option 1: Change the escape character that cu uses.