LinuxCommandLibrary

tip

Connect to serial devices or remote systems

SYNOPSIS

tip [options] host | device

PARAMETERS

-v
    Verbose mode. Displays diagnostic information during connection setup.

-8
    8-bit clean. Forces the connection to use 8-bit characters, disabling parity checking.

-speed
    Set baud rate. Specifies the initial transmission speed (e.g., 9600, 115200) for the connection. This overrides any speed set in the /etc/remote entry or default settings.

-l
    Local TTY line. Specifies the local TTY device to use for the connection (e.g., /dev/ttyS0). This is used when connecting directly to a serial port.

-h
    Remote host. Forces tip to interpret the argument as a host entry from /etc/remote, even if it might otherwise be interpreted as a device path.

-disconnect-on-exit
    Hang up on exit. Causes tip to assert DTR (Data Terminal Ready) to hang up the modem when the connection is terminated. Useful for ensuring the remote modem drops the line.

-hwflow
    Hardware flow control. Enables RTS/CTS hardware flow control for the serial connection, preventing data loss by signaling when buffers are full.

-softflow
    Software flow control. Enables XON/XOFF software flow control for the serial connection, using special characters to pause and resume data transmission.

DESCRIPTION

tip is a command-line utility for establishing a terminal connection to a remote system, typically over a serial communication line or, historically, a network connection. It acts as a transparent interface, allowing users to interact with the connected system as if directly attached. Commonly used for accessing console ports of routers, switches, servers, or modems, tip provides a flexible way to manage devices that don't yet have network connectivity or require out-of-band management. It supports various serial port configurations (baud rate, parity) and offers escape sequences (e.g., ~., ~#, ~c) for control actions like disconnecting, sending a break, or changing parameters on the fly. While modern network protocols like SSH have largely replaced tip for general remote access, it remains an invaluable tool for direct hardware interaction and debugging legacy systems.

CAVEATS

Security: tip itself does not provide encryption for network connections, making it unsuitable for secure remote access over untrusted networks.

Configuration: Relies heavily on the /etc/remote file for host definitions, which can be complex to set up and maintain for multiple remote systems.

Legacy: While still functional, it is less feature-rich and user-friendly compared to modern terminal emulators or SSH clients.

Device Permissions: Requires appropriate read/write permissions for serial devices (e.g., /dev/ttyS0), often requiring root privileges or membership in a specific group (like dialout).

ESCAPE SEQUENCES

During an active tip session, special escape sequences are used to control the program itself, rather than sending input to the remote system. These sequences always start with a tilde (~) character at the beginning of a line.

~.: Disconnect. Terminates the tip session and closes the connection.
~#: Send break. Sends a BREAK signal to the remote system. This is often used to interrupt processes, reset devices, or enter a bootloader/monitor mode.
~c <command>: Local command. Executes a command on the local system, allowing you to run shell commands without exiting tip.
~s <variable>=<value>: Set variable. Modifies internal tip variables. For example, ~s baud=115200 changes the connection speed.
~p <local_file> <remote_file>: Put file. Sends a local file to the remote system. This often requires a cooperating program on the remote side to receive the file.
~t <remote_file> <local_file>: Take file. Receives a file from the remote system. Similar to 'put', this requires remote side cooperation.
~?: Help. Displays a list of all available escape sequences.

HISTORY

tip originated in Berkeley Unix (BSD) in the late 1970s/early 1980s. It was designed as a simple yet powerful tool for interacting with modems and other serial devices, and for connecting to other Unix systems via dial-up lines. It became a standard utility in BSD-derived systems and was later ported to Linux and other Unix-like operating systems as part of the bsdutils or similar packages. While its primary use case for inter-system communication has been largely superseded by network protocols like TCP/IP and applications like SSH, its core functionality for direct serial port interaction remains relevant for specific hardware management and debugging tasks, especially in embedded systems or networking equipment.

SEE ALSO

cu(1), screen(1), minicom(1), picocom(1), stty(1), ssh(1)

Copied to clipboard