15.1. Admission
UNIX has always supported communication with serial ports. The fact is that the first computers in the UNIX environment used serial ports as outputs and inputs for users. Things have changed a lot since the “medium” terminal consisted of a serial printer operating at 10 characters per second and keyboard.
This chapter will show you some of the paths that FreeBSD uses with serial ports.
15.2. The Basics
This section should give you basic information about serial ports. If you do not find enough information on topics that interest you, check the “TERMINAL and Dial’up connections” section of this document.
The ttydX or cuaaX device is used to open the application. When the process opens the device, it accepts its basic input / output settings. You can see them by issuing the following command from the command line:
#stty -a -f / dev / ttyd1
When you change the settings of this device they will work until the device is not closed. As soon as it is opened, it will return to the basic settings. To make changes to the basic settings, you should open and adjust the device’s “initial state”.
For example, to enable the device in the configuration: CLOCAL mode, 8 bits and XON / XOFF flow controll as the basic settings for ttyd5, you should issue the following command:
#stty -f / dev / ttyid5 clocal cs8 ixon ixoff
A good place to put such configurations is /etc/rc.serial. When we place changes in it, the launched applications will download settings for individual devices (in this case, ttyid5) and accept them as standard.
Of course you will still be able to change these values from the command line.
You can of course also prevent changes to settings by other applications by putting the device in a locked state. For example, to block the speed of the ttyd5 device at 57600 bps, the following command would have to be executed:
#stty -f / dev / ttyld5 57600
Now the application that will open the ttyd5 device and will try to change the speed on the port will be blocked at 57600 bps.
Of course, you should create settings of the initial state and lock status of the device with the possibility of writing only by the root. The MAKEDEV script does not do this when you create the device’s settings entries.
15.3. terminals
Terminals provide a more convenient and cheaper way to access your system when you are not at the server console but you are connected to the network. This chapter describes how to use terminals in FreeBSD.
15.3.1. Use and types of terminals
The original UNIX system did not have a console. Instead, people would enter and run programs using terminals that were connected to a computer-server using serial ports. It’s quite like if we used a modem and any software terminal to call this another remote system in which we can only work in text mode.
Today’s PCs have consoles that are capable of high-quality graphics, but the ability to maintain a serial port connection continues to exist as with all UNIX systems today. FreeBSD is not an exception here. Using a terminal connected to an unused serial port, you can log in and run any program that you could normally run on the console or in the xterm window in X Window.
For large users, you can connect multiple terminals in the FreeBSD system and place them on the employees’ desks. For “home users”, computers like the older IBM PC or Macintosh can be used, which will be connected as a network terminal to a more powerful computer on which FreeBSD will run. You can replace something that would be a single-user computer into a powerful multi-access system.
There are three types of terminals in the FreeBSD system:
- “silly” terminals
- PCs working as terminals
- Windows X system terminals
They are described in the following sections.
15.3.1.1. Stupid terminals
Stupid terminals are specialized parts of the equipment that you can connect to the server through serial ports. They call themselves stupid because they only have enough computing power to display, send and receive text. You can not run any program on it. The computer to which we connect “silly” terminals has all the necessary computing power needed to run word processors, compilers, mail client, games and many other tools.
There are many types of stupid terminals, created by many different companies, such as Digital Equipment Corporation’s (DEC) and JKO terminal VT-100 and Wyse’s WY-75. Almost every one of them will work in the FreeBSD system. Some of the higher-end terminals may even display graphics, but few software packages can use these advanced features.
Stupid terminals are very popular in networks where their users do not need access to graphical applications, such as those available in the X Windows system.
15.3.1.2. PCs working as terminals
If stupid terminals only have the ability to display, send and receive text, then certainly any “unnecessary” computer can work as a stupid terminal. All you need is the right cable and programmable terminal emulation to run on your computer.
This configuration is the most popular at home. For example, if someone is currently working on your FreeBSD console, you can work at the same time while connected to a computer with less power but only working in text mode to your FreeBSD computer.
15.3.1.3. Terminals of X Windows systems
The Windows X system terminals are the most sophisticated of the available terminals. Instead of connecting them via serial ports, they are usually connected to the network via Ethernet. They can use X system applications, not just text ones.
This chapter does not provide a description of the installation, configuration or use of X terminals. We introduced X terminals only because of the completeness of this chapter.
15.3.2. Cables and ports
To connect the terminal to the FreeBSD system you need the right cable and serial port to connect to. This section will tell you what you need to do. If you are already familiar with the terminal topic and have the right cable, you can go straight to CONFIGURATION.
15.3.2.1. Wires
Because the terminals use serial ports, you will have to use a serial cable (RS-232C) to connect to the computer on which FreeBSD is running.
There are two types of serial cannon. Which one you use depends on which terminal you want to connect
- If you want to connect a personal computer as a working terminal, use a null-modem cable. This cable is used to connect 2 computers together.
- If you have a computer that has been factory-designed as a terminal, the best source of information will be the documentation attached to it. If you do not have one, try connecting via null-modem. If it does not work, try a standard cable.
Also, the serial port you use in the terminal and in FreeBSD must have a suitable free port so that you can use the given cable.
15.3.2.1.1. Null-modem cable
Zero modem cable transmits some signals directly and some switches. For example, sending data takes place via one pin in the sending computer and is received by another pin in the computer at the end of the transmission.
If you would like to make your own cable yourself, below is a table showing recommended paths to build your own cable for null-modem connection. It shows the connector types RS-323C, signal types and pin numbers in the DB-25 plug.
signal pin pin signal TxD 2 connected to 3 RxD RxD 3 connected to 2 TxD DTR 20 connected to 6 DSR DSR 6 combined with 20 DTR SG 7 combined with 7 SG DCD 8 connected to 4 RTS RTS 4 connected to 5 CTS CTS 5 connected to 8 DCD Note. For DCD to RTS, connect pins 4 and 5 internally in the socket, and only with the 8-pin pin on the 2nd side.
15.3.2.1.2. Standard RS-232C cable
The standard RS-232C cable transmits signals one-to-one. This means that a pin sending data at one end of the cable goes to the pin sending data at the other end. This is the type of cable to connect the modem and some terminals to FreeBSD.
15.3.2.2. ports
Serial ports are direct devices through which data is transferred between the FreeBSD server and the terminal. This section will describe what types of ports we can use and how they are addressed in FreeBSD.
15.3.2.2.1. Types of ports
A few sentences about existing serial ports. Before you buy or build a cable, you should be sure that it will match the port on your terminal and on the computer on which FreeBSD runs.
Most terminals have a DB-25 port. Personal computers, including PCs running FreeBSD, have DB-25 or DB-9 ports. If you have a multiport card on your computer, you can also have RJ-12 or RJ-45 ports.
It is best to check the documentation included with the equipment and look for the specifications of used ports in it. Sometimes, however, it is enough to look closely at the equipment to find the appropriate ports.
15.3.2.2.2. Port naming
In FreeBSD, access to serial ports can be found in the / dev directory. You can use them in two different ways.
- Ports used to receive connections are called / dev / ttydX where X is the port number starting from zero. Generally, we use these ports also for terminals. They require that a DCD signal appears on the line to start working.
- Ports used to call connections are called / dev / cuaaX. Usually, these ports are not used for terminals but for modems. You can use them if the cable or terminal does not have CD (carrier detect) support.
See also the sio manual page (4) for more information.
If you have a terminal connected to the first serial port (COM1 in DOS), you should use / dev / ttyd0 to communicate with the terminal. If it is the second serial port (COM2) you should use / dev / ttyd1 etc.
Note. Check if your kernel is adapted to support communication over serial ports, especially when working with a multiport card. See the FreeBSD kernel configuration chapter for more information.
15.3.3. Configuration
This section describes what you need to configure in your system to enable opening sessions for terminals. I assume that you already have a correctly configured kernel that supports connections to serial ports through which the terminals connect.
In short, you have to pass the init process, which is responsible for process control and initialization, to start the getty process, which is responsible for starting the login program.
To do this you have to edit the / etc / ttys file. You have to do this of course from the root level to be able to make changes to this file.
- Add an entry to the / etc / ttys file to the device name from the / dev directory, if of course not already entered there.
- Specify that you want to run / usr / libexec / getty on this port, and specify the appropriate getty type from the / etc / gettytab file.
- Specify the type of terminal.
- Set the port to “on”
- Decide whether the port should be “secure”.
- Restart init to reload the file / etc / ttys.
Optionally, you can create your own getty which later you will use in step 2, making the appropriate entry in / etc / gettytab. This document will not tell you how to do it. For more information, read the manual gettytab (5) and getty (8).
In the following sections, we will describe in detail how to perform these steps. We will use a working example to illustrate what is needed to do this. In our example, we will be connecting 2 terminals to the system: Wyse-50 and the old 286 IBM PC and the Procomm terminal that emulates vt-100. We will connect the Wyse-50 terminal to the second serial line and 286 to the sixth serial port (multiport card).
If you want to find more information about the / etc / ttys file, read the ttys (5) man page.
15.3.3.1. Adding an entry to the file / etc / ttys
The first thing you need to do is add the appropriate entry to the file / etc / ttys, if it is not already there.
The file / etc / ttys contains a list of all ports through which you can log into the system. For example, the first virtual console ttyv0 has its entry in this file. Thanks to this you can log in to the console via it. The file also contains entries about other virtual consoles, serial ports and pseudo terminals. For built-in terminals, such as serial ports, we make entries omitting their exact location (/ dev).
When you install FreeBSD, the file / etc / ttys contains entries for the first four serial ports: from ttyd0 to ttyd3. If you connect the terminal to one of these ports, you do not need to make any changes.
In our case, we connected Wyse-50 to the 2nd serial port, ttyd1, which is already in this file. However, we had to add an entry for 286 PC connected to the sixth port on a multiport card. Below is a fragment of the / etc / ttys file after we gave it a new entry:
ttyd1 “/ usr / libexec / getty std.9600” unknown off secure ttyd5
15.3.3.2. Specifying the getty program
The next thing we need to do is determine the program that will be used to support the login process on the terminal. For FreeBSD, the standard program for this is / usr / lib / getty. It displays the login: command line.
The getty program gets (optionally) one paramath from the command line used by getty. The type of getty tells us about the characteristics of a given connection with the terminal, i.e. about the connection speed, and parity. The getty program gets its settings from the file / etc / gettytab.
The / etc / gettytab file contains many pre-defined settings for new and old connection types with the terminal. In almost all cases entries starting with std will work for terminals permanently connected to the server. This entry ignores parity. In this file there are lines with speed determination for std from 110 to 115,200 bps. Of course, there are no obstacles for you to add your own entries there. However, to learn more about it, read the gettytab (5) page in the manual.
When you set the getty type for the / etc / ttys file, make sure that the communication connections on the terminal agree.
For example, Wyse-50 has the following settings: no parity and 38 400 bps connection. PC 286 also set to lack of flexibility, but the speed is defined as 19200bps. Below are the lines in the file / etc / ttys in which we define these 2 terminals.
ttyd1 “/ usr / libexec / getty std.38400” unknown off secure ttyd5 “/ usr / libexec / getty std.19200”
Attention. The second field, in which we define the program that is to be used to run the terminal, is closed in the quizzes. This is important because if we did not include this in quotes, the arguments for getty could be treated as the next field.
15.3.3.3. Determining the basic type of terminal
The third field in the / etc / ttys file specifies the default terminal type for the port. For dial-up ports, you will enter unknown or dialup here because most users have a dial-up with virtually any type of terminal or firmware terminal. For computers permanently connected to the server, the terminal type does not change, so you can place the real terminal type there.
Users should use the tset command in their configuration files for their accounts (.login and .profile or other depending on the server specifications) to check the type of terminal and display the appropriate prompt if required. By setting the terminal type in / etc / ttys, we should do this so that users will not have problems logging in.
To find the right type of terminal supported by FreeBSD, you need to look at the file / usr / share / misc / termcap. There is a list of about 600-type terminal types. You can of course add more if you need it. However, to learn more about it, read the gettytab page (5) in the manual.
For example, Wyse-50 is the type of Wyse-50 terminal (although it can emulate other types, it will be left in Wyse-50 mode). The PC 286 is run from Procomm which emulates the vt-100 terminal. Below is the appropriate but not yet completed entry from the / etc / ttys file for our example.
ttyd1 “/ usr / libexec / getty std.38400” wy50 off secure ttyd5 “/ usr / libexec / getty std.19200” vt100
15.3.3.4. Unlocking ports
The next field in the / etc / ttys file, which is the fourth in order, is the field that decides whether to open the port port. Putting it in it, we will start the init process for the second entry from the / etc / ttys file, ie getty, which will call us the login process. If you put there off, you will not get to get down and you will not be able to log in to that port.
Naturally, this field is set in the majority of cases to the value of on. Below is again a clipping of the / etc / ttys file with the configuration you have set. In both cases, we set the value of this field to on.
ttyd1 “/ usr / libexec / getty std.38400” wy50 on secure ttyd5 “/ usr / libexec / getty std.19200” vt100 on
15.3.3.5. Determining secure ports
We have already reached the last field (well, almost to the last one, there is an optional window field, but we will leave it). So the last field tells us if the port is safe.
What does a secure port mean?
This means that we can log into the root account from this port (or any other with UID = 0). On ports not specified as secure, no user with UID = 0 will be able to log in.
How to use secure and unsecured ports?
Marking the port as unsecured, the terminal to which we connect will not allow us to log in as a user with UID = 0. Users who know the root password for your server will first have to log in as normal users. To get root rights they will have to use the su command.
And that’s why there will be two records to help track down the path to obtaining root rights, both login and su commands are saved in system logs (and logins are also saved in the wtemp file).
Marking oprt as safe, we give you the option of logging in to the user with root rights. He will be (or other people who know the root password) log in directly as the root user. You do not have to use the su command then to get root rights.
Which type should you use?
Use “insecure”. Use the “secure” type only for terminals that are not in the public network and should ideally be located behind a “closed door” or a wall of fire.
And here are the complete entries for the file / etc / ttys, with a comment where the given terminals are located.
ttyd1 “/ usr / libexec / getty std.38400” wy50 on insecure # Kitchen ttyd5 “/ usr / libexec / getty std.19200” vt100 on insecure # Guest Bathroom
15.3.3.6. Forcing the init restart to reload the / etc / ttys settings
When you start FreeBSD, the first process, init, reads the contents of the file / etc / ttys and accordingly runs programs according to the list for each entry in which the fourth field was on, allowing you to log on to the given terminal.
After you edit and make changes to the / etc / ttys file, you do not have to restart the system so that init can see changes in this file. So, init will read the / etc / ttys file again when it receives the SIGHUP signal.
After you save your changes to the / etc / ttys file, send the SIGHUP signal to the init process by typing:
#kill -HUP 1
(The init process always has ID 1)
If everything has been configured correctly, and all cables are plugged into the appropriate communication ports, and the terminal is switched on, you should see the login lines. Your terminal is ready for the first login.
15.3.4. Troubleshooting
Even if the entire operations are carried out with the smallest details, something can go wrong. Below is a list of symoptoms and suggested solutions to the problem.
The login window does not appear
Make sure that the terminal is connected and attached to the current. If it is a personal computer that works as a terminal, make sure it is running program emulation on a good communication port.
Make sure that the cables are properly plugged into both computers.
Make sure that these are good cables.
Make sure that the terminal and FreeBSD are set to the same baud rate (bps) and parity. If you have a graphics terminal, make sure that the contrast and brightness are not reset. If it is a printer that works as a terminal, make sure that there is paper and ink in the right quantities and places.
Make sure that the getty process is started and it supports the terminal. Enter
#ps -axww | grep getty
to get a list of running getty processes. You should see an entry for your terminal in it. For example :
22189 d1 Is + 0: 00.03 / usr / libexec / getty std.38400 ttyd1
shows that the getty process is running on the second communication port ttyd1 and uses the entry std.38400 from / etc / gettytab.
If you do not run such a getty process, check if you have enabled the port in the / etc / ttys file. Make sure you have executed the kill -HUP 1 command
Strange stamps appearing instead of the login line:
Make sure that the terminal and FreeBSD are compatible with each other in terms of speed settings (bps) and parity. Check the getty process and be sure that you are using a good type of getty. If you do not edit / etc / ttys and do the kill -HUP 1 again
The characters are displayed twice and the password is not hidden
Switch terminal (or software terminal emulation) from “half duplex” or “local echo” to “full duplex”
15.4. Support for outgoing calls
This document will provide you with suggestions on how to set up FreeBSD as a system for accepting dial-up connections. This document is written based on the author’s experience (Guy Helmer) with FreeBSD version 1.0 and 1.1 and 1.1.5.1 (and experience with dial-up connections on other UNIX systems), although this document may not answer all your configuration questions or provide examples of insufficient examples in your case. The author also does not assume liability for any loss of data resulting from the use of the guidelines contained herein.
15.4.1. Requirements
To start working on this chapter you need basic knowledge about the FreeBSD system. The author assumes that you have the FreeBSD system installed, you know how to edit files in it and how to use system manual. As a discussion described below, for a specific version of FreeBSD, there is a basic knowledge of terminology, modems and cabling.
15.4.1.1. FreeBSD system version
The first thing we assume is that you’re using FreeBSD version 1.1 or higher (including version 2.X). FreeBSD version 1.0 contains two different network drivers, which complicates the situation. So, the serial device driver (sio) is refined in every release of FreeBSD, so in the newer version of FreeBSD there will be an improved and more efficient driver than in the earlier version of the system.
15.4.1.2. Terminology
A quick explanation of the terminology:
bps Bits per Second – the speed with which data is sent (bits per second) DTE Data Terminal Equipment – for example, yours computer DCE Data Communications Equipment – your modem RS-232 EIA agency standard for communication with ports serial for hardwar
If you need more information about terminology and subject of communication, the author recommends to read the “The RS-232 Bible” (unfortunately no ISBN number), which is worth recalling.
When we talk about the speed of data transfer, the author does not use the term “baud”. “Baud” refers to the amount of electrical state changes that can be obtained over a period of time, while “bps” is the correct term to use.
15.4.1.3. External modems versus internal modems
External modems are less troublesome for dial-up connections because they can often be configured permanently through parameters stored in non-erasing RAM memory, and provide us with information about RS-232 signals through flashing diodes. Flashing LEDs impress the viewers, but they can also show us what the modem is doing right now.
Internal modems usually do not have non-ram RAM, so their configurations can only be done by setting jumpers. If the internal modem has even some diodes, then the use of them is quite uncomfortable because they are located in the back of the computer or are covered by the casing.
15.4.1.4. Modems and cables
The basic knowledge on this subject is taken as follows:
- You know how to connect a modem to a computer so that they can communicate with each other
- You are familiar with the commands of your modem, or you know where to look for them if needed.
- You know how to configure your modem (probably through a program for communication with the terminal) where you can set the RAM parameters “permanently”.
The first thing to do is connect the modem, it is usually straightforward, most of the serial cables work without problems. You will also need a cable with the right plug (DB-9 or DB-25 female or male) at each end, and the cable must be DCE-to-DTE with the following sync cables:
– Transmitted Data (SD) – Recived Data (RD) – Request to Send (RTS) – Clear to Send (CTS) – Data Set Ready (DSR) – Data Terminal Ready (DTR) – Carrier Detect (CD) – Signal Ground (SG)
FreeBSD requires RTS and CTS signals to control the data stream at speeds above 2400 bps, the CD signal to be detected when the response arrives or the line is raised, and the DTR signal to reset the modem after the session ends. In some cables there are more lines than required to send signals, so if you have a problem, such as a logged session does not end when the line “rises”, the problem may be due to the fault of the cable.
The second requirement is that you know how to use the modem you use. If you do not know the commands of your modem’s command line, you will need a modem manual or a quick reference guide.
The last thing you need to know is how to set up your modem to work well with the FreeBSD system. Like other UNIX operating systems, FreeBSD uses hardware signals to find incoming connections, or to answer a call, or to reset the modem after a connection. FreeBSD avoids sending commands to the modem or checking the status from the modem. If you are familiar with connecting modems to PC-based BBSs, this can be troublesome.
15.4.1.5. Serial interfaces considered
FreeBSD supports NS8250-, NS16450-, NS 16550- and NS 16550A-based EIA RS-232C (CCIT V.24) communication interfaces. Devices 8250 and 16450 have a one-character buffer. The 16550 has a 16-character buffer that increases system performance. The 16550 scheduling error interferes with the 16-character buffer, so try to use 16550A if possible. Because a one-character device buffer requires more operating system operation than a 16-character buffer, the 16550A card is more convenient and preferred. If the system has a series of active serial ports or large loads, the 16550A card is better for low transmission errors.
15.4.2. Quick overview
Below is the process by which FreeBSD proceeds to log in the Dial’up connection. The getty process started by init waits to open the specified serial port (for example / dev / ttyd0). The ps ax command should show:
4850 ?? I 0:00:09 / usr / libexec / getty V19200 ttyd0
When the user calls the modem and the modems establish a connection, the CD signal is the confirmation of the modem. Kernel will notice that the connection was discovered and getty was opened for the port. getty sends a login login line: at the specified line speed. getty checks whether the received characters are acceptable, and, in a standard configuration, if he finds garbage (probably the combination of modems has a different speed than getty), getty tries to adjust the speed so that the characters received are legible.
We hope that getty finds the correct speed and the user will see the word login:. After he has entered his username, getty will execute the program / usr / bin / login, which will perform the login asking for the password and then launch the shell.
Let’s look deeper into the configuration.
15.4.3. Configuring the kernel
A typical FreeBSD kernel is prepared to support four serial ports, known in DOS under the names: COM1 :, COM2 :, COM3: and COM4 :. FreeBSD can now also work with “stupid” multiport serial cards such as Boca Boeard 1008 and 2016 (please read the manual sio (4) to learn more about configuring a kernel with a multi-port serial card). The standard kernel only looks for standard COM ports.
To see if your kerel has recognized any of your serial ports, follow the messages during the kernel botting process, or use the / sbin / dmesg command to repeat these messages. In particular, look for lines that start with the word sio. Hint: to see only messages containing the word sio, use the command:
# / sbin / dmesg | grep ‘sio’
For example, in a system with four serial ports, these are the following ports:
sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2fe-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A
If your kernel does not recognize all of the serial ports, you will probably need to create a kernel with specific parameters specifically for your hardware configuration.
Please read the BSD System Menager’s Manual chapter “Building Kernels with Config” [the text can also be found in / usr / src / share / doc / smm] and “FreeBSD Configuration Options” [z / sys / conf / options i / sys / arch / conf / options.arch with arch starting with an example from i386] to learn more about configuring and creating a kernel. Maybe you will have to unpack the source of the kernel distribution if you do not already have those sources in the * srcdist / srcsys system. ?? in FreeBSD 1.1, srcdist / sys. ?? in FreeBSD 1.1.5.1, or inside a distribution in FreeBSD 2.0) to be able to configure and create a kernel.
Create kernel configurations for your own system (if you still have one), go to the / sys / i386 / conf directory. If you create a new configuration file, copy the GENERICAH file (currently GEENRIC, or LINT) to YOURSYS, where YOURSYS is the name of your system, but written in capital letters. Edit it and change the following lines:
device sio0 at isa? port “IO_COM1” tty irq 4 vector siointr device sio1 at isa? port “IO_COM2” tty irq 3 vector siointr device sio2 at isa? port “IO_COM3” tty irq 5 vector siointr device sio3 at isa? port “IO_COM4” tty irq 9 vector siointr
You can uncomment or completely delete lines for devices you do not have. If you have a multi-port serial card, such as Boca Board BB2016, read the manual sio (4) if you want to have complete information on how to enter lines for a multiport card. Be careful if you use the configuration file from a different version of the system, because the flags of the devices differ in some versions.
NOTE: the “IO_COM1” port is a substitute for port 0x3f8, IO_COM2 for 0x2f8, IO_COM3 for 0x3e8 and IO_COM4 for 0x2e8, which have common port addresses for respected serial ports; breaks 4,3,5,9 are common interrupts for the line. Thus, regular serial ports can not be used together to interrupt ISA-bus (multi-port cards have a built-in electronics, which allows all 16550A devices on the board to share one or two interruptions of the entry line).
Once you have finished adjusting your kernel file, use the config program as in the “Building Berkeley Kernels with Config” documentation and read the config (8) man to prepare the kernel structure, then create and install it, and then test it.
15.4.4. Special device files
Most devices in the kernel are available as “special device files” that are in the / dev directory. The sio device is available as user / dev / ttyd? (wdzwaniania) i / dev / cuaa? (outgoing calls). In FreeBSD version 1.1.5 and higher there are also initialization devices (/ dev / ttyid? I / dev / cuai0?) And locking devices (/ dev / ttyld and / dev / cual0). Initialization devices are used to initialize a serial port each time the port is opened, as is the crtcts command for modems that use CTS / RTS signaling to control data flow. Locking devices are used to give a blocked flag, which will protect programs or users from changing parameters, read the termios (4), sio (4) and stty (4) manhears to learn about terminal settings,
15.4.4.1. Creating special device files
The shell script named MAKEDEV in the / dev directory manages special device files. To use the MAKEDEV script to create a special file for a dial’up device for COM1: (port 1) use MAKEDEV ttyd1.
MAKEDEV creates not only special devices / dev / ttyd devices? , but also / dev / cuaa? (and all files to the initialization and locking devices in the system) and removes the special file of the private terminal to rigidly (/ dev / tty0?) if it exists.
After creating new special device files, check the permissions of these files (especially / dev / cua *) to be sure that only users who should have access to them can read and write to them – most likely you will not want to allow all your users to use them Your modems to connect. Standard permissions for / dev / cua * files should be sufficient:
crw-rw —- 1 uucp dialer 28, 129 Feb 15 14:38 / dev / cuaa1 crw-rw —- 1 uucp dialer 28, 161 Feb 15 14:38 / dev / cuaia1 crw-rw —- 1 uucp dialer 28, 193 Feb 15 14:38 / dev / cuala1
These permissions allow the user uucp and other users in the dialer group to use the device.
15.4.5. Configuration file
There are three configuration files in the / etc directory that you will most likely need to modify to allow dial-up connections to your system. First, / usr / gettytab, contains configuration information for deamona / usr / libexec / getty. drugi, / etc / ttys, contains information that tells / sbin / init what device tty should have a getty process run for it. At the end, you can put the port initialization command in the /etc/rc.serial script if you have a system version 1.5.1.1 or higher, or you can initialize the ports from the /etc/rc.local script.
There are two schools to configure Dial-up modems in UNIX. One group configures its modems and system so that nei does not matter with what speed the user is getting into their system, the RS-232 port interface runs with blocked speed. The advantage of this configuration is that the caller always gets a call. The problem is that the system does not know what the true connection speed is, so full-screen programs like Emacs do not extend their screen-painting methods to create better answers for lower speeds.
The second school is the configuration of your modems on RS-232 interfaces so that the basic speed depends on the remote user’s speed. The connection in the V.32bis (14.4 Kbps) standard with the modem running on the RS-232 interface at 19.2 Kbps, when the 2400bps connection runs the RS-232 interface at this speed. Because getty will not understand any particular modem connection report, getty will display the login: at the speed consistent with the initialization speed and will check the returning characters to it. If the user sees trash at home, he should pressuntil he sees the correct characters on his monitor. If the speed has not been determined, getty looks for everything that the user calls garbage, and tries to go to the next speed and display the login again:. Of course, the login sequence does not look as “clean” as in the previous method using speed blocking, but the user at lower speeds should receive better interactive responses from full-screen programs.
The author will try to give indirect information between these two methods, but he is warned to have a configuration in which the speed of modem connection depends on the connection speed.
15.4.5.1. / Etc / gettytab
/ etc / gettytab is a termacap (5) style configuration file for getty information. Please see gettytab (5) in manual for complete information on this topic.
15.4.5.1.1. Configuration with constant speed
If you block your communication speed with the modem, you probably will not have to make any changes to the / etc / gettytab file.
15.4.5.1.2. Configuration with adjustable speed
You will have to set up an entry in / etc / gettytab to pass the getty process information about the speed you want to use for your modem. If you have a 2400bps modem, you will probably use the existing entry D2400. This entry exists in FreeBSD 1.1.5.1. in the gettytab file, so you will not need to add anything unless it’s a different version of FreeBSD.
# # Fast dialup terminals, 2400/1200/300 rotary # (can start either way) D2400 | D2400 | Fast-Dial-2400: \ : Nx = D2400: tc = 2400-baud: 3 | D1200 | Fast-Dial-1200: \ : Nx = D300: tc = 1200 baud: 5 | D300 | Fast-Dial-300: \ : Nx = D2400: tc = 300-baud:
If you have a higher speed modem, you’ll probably need to add an entry to the file / etc / gettyrab; below is an example of an entry allowing you to use the 14.4 Kbps modem with the upper interface set to 19.2 Kbps.
# # Additioooons for a V.32bis Modem # um | V300 | High Speed Modem at 300.8-bit: \ : Nx = V19200: tc = std.300: un | V1200 | High Speed Modem at 1200.8-bit: \ : Nx = V300: tc = std.1200: uo | V2400 | High Speed Modem at 2400,8-bit: \ : Nx = V1200: tc = std.2400: up | V9600 | High Speed Modem at 9600,8-bit: \ : Nx = V2400: tc = std.9600: um | V19200 | High Speed Modem at 19200.8-bit: \ : Nx = V9600: tc = std.19200:
in FreeBSD 1.1.5 and later, this entry will result in a connection to the 8-bit settings, without parity. In FreeBSD versions below 1.1, add the parameter: eg: to the std.xxx entry at the beginning of the file for 8-bit, no parity, otherwise, the standard connection has 7bit parameters, parity.
The above example starts at 19.2 Kbps (for V.32bis connections), then switches to 9600bps (for V.32), 2400 bps, 1200 bps, 300bps and will return to 19.2 Kbps. Call switching is defined in nx = (“next in the array”). Each line using the entry tc = (“continuation of the table”) raises the rest from “standard” settings for a specific connection speed.
If you have a 28.8 Kbps modem and / or you want to use compression on a 14.4 Kbps modem, you will have to use higher connection speeds than 19.2 Kbps. Below is an example of entry in gettytab starting at 57600 Kbps:
# # Additions for V.32bis or V.34 Modem # Starting at 57.6 Kbps # vm | VH300 | Very High Speed Modem at 300.8bit: \ : Nx = VH57600: tc = std.300: vn | VH1200 | Very High Speed Modem at 1200.8bit: \ : Nx = VH300: tc = std.1200: vo | VH2400 | Very High Speed Modem at 2400.8bit: \ : Nx = VH1200: tc = std.2400: vp | VH9600 | Very High Speed Modem at 9600,8bit: \ : Nx = VH2400: tc = std.9600: vq | VH57600 | Very High Speed Modem at 57600.8bit: \ : Nx = VH9600: tc = std.57600:
If you have a slow processor or large system load and you do not have a 16550-based serial port, you can receive sio “silo” errors when connecting 57.6 Kbps.
15.4.5.2. / Etc / ttys
/ etc / ttys is the ttys list for init for monitoring. / etc / ttys also provides secure information to login: (the root user can log in only to ttys marked as secure). See manual ttys (5) for more information.
You will have to modify existing lines in / etc / ttys beforehand or add a new one so that init can start the getty process automatically for the new dial-up port. The general format of the line will be the same, whether you use the blocked speed or set in the configuration:
ttyd0 “/ usr / libexec / getty xxx” dialup on
The first attribute at the beginning of the line specifies the special device, for this entry – ttyd0 means / dev / ttyd0 is the file that getty will follow. The second attribute, “/ usr / libexec / getty xxx” (xxx is repeated in the gettytab initialization settings) is an init process run on the device. The third attribute, dialup, is the standard terminal type. The fourth parameter, on, indicating init that this line is optional. There may also be a fifth parameter, secure, but it should be used only for physically safe terminals (like a console).
The standard type of terminal (dialup for the above example) may differ in local preferences. dialup is a traditional standard type of terminal for a dial-up line, so users can create their own script with settings to see that the terminal is as dialup and automatically change it to another type. Although the author has found a more convenient way, his site sets vt100 as a standard terminal because users use VT100 emulation on their remote systems.
After you make changes to / etc / ttys, you will have to initiate the HUP signal to init, so that it can read the settings in the file again. You can use the command:
# kill -HUP 1
to send this signal. If this is the first time you change the system settings, you may have to wait until your modem is properly configured and connected before you send HUP to init.
15.4.5.2.1. Configuration file with blocked speed
For a speed-locked configuration, your entries in ttys will need an entry with the correct speed to deliver it to getty. For a modem whose speed on the port is blocked at 19,200 Kbps, the ttys entry should look something like this:
ttyd0 “/ usr / libexec / getty std.19200” dialup on
If the modem is blocked on a different data transfer speed, replace the std.19200 entry corresponding to the speed according to schamatu std.speed from / etc / gettytab.
15.4.5.2.2. Configuration with adjustable speed
In the configuration with the set speed, your ttys entries will require the proper start of the “auto-baud” (sic) entry in / etc / gettytab. For example, if you add the above entries for modems with a negotiated speed which starts from 19.2 Kbps (entries in gettytab contain the starting point on V19200), your ttys should look like this:
ttyd0 “/ usr / libexec / gettty V19200” dialup on
15.4.5.3. /etc/rc.serial or /etc/rc.local
High speed modems, such as V.32, V.32bis and V.34, require the use of hardware data flow control. You can add the stty command to /etc/rc.serial in FreeBSD 1.1.5.1. and above or in /etc/rc.local in FreeBSd 1.1 to set the hardware data control flag in the FreeBSD kernel for the modem port.
For example, in FreeBSD 1.1.5.1, /etc/rc.serial reads:
#! / Bin / sh # # Serial port initial configuration stty -f / dev / ttyid1 crtscts stty -f / dev / cuai01 crtscts
These crtscts flag settings for termios first serial port (COM2 ? are for the initialization of dial-in and dial-out devices.
On older systems like FreeBSD 1.1, we added these entries to /etc/rc.local to set these flags on the device as crtscts:
# Set serial ports to use RTS / CTS flow control stty -f / dev / ttyd0 crtscts stty -f / dev / ttyd1 crtscts stty -f / dev / ttyd2 crtscts stty -f / dev / ttyd3 crtscts
Since there are no special device files in FreeBSD 1.1, one simply simply sets the flags on the devices, and it is to be hoped that they will not be changed.
15.4.6. Modem settings
If you have a modem that allows for permanent parameter settings in an unstable RAM, you will need to use a terminal program (such as Telix for PC-DOS or the tip under FreeBSd) to set parameters. Connect the modem using the same initial speed as using getty and configure the modem’s RAM in accordance with the following requirements:
- provide a CD when connected
- provide a DTR for operations; dump DTR and reset the modem
- control of data flow through CTS
- block the flow control of XON / XOFF
- RTS receives data flow control
- without the echo command
Please read the documentation for your modem to find the commands and / or jumpers that are used for this.
For example, to set the above settings on the USRobotics Sportster 14,400 modem, one of the possibilities is to enter such a command into the modem:
ATZ AT & C1; & D2 & H1; & I0; & R2; & W;
You will probably also need to do this to change other settings in the modem, such as when you want to use V.42bis and / or MNP5 compression.
The Sportster 14,400 external USR modem also has several jumpers that need to be adjusted, for other modems you can use the following example:
– Switch 1: Top – DTR Normal – Switch 2: Invalid (Verbal Result Codes / Numeric Result Codes) – Switch 3: Top – Suppress Result Codes – Switch 4: Down – No echo, offline commands – Switch 5: Top – Auto Answer – Switch 6: Top – Carrier Detect Normal – Switch 7: Up – Load a standard NVRAM – Switch 8: Invalid (Smart Mode / Dumb Mode)
The display of the resulting code should be blocked for dial-up modems to avoid problems that may occur when getty will erroneously give the login line: to the modem, it is on the command line and the modem will display an echo or return the result code. I heard that such a sequence can lead to a “silly” conversation between getty and modem.
15.4.6.1. Configuration file with blocked speed
For a speed-locked configuration, you will have to configure the modem to maintain a constant data rate between the modem and the computer, independent of the speed of communication between them. In the external ODR Sportster 14,400, the following commands will block the speed of data transfer between the modem and the computer to the size specified in the command:
ATZ AT & B1 & W;
15.4.6.2. Configuration with adjustable speed
For multi-speed configurations, you will have to configure your modem so that it increases the speed on the serial port to the size with which it receives data. In an external USR Sportster 14,400 modem, the following commands block modem errors, the correct data transfer speed is included in the command, but the permissible serial port speed will be adapted to the error free connection.
ATZ AT & B2 & W;
15.4.6.3. Checking the modem configuration
Most modems that offer us higher speeds have commands that allow us to check the current modem operating parameters, in human-readable form. In the external USR Sportster 14,400 modem, the ATI5 command will display the settings that are stored in the unplaced RAM. To see the real operational parameters of the modem, enter the command ATZ and then ATI4.
If you have a third-party modem, check your modem’s instructions on how to double check the modem configuration parameters.
15.4.7. Troubleshooting
Below are some tips on how to check your modem.
15.4.7.1. Check your system
Connect your modem to a computer with FreeBSD, run it, and if the LEDs (DST and PWR) light up on the modem, see if the DTR LED is on when the login appears on the console:. If it lights up, it means that the system has launched the getty process and prepared the communication port and waits for connection with the modem.
If the DTR LED did not come on, log in to the console and enter the ps ax command to see if the system is trying to start the getty process on the correct port. You should see lines like below from the following:
114 ?? I 0: 00.10 / usr / libexec / getty V19200 ttyd0 115 ?? I 0: 00.10 / usr / libexec / getty V19200 ttyd1
If you see something else like, for example
114 d0 I 0: 00.10 / usr / libexec / getty V19200 ttyd0
and the modem will not accept the connection, it means that the getty process is running correctly and waiting for the communication port to open. This will probably be a problem with the cable or modem configuration, because getty is unable to open the communication port until CD (Carrier Detect) has been asserted by the modem.
If you do not see any getty process waiting to open the designated ttydX port, check the entries in / etc / ttys again or make some mistakes there. Also check the file with logs (/ var / log / messages) or have some init or getty entries that specify the problem. If there are no logs there, check again / etc / ttys and / etc / gettytab whether the required ttydX special device files are typed correctly, or you have not committed any other typos.
15.4.7.2. Try to make a call
Try to call the system, make sure you have: 8 bits, no parity, 1 stop bit, on the remote system. If you do not receive the prompt, or you get “ trash ”, try to pressonce a second. If you still do not see the login line: after a moment, try sending a BREAK signal. If you are using a fast modem to call, try to connect again by blocking the modem interface speed (via AT & B1 for the USR Sportster modem for example).
If you still do not see the login: line, check the contents of the / etc / gettytab file again paying attention to
The initiation name listed in / etc / ttys matches the same line in / etc / gettytab
Each entry nx = matches another name from gettytab
Each entry tc = matches other names from gettytab
If you are calling and the modem on the FreeBSD system is not responding, make sure that the modem is configured to respond to the telephone when the DTR signal is provided. If I can look configured correctly, check if the modem gets a DTR signal by checking if the correct LED is on the modem (if the modem has some).
If you’ve already checked everything a few times and you still can not get into the phone, take a break and try again later. If this does not help, maybe you should send a mail to the main FreeBSD newsgroup describing your modem and problem and good people on the group will try to help you somehow.
15.4.8. thanks
Thank you to these people for your comments and advice:
Sean Kelly, [email protected]
for a lot of good suggestions
15.5. Dial-out Service
Information merged FAQ.
Below are hints that your computer will be able to connect using a modem with another computer. They are suitable to establish a terminal session with a remote host.
This is useful for logging into the BBS.
This type of connection can be extremely helpful when downloading files from the Internet if you have problems with PPP. If you need something from FTP and you do not have an FTP connection, use the terminal session. Then use the change to send them to your computer.
15.5.1. Why can not I run a tip or a cu?
On your system, probably the tip and cu programs have execute rights only for the uucp user and the dialer group. You can use this group to control who can use your modem or remote systems. Just add your user to the drupa dialer.
You can also give all users the option of running the tip and cu programs by entering:
# chmod 4511 / usr / bin / tip
You do not have to issue this command for cu, because cu is just a link to the tip program.
15.5.2. My spare Hayes modem has no support, what can I do?
Currently, the manual page for the tip program is out of date. The general dialer is already built-in. Just use the command at = hayes in your / etc / remote file.
The driver for Hayes is not extensive enough to recognize some of the more advanced messages from the modem like BUSY, NO DIALTONE or CONNECT 115200 and just reject them. You should disable these messages when using the tip program (using ATX0 & W).
So, exceeding the connection time for the tip is 60 seconds. Your modem should use something smaller, otherwise the tip will inform you about communication problems. Try ATS7 = 45 & W.
Currently, as a tapped tip, he does not have full support. The solution is to edit the tipconf.h file in the /usr/src/usr.bin/tip/tip directory. Of course you need distribution sources.
Change lines #define HAYES 0 to #define HAYES 1. Then execute the make and make install commands. Everything will work better after doing this.
15.5.3. How do I expect to enter these AT commands?
Do what is called “ direct ” in your / etc / remote file. For example, if your modem is connected to the first communication port, / dev / cuaa0, put it in the line:
cuaa0: dv = / dev / cuaa0: br # 19200: pa = none
use the maximum bps size that your modem supports in the variable br. Then, type tip cuaa0, so that you connect to the modem.
If there is no / dev / cuaa0 device in your system, do the following:
# cd / dev # MAKEDEV cuaa0
Or use root with the following options:
# cu -lline -sspeed
line is a serial port (eg / dev / cuaa0) and speed is the speed (eg 57600). When you finish entering AT commands, type ~. to get out of the room.
15.5.4. The @ sign for the variable pn does not work!
The @ sign when specifying a telephone number variable (phone number or pn) tells the tip program to check the / etc / phones file for this number. Unfortunately, @ is also a special character in variable files such as / etc / remote. To use it you have to precede it with backslash:
pn = \ @
15.5.5. How can I dial a phone number from the command line?
Enter what is named “ generic ” in the / etc / remote file. For example:
tip115200 | Dial any phone number at 115200 bps: \ : Dv = / dev / cuaa0: br # 115200: at = hayes: pa = none: du: tip57600 | Dial any phone number at 57600 bps: \ : Dv = / dev / cuaa0: br # 57600: at = hayes: pa = none: du:
Then you can enter:
# tip -115200 5551234
If you prefer cu from tip, use the standard cu entry:
cu115200 | Use cu to dial any number at 115200bps: \ : Dv = / dev / cuaa1: br # 57600: at = hayes: pa = none: du:
and then:
# cu 5551234 -s 115200
15.5.6. Do I have to enter the bps speed each time?
Put it in the entry for tip1200 or cu1200, but go forward and use the appropriate br value for each speed bps. For the tip, the default speed is 1200 bps, whose entry with the settings is searched for. You can not use 1200bps after all.
15.5.7. Can I pass the host number directly to the server terminal?
More eagerly than to wait until you connect and enter CONNECT every time, use the cm value for the tip. For example, these entries in / etc / remote:
pain | pain.deep13.com | Forrester’s machine: \ : cm = CONNECT pain \ n: tc = deep13: muffin | muffin.deep13.com | Frank’s machine: \ : cm = CONNECT muffin \ n: tc = deep13: deep13: Gizmonics Institute terminal server: \ : Dv = / dev / cuaa2: br # 38400: at = hayes: du: pa = none: pn = 5551234:
they will allow you to type tip pain or tip muffin and connect to these hosts; and tip deep13 to get to the server terminal.
15.5.8. Can a tip try more than one line for each page?
This is a common problem when the university has several modem lines and several hundred students trying to connect …
Create an entry for your university in / etc / remote and use @ as the value of pn:
big-university: \ : Pn = \ @: tc = dialout dialout: \ : Dv = / dev / cuaa3: br # 9600: at = courier: du: pa = none:
Later, put a list of phone numbers for the university in the / etc / phones file:
big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114
tip will try every phone from the list and then it will end. If you want to keep trying to connect, start the tip in the while loop.
15.5.9. Why do I have to press CTRL + P twice to send a single CTRL + P?
CTRL + P is the standard “ enforcing ” character used to inform the tip that the next character is given. You can set a mandatory character for any other character using ~ s escape, which means “ set variable ”.
The type ‘sforce = single-char’ is the new line. single-char is a single sign. If you are excluding single characters, then the force character is an empty character, which you can get using CTRL + 2 or CTRL + SPACEBAR. A good value for a single character is SHIFT + CTRL + 6, which is used in some terminal servers.
You can set a mandatory character to whatever you want by defining it in the $ HOME / .tiprc file:
force =
15.05.10. Suddenly, everything I type is written in BIG LETTERS ??
You must use CTRL + A, “ raised characters ” have been designed for people with a broken caps-lock key. Use ~ s as above and set the raisechar variable to match you. Of course, you can set it the same as the forcing sign, if you think you will not use any of them. YOU must have pressed CTRL + A, tip’s “ raise character, ” specially designed for people with broken caps-lock keys. Use ~ s as above and the variable raisechar to be pretty. In fact, you can set it to be the same as the force of nature.
Here is a simple .tiprc file perfect for Emacs users who often use the combination of CTRL + 2 and CTRL + A:
force = ^^ raisechar = ^^
^^ matches the SHIFT + CTRL + 6 combination.
15.05.11. How can I use the tip for file trancfer?
If you are talking to another UNIX system, you can send and receive files using ~ p (drop, send) and ~ t (accept). These commands run cat and echo on the remote system to receive and send files. The syntax is:
~ p local-file [remote-file] ~ t remote-file [local-file]
Unfortunately, there is no bug checking here, so you probably should use a different protocol, like using a change.
15.05.12. How can I run with a change from the tip?
To receive the file, start the sending program at the remote end. Then enter ~ C rz to start receiving them locally.
To send files, start the receiving program at the remote end. Then enter ~ C sz files to send them to the remote system
