This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

man4

1: Linux cli command extcap
2: Linux cli command wavelan
3: Linux cli command cciss
4: Linux cli command loop-control
5: Linux cli command lp
6: Linux cli command vcs
7: Linux cli command pts
8: Linux cli command sd
9: Linux cli command ram
10: Linux cli command cpuid
11: Linux cli command lirc
12: Linux cli command vcsa
13: Linux cli command hpsa
14: Linux cli command rtc
15: Linux cli command tty
16: Linux cli command msr
17: Linux cli command console_ioctl
18: Linux cli command urandom
19: Linux cli command kmem
20: Linux cli command random
21: Linux cli command veth
22: Linux cli command tty_ioctl
23: Linux cli command initrd
24: Linux cli command ptmx
25: Linux cli command smartpqi
26: Linux cli command null
27: Linux cli command mouse
28: Linux cli command console_codes
29: Linux cli command st
30: Linux cli command fuse
31: Linux cli command port
32: Linux cli command dsp56k
33: Linux cli command full
34: Linux cli command loop
35: Linux cli command zero
36: Linux cli command ttyS
37: Linux cli command mem
38: Linux cli command intro
39: Linux cli command hd
40: Linux cli command wireshark-filter

1 - Linux cli command extcap

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command extcap and provides detailed information about the command extcap, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the extcap.

NAME 🖥️ extcap 🖥️

The extcap interface

DESCRIPTION

The extcap interface is a versatile plugin interface that allows external binaries to act as capture interfaces directly in Wireshark. It is used in scenarios, where the source of the capture is not a traditional capture model (live capture from an interface, from a pipe, from a file, etc). The typical example is connecting esoteric hardware of some kind to the main Wireshark application.

Without extcap, a capture can always be achieved by directly writing to a capture file:

the-esoteric-binary –the-strange-flag –interface=stream1 –file dumpfile.pcap & wireshark dumpfile.pcap

but the extcap interface allows for such a connection to be easily established and configured using the Wireshark GUI.

The extcap subsystem is made of multiple extcap binaries that are automatically called by the GUI in a row. In the following chapters we will refer to them as “the extcaps”.

Extcaps may be any binary or script within the extcap directory. Please note, that scripts need to be executable without prefacing a script interpreter before the call.

WINDOWS USERS: Because of restrictions directly calling the script may not always work. In such a case, a batch file may be provided, which then in turn executes the script. Please refer to doc/extcap_example.py for more information.

When Wireshark launches an extcap, it automatically adds its installation path (normally *C:\Program Files\Wireshark*) to the DLL search path so that the extcap library dependencies can be found (it is not designed to be launched by hand). This is done on purpose. There should only be extcap programs (executables, Python scripts, …) in the extcap folder to reduce the startup time and not have Wireshark trying to execute other file types.

GRAMMAR ELEMENTS

Grammar elements:

arg (options)

argument for CLI calling

number

Reference # of argument for other values, display order

call

Literal argument to call (–call=…)

display

Displayed name

default

Default value, in proper form for type

range

Range of valid values for UI checking (min,max) in proper form

type

Argument type for UI filtering for raw, or UI type for selector:
integer unsigned long (may include scientific / special notation) double string (display a textbox) selector (display selector table, all values as strings) editselector (selector table which can be overridden, all values as strings) boolean (display checkbox) booleanflag (display checkbox) radio (display group of radio buttons with provided values, all values as strings) fileselect (display a dialog to select a file from the filesystem, value as string) multicheck (display a textbox for selecting multiple options, values as strings) password (display a textbox with masked text) timestamp (display a calendar)

value (options)

Values for argument selection arg Argument # this value applies to

EXAMPLES

Example 1:

arg {number=0}{call=–channel}{display=Wi-Fi Channel}{type=integer}{required=true} arg {number=1}{call=–chanflags}{display=Channel Flags}{type=radio} arg {number=2}{call=–interface}{display=Interface}{type=selector} value {arg=0}{range=1,11} value {arg=1}{value=ht40p}{display=HT40+} value {arg=1}{value=ht40m}{display=HT40-} value {arg=1}{value=ht20}{display=HT20} value {arg=2}{value=wlan0}{display=wlan0}

Example 2:

arg {number=0}{call=–usbdevice}{USB Device}{type=selector} value {arg=0}{call=/dev/sysfs/usb/foo/123}{display=Ubertooth One sn 1234} value {arg=0}{call=/dev/sysfs/usb/foo/456}{display=Ubertooth One sn 8901}

Example 3:

arg {number=0}{call=–usbdevice}{USB Device}{type=selector} arg {number=1}{call=–server}{display=IP address for log server}{type=string}{validation=(?:\d{1,3}.){3}\d{1,3}} flag {failure=Permission denied opening Ubertooth device}

Example 4:

arg {number=0}{call=–username}{display=Username}{type=string} arg {number=1}{call=–password}{display=Password}{type=password}

Example 5:

arg {number=0}{call=–start}{display=Start Time}{type=timestamp} arg {number=1}{call=–end}{display=End Time}{type=timestamp}

SECURITY CONSIDERATIONS

·
If you’re running Wireshark as root, we can’t save you.

·
Dumpcap retains suid/setgid and group execute permissions for users in the “wireshark” group only.

·
Third-party capture programs run with whatever privileges they’re installed with.

·
If an attacker can write to a system binary directory, it’s game over.

·
You can find your local extcap directory in About › Folders.

NOTES

Extcap is feature of Wireshark. The latest version of Wireshark can be found at <https://www.wireshark.org>.

HTML versions of the Wireshark project man pages are available at <https://www.wireshark.org/docs/man-pages>.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

2 - Linux cli command wavelan

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command wavelan and provides detailed information about the command wavelan, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the wavelan.

NAME 🖥️ wavelan 🖥️

AT&T GIS WaveLAN ISA device driver

SYNOPSIS

insmod wavelan_cs.o [io=B,B..] [ irq=I,I..] [name=N,N..]

DESCRIPTION

This driver is obsolete: it was removed in Linux 2.6.35.

wavelan is the low-level device driver for the NCR / AT&T / Lucent WaveLAN ISA and Digital (DEC) RoamAbout DS wireless ethernet adapter. This driver is available as a module or might be compiled in the kernel. This driver supports multiple cards in both forms (up to 4) and allocates the next available ethernet device (eth0..eth#) for each card found, unless a device name is explicitly specified (see below). This device name will be reported in the kernel log file with the MAC address, NWID, and frequency used by the card.

Parameters

This section applies to the module form (parameters passed on the insmod(8) command line). If the driver is included in the kernel, use the ether=IRQ,IO,NAME syntax on the kernel command line.

io
Specify the list of base addresses where to search for wavelan cards (setting by dip switch on the card). If you don’t specify any io address, the driver will scan 0x390 and 0x3E0 addresses, which might conflict with other hardware…

irq
Set the list of IRQs that each wavelan card should use (the value is saved in permanent storage for future use).

name
Set the list of names to be used for each wavelan card device (name used by ifconfig(8)).

Wireless extensions

Use iwconfig(8) to manipulate wireless extensions.

NWID (or domain)

Set the network ID [0 to FFFF] or disable it [off]. As the NWID is stored in the card Permanent Storage Area, it will be reused at any further invocation of the driver.

Frequency & channels

For the 2.4 GHz 2.00 Hardware, you are able to set the frequency by specifying one of the 10 defined channels (2.412, 2.422, 2.425, 2.4305, 2.432, 2.442, 2.452, 2.460, 2.462 or 2.484) or directly as a numeric value. The frequency is changed immediately and permanently. Frequency availability depends on the regulations…

Statistics spy

Set a list of MAC addresses in the driver (up to 8) and get the last quality of link for each of those (see iwspy(8)).

/proc/net/wireless

status is the status reported by the modem. Link quality reports the quality of the modulation on the air (direct sequence spread spectrum) [max = 16]. Level and Noise refer to the signal level and noise level [max = 64]. The crypt discarded packet and misc discarded packet counters are not implemented.

Private ioctl

You may use iwpriv(8) to manipulate private ioctls.

Quality and level threshold

Enables you to define the quality and level threshold used by the modem (packet below that level are discarded).

Histogram

This functionality makes it possible to set a number of signal level intervals and to count the number of packets received in each of those defined intervals. This distribution might be used to calculate the mean value and standard deviation of the signal level.

Specific notes

This driver fails to detect some non-NCR/AT&T/Lucent Wavelan cards. If this happens for you, you must look in the source code on how to add your card to the detection routine.

Some of the mentioned features are optional. You may enable or disable them by changing flags in the driver header and recompile.

3 - Linux cli command cciss

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command cciss and provides detailed information about the command cciss, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the cciss.

NAME 🖥️ cciss 🖥️

HP Smart Array block driver

SYNOPSIS

modprobe cciss [ cciss_allow_hpsa=1 ]

DESCRIPTION

Note: This obsolete driver was removed in Linux 4.14, as it is superseded by the hpsa(4) driver in newer kernels.

cciss is a block driver for older HP Smart Array RAID controllers.

Options

cciss_allow_hpsa=1: This option prevents the cciss driver from attempting to drive any controllers that the hpsa(4) driver is capable of controlling, which is to say, the cciss driver is restricted by this option to the following controllers:

    Smart Array 5300
    Smart Array 5i
    Smart Array 532
    Smart Array 5312
    Smart Array 641
    Smart Array 642
    Smart Array 6400
    Smart Array 6400 EM
    Smart Array 6i
    Smart Array P600
    Smart Array P400i
    Smart Array E200i
    Smart Array E200
    Smart Array E200i
    Smart Array E200i
    Smart Array E200i
    Smart Array E500

Supported hardware

The cciss driver supports the following Smart Array boards:

    Smart Array 5300
    Smart Array 5i
    Smart Array 532
    Smart Array 5312
    Smart Array 641
    Smart Array 642
    Smart Array 6400
    Smart Array 6400 U320 Expansion Module
    Smart Array 6i
    Smart Array P600
    Smart Array P800
    Smart Array E400
    Smart Array P400i
    Smart Array E200
    Smart Array E200i
    Smart Array E500
    Smart Array P700m
    Smart Array P212
    Smart Array P410
    Smart Array P410i
    Smart Array P411
    Smart Array P812
    Smart Array P712m
    Smart Array P711m

Configuration details

To configure HP Smart Array controllers, use the HP Array Configuration Utility (either hpacuxe(8) or hpacucli(8)) or the Offline ROM-based Configuration Utility (ORCA) run from the Smart Array’s option ROM at boot time.

FILES

Device nodes

The device naming scheme is as follows:

Major numbers:

104	cciss0
105	cciss1
106	cciss2
105	cciss3
108	cciss4
109	cciss5
110	cciss6
111	cciss7

Minor numbers:

    b7 b6 b5 b4 b3 b2 b1 b0
    |----+----| |----+----|
         |           |
         |           +-------- Partition ID (0=wholedev, 1-15 partition)
         |
         +-------------------- Logical Volume number

The device naming scheme is:

/dev/cciss/c0d0	Controller 0, disk 0, whole device
/dev/cciss/c0d0p1	Controller 0, disk 0, partition 1
/dev/cciss/c0d0p2	Controller 0, disk 0, partition 2
/dev/cciss/c0d0p3	Controller 0, disk 0, partition 3

/dev/cciss/c1d1	Controller 1, disk 1, whole device
/dev/cciss/c1d1p1	Controller 1, disk 1, partition 1
/dev/cciss/c1d1p2	Controller 1, disk 1, partition 2
/dev/cciss/c1d1p3	Controller 1, disk 1, partition 3

Files in /proc

The files /proc/driver/cciss/cciss[0-9]+ contain information about the configuration of each controller. For example:

$ cd /proc/driver/cciss
$ ls -l
total 0
-rw-r--r-- 1 root root 0 2010-09-10 10:38 cciss0
-rw-r--r-- 1 root root 0 2010-09-10 10:38 cciss1
-rw-r--r-- 1 root root 0 2010-09-10 10:38 cciss2
$ cat cciss2
cciss2: HP Smart Array P800 Controller
Board ID: 0x3223103c
Firmware Version: 7.14
IRQ: 16
Logical drives: 1
Current Q depth: 0
Current # commands on controller: 0
Max Q depth since init: 1
Max # commands on controller since init: 2
Max SG entries since init: 32
Sequential access devices: 0
cciss/c2d0:   36.38GB       RAID 0

Files in /sys

/sys/bus/pci/devices/dev/ccissX*/cXdY/model*
Displays the SCSI INQUIRY page 0 model for logical drive Y of controller X.

/sys/bus/pci/devices/dev/ccissX*/cXdY/rev*
Displays the SCSI INQUIRY page 0 revision for logical drive Y of controller X.

/sys/bus/pci/devices/dev/ccissX*/cXdY/unique_id*
Displays the SCSI INQUIRY page 83 serial number for logical drive Y of controller X.

/sys/bus/pci/devices/dev/ccissX*/cXdY/vendor*
Displays the SCSI INQUIRY page 0 vendor for logical drive Y of controller X.

/sys/bus/pci/devices/dev/ccissX*/cXdY/block:cciss!cXdY
A symbolic link to /sys/block/cciss!cXd*Y.

/sys/bus/pci/devices/dev/ccissX*/rescan*
When this file is written to, the driver rescans the controller to discover any new, removed, or modified logical drives.

/sys/bus/pci/devices/dev/ccissX*/resettable*
A value of 1 displayed in this file indicates that the “reset_devices=1” kernel parameter (used by kdump) is honored by this controller. A value of 0 indicates that the “reset_devices=1” kernel parameter will not be honored. Some models of Smart Array are not able to honor this parameter.

/sys/bus/pci/devices/dev/ccissX*/cXdY/lunid*
Displays the 8-byte LUN ID used to address logical drive Y of controller X.

/sys/bus/pci/devices/dev/ccissX*/cXdY/raid_level*
Displays the RAID level of logical drive Y of controller X.

/sys/bus/pci/devices/dev/ccissX*/cXdY/usage_count*
Displays the usage count (number of opens) of logical drive Y of controller X.

SCSI tape drive and medium changer support

SCSI sequential access devices and medium changer devices are supported and appropriate device nodes are automatically created (e.g., /dev/st0, /dev/st1, etc.; see st(4) for more details.) You must enable “SCSI tape drive support for Smart Array 5xxx” and “SCSI support” in your kernel configuration to be able to use SCSI tape drives with your Smart Array 5xxx controller.

Additionally, note that the driver will not engage the SCSI core at init time. The driver must be directed to dynamically engage the SCSI core via the /proc filesystem entry, which the “block” side of the driver creates as /proc/driver/cciss/cciss* at run time. This is because at driver init time, the SCSI core may not yet be initialized (because the driver is a block driver) and attempting to register it with the SCSI core in such a case would cause a hang. This is best done via an initialization script (typically in /etc/init.d, but could vary depending on distribution). For example:

for x in /proc/driver/cciss/cciss[0-9]*
do
    echo "engage scsi" > $x
done

Once the SCSI core is engaged by the driver, it cannot be disengaged (except by unloading the driver, if it happens to be linked as a module.)

Note also that if no sequential access devices or medium changers are detected, the SCSI core will not be engaged by the action of the above script.

Hot plug support for SCSI tape drives

Hot plugging of SCSI tape drives is supported, with some caveats. The cciss driver must be informed that changes to the SCSI bus have been made. This may be done via the /proc filesystem. For example:

echo “rescan” > /proc/scsi/cciss0/1

This causes the driver to:

query the adapter about changes to the physical SCSI buses and/or fiber channel arbitrated loop, and
make note of any new or removed sequential access devices or medium changers.

The driver will output messages indicating which devices have been added or removed and the controller, bus, target, and lun used to address each device. The driver then notifies the SCSI midlayer of these changes.

Note that the naming convention of the /proc filesystem entries contains a number in addition to the driver name (e.g., “cciss0” instead of just “cciss”, which you might expect).

Note: Only sequential access devices and medium changers are presented as SCSI devices to the SCSI midlayer by the cciss driver. Specifically, physical SCSI disk drives are not presented to the SCSI midlayer. The only disk devices that are presented to the kernel are logical drives that the array controller constructs from regions on the physical drives. The logical drives are presented to the block layer (not to the SCSI midlayer). It is important for the driver to prevent the kernel from accessing the physical drives directly, since these drives are used by the array controller to construct the logical drives.

SCSI error handling for tape drives and medium changers

The Linux SCSI midlayer provides an error-handling protocol that is initiated whenever a SCSI command fails to complete within a certain amount of time (which can vary depending on the command). The cciss driver participates in this protocol to some extent. The normal protocol is a four-step process:

First, the device is told to abort the command.
If that doesn’t work, the device is reset.
If that doesn’t work, the SCSI bus is reset.
If that doesn’t work, the host bus adapter is reset.

The cciss driver is a block driver as well as a SCSI driver and only the tape drives and medium changers are presented to the SCSI midlayer. Furthermore, unlike more straightforward SCSI drivers, disk I/O continues through the block side during the SCSI error-recovery process. Therefore, the cciss driver implements only the first two of these actions, aborting the command, and resetting the device. Note also that most tape drives will not oblige in aborting commands, and sometimes it appears they will not even obey a reset command, though in most circumstances they will. If the command cannot be aborted and the device cannot be reset, the device will be set offline.

In the event that the error-handling code is triggered and a tape drive is successfully reset or the tardy command is successfully aborted, the tape drive may still not allow I/O to continue until some command is issued that positions the tape to a known position. Typically you must rewind the tape (by issuing mt -f /dev/st0 rewind for example) before I/O can proceed again to a tape drive that was reset.

4 - Linux cli command loop-control

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command loop-control and provides detailed information about the command loop-control, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the loop-control.

NAME 🖥️ loop-control 🖥️

control - loop devices

SYNOPSIS

#include <linux/loop.h>

DESCRIPTION

The loop device is a block device that maps its data blocks not to a physical device such as a hard disk or optical disk drive, but to the blocks of a regular file in a filesystem or to another block device. This can be useful for example to provide a block device for a filesystem image stored in a file, so that it can be mounted with the mount(8) command. You could do

$ dd if=/dev/zero of=file.img bs=1MiB count=10
$ sudo losetup /dev/loop4 file.img
$ sudo mkfs -t ext4 /dev/loop4
$ sudo mkdir /myloopdev
$ sudo mount /dev/loop4 /myloopdev

See losetup(8) for another example.

A transfer function can be specified for each loop device for encryption and decryption purposes.

The following ioctl(2) operations are provided by the loop block device:

LOOP_SET_FD
Associate the loop device with the open file whose file descriptor is passed as the (third) ioctl(2) argument.

LOOP_CLR_FD
Disassociate the loop device from any file descriptor.

LOOP_SET_STATUS
Set the status of the loop device using the (third) ioctl(2) argument. This argument is a pointer to a loop_info structure, defined in <linux/loop.h> as:

struct loop_info {
    int           lo_number;      /* ioctl r/o */
    dev_t         lo_device;      /* ioctl r/o */
    unsigned long lo_inode;       /* ioctl r/o */
    dev_t         lo_rdevice;     /* ioctl r/o */
    int           lo_offset;
    int           lo_encrypt_type;
    int           lo_encrypt_key_size;  /* ioctl w/o */
    int           lo_flags;       /* ioctl r/w (r/o before
                                     Linux 2.6.25) */
    char          lo_name[LO_NAME_SIZE];
    unsigned char lo_encrypt_key[LO_KEY_SIZE];
                                  /* ioctl w/o */
    unsigned long lo_init[2];
    char          reserved[4];
};

The encryption type (lo_encrypt_type) should be one of LO_CRYPT_NONE, LO_CRYPT_XOR, LO_CRYPT_DES, LO_CRYPT_FISH2, LO_CRYPT_BLOW, LO_CRYPT_CAST128, LO_CRYPT_IDEA, LO_CRYPT_DUMMY, LO_CRYPT_SKIPJACK, or (since Linux 2.6.0) LO_CRYPT_CRYPTOAPI.

The lo_flags field is a bit mask that can include zero or more of the following:

LO_FLAGS_READ_ONLY
The loopback device is read-only.

LO_FLAGS_AUTOCLEAR (since Linux 2.6.25)
The loopback device will autodestruct on last close.

LO_FLAGS_PARTSCAN (since Linux 3.2)
Allow automatic partition scanning.

LO_FLAGS_DIRECT_IO (since Linux 4.10)
Use direct I/O mode to access the backing file.

The only lo_flags that can be modified by LOOP_SET_STATUS are LO_FLAGS_AUTOCLEAR and LO_FLAGS_PARTSCAN.

LOOP_GET_STATUS
Get the status of the loop device. The (third) ioctl(2) argument must be a pointer to a struct loop_info.

LOOP_CHANGE_FD (since Linux 2.6.5)
Switch the backing store of the loop device to the new file identified file descriptor specified in the (third) ioctl(2) argument, which is an integer. This operation is possible only if the loop device is read-only and the new backing store is the same size and type as the old backing store.

LOOP_SET_CAPACITY (since Linux 2.6.30)
Resize a live loop device. One can change the size of the underlying backing store and then use this operation so that the loop driver learns about the new size. This operation takes no argument.

LOOP_SET_DIRECT_IO (since Linux 4.10)
Set DIRECT I/O mode on the loop device, so that it can be used to open backing file. The (third) ioctl(2) argument is an unsigned long value. A nonzero represents direct I/O mode.

LOOP_SET_BLOCK_SIZE (since Linux 4.14)
Set the block size of the loop device. The (third) ioctl(2) argument is an unsigned long value. This value must be a power of two in the range [512,pagesize]; otherwise, an EINVAL error results.

LOOP_CONFIGURE (since Linux 5.8)
Setup and configure all loop device parameters in a single step using the (third) ioctl(2) argument. This argument is a pointer to a loop_config structure, defined in <linux/loop.h> as:

struct loop_config {
    __u32               fd;
    __u32               block_size;
    struct loop_info64  info;
    __u64               __reserved[8];
};

In addition to doing what LOOP_SET_STATUS can do, LOOP_CONFIGURE can also be used to do the following:

set the correct block size immediately by setting loop_config.block_size;
explicitly request direct I/O mode by setting LO_FLAGS_DIRECT_IO in loop_config.info.lo_flags; and
explicitly request read-only mode by setting LO_FLAGS_READ_ONLY in loop_config.info.lo_flags.

Since Linux 2.6, there are two new ioctl(2) operations:

LOOP_SET_STATUS64
LOOP_GET_STATUS64
These are similar to LOOP_SET_STATUS and LOOP_GET_STATUS described above but use the loop_info64 structure, which has some additional fields and a larger range for some other fields:

struct loop_info64 {
    uint64_t lo_device;           /* ioctl r/o */
    uint64_t lo_inode;            /* ioctl r/o */
    uint64_t lo_rdevice;          /* ioctl r/o */
    uint64_t lo_offset;
    uint64_t lo_sizelimit;  /* bytes, 0 == max available */
    uint32_t lo_number;           /* ioctl r/o */
    uint32_t lo_encrypt_type;
    uint32_t lo_encrypt_key_size; /* ioctl w/o */
    uint32_t lo_flags; i          /* ioctl r/w (r/o before
                                     Linux 2.6.25) */
    uint8_t  lo_file_name[LO_NAME_SIZE];
    uint8_t  lo_crypt_name[LO_NAME_SIZE];
    uint8_t  lo_encrypt_key[LO_KEY_SIZE]; /* ioctl w/o */
    uint64_t lo_init[2];
};

/dev/loop-control

Since Linux 3.1, the kernel provides the /dev/loop-control device, which permits an application to dynamically find a free device, and to add and remove loop devices from the system. To perform these operations, one first opens /dev/loop-control and then employs one of the following ioctl(2) operations:

LOOP_CTL_GET_FREE
Allocate or find a free loop device for use. On success, the device number is returned as the result of the call. This operation takes no argument.

LOOP_CTL_ADD
Add the new loop device whose device number is specified as a long integer in the third ioctl(2) argument. On success, the device index is returned as the result of the call. If the device is already allocated, the call fails with the error EEXIST.

LOOP_CTL_REMOVE
Remove the loop device whose device number is specified as a long integer in the third ioctl(2) argument. On success, the device number is returned as the result of the call. If the device is in use, the call fails with the error EBUSY.

FILES

/dev/loop*
The loop block special device files.

EXAMPLES

The program below uses the /dev/loop-control device to find a free loop device, opens the loop device, opens a file to be used as the underlying storage for the device, and then associates the loop device with the backing store. The following shell session demonstrates the use of the program:

$ dd if=/dev/zero of=file.img bs=1MiB count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00609385 s, 1.7 GB/s
$ sudo ./mnt_loop file.img
loopname = /dev/loop5

Program source

#include <fcntl.h>
#include <linux/loop.h>
#include <sys/ioctl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define errExit(msg)    do { perror(msg); exit(EXIT_FAILURE); \
                        } while (0)
int
main(int argc, char *argv[])
{
    int loopctlfd, loopfd, backingfile;
    long devnr;
    char loopname[4096];
    if (argc != 2) {
        fprintf(stderr, "Usage: %s backing-file

“, argv[0]); exit(EXIT_FAILURE); } loopctlfd = open("/dev/loop-control”, O_RDWR); if (loopctlfd == -1) errExit(“open: /dev/loop-control”); devnr = ioctl(loopctlfd, LOOP_CTL_GET_FREE); if (devnr == -1) errExit(“ioctl-LOOP_CTL_GET_FREE”); sprintf(loopname, “/dev/loop%ld”, devnr); printf(“loopname = %s “, loopname); loopfd = open(loopname, O_RDWR); if (loopfd == -1) errExit(“open: loopname”); backingfile = open(argv[1], O_RDWR); if (backingfile == -1) errExit(“open: backing-file”); if (ioctl(loopfd, LOOP_SET_FD, backingfile) == -1) errExit(“ioctl-LOOP_SET_FD”); exit(EXIT_SUCCESS); }

5 - Linux cli command lp

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command lp and provides detailed information about the command lp, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the lp.

NAME 🖥️ lp 🖥️

line printer devices

SYNOPSIS

#include <linux/lp.h>

CONFIGURATION

lp[0–2] are character devices for the parallel line printers; they have major number 6 and minor number 0–2. The minor numbers correspond to the printer port base addresses 0x03bc, 0x0378, and 0x0278. Usually they have mode 220 and are owned by user root and group lp. You can use printer ports either with polling or with interrupts. Interrupts are recommended when high traffic is expected, for example, for laser printers. For typical dot matrix printers, polling will usually be enough. The default is polling.

DESCRIPTION

The following ioctl(2) calls are supported:

int ioctl(int fd, LPTIME, int arg)
Sets the amount of time that the driver sleeps before rechecking the printer when the printer’s buffer appears to be filled to arg. If you have a fast printer, decrease this number; if you have a slow printer, then increase it. This is in hundredths of a second, the default 2 being 0.02 seconds. It influences only the polling driver.

int ioctl(int fd, LPCHAR, int arg)
Sets the maximum number of busy-wait iterations which the polling driver does while waiting for the printer to get ready for receiving a character to arg. If printing is too slow, increase this number; if the system gets too slow, decrease this number. The default is 1000. It influences only the polling driver.

int ioctl(int fd, LPABORT, int arg)
If arg is 0, the printer driver will retry on errors, otherwise it will abort. The default is 0.

int ioctl(int fd, LPABORTOPEN, int arg)
If arg is 0, open(2) will be aborted on error, otherwise error will be ignored. The default is to ignore it.

int ioctl(int fd, LPCAREFUL, int arg)
If arg is 0, then the out-of-paper, offline, and error signals are required to be false on all writes, otherwise they are ignored. The default is to ignore them.

int ioctl(int fd, LPWAIT, int arg)
Sets the number of busy waiting iterations to wait before strobing the printer to accept a just-written character, and the number of iterations to wait before turning the strobe off again, to arg. The specification says this time should be 0.5 microseconds, but experience has shown the delay caused by the code is already enough. For that reason, the default value is 0. This is used for both the polling and the interrupt driver.

int ioctl(int fd, LPSETIRQ, int arg)
This ioctl(2) requires superuser privileges. It takes an int containing the new IRQ as argument. As a side effect, the printer will be reset. When arg is 0, the polling driver will be used, which is also default.

int ioctl(int fd, LPGETIRQ, int *arg)
Stores the currently used IRQ in arg.

int ioctl(int fd, LPGETSTATUS, int *arg)
Stores the value of the status port in arg. The bits have the following meaning:

LP_PBUSY	inverted busy input, active high
LP_PACK	unchanged acknowledge input, active low
LP_POUTPA	unchanged out-of-paper input, active high
LP_PSELECD	unchanged selected input, active high
LP_PERRORP	unchanged error input, active low

Refer to your printer manual for the meaning of the signals. Note that undocumented bits may also be set, depending on your printer.

int ioctl(int fd, LPRESET)
Resets the printer. No argument is used.

FILES

/dev/lp*

6 - Linux cli command vcs

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command vcs and provides detailed information about the command vcs, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the vcs.

NAME 🖥️ vcs 🖥️

virtual console memory

DESCRIPTION

/dev/vcs0 is a character device with major number 7 and minor number 0, usually with mode 0644 and ownership root:tty. It refers to the memory of the currently displayed virtual console terminal.

/dev/vcs[1-63] are character devices for virtual console terminals, they have major number 7 and minor number 1 to 63, usually mode 0644 and ownership root:tty. /dev/vcsa[0-63] are the same, but using unsigned shorts (in host byte order) that include attributes, and prefixed with four bytes giving the screen dimensions and cursor position: lines, columns, x, y. (x = y = 0 at the top left corner of the screen.)

When a 512-character font is loaded, the 9th bit position can be fetched by applying the ioctl(2) VT_GETHIFONTMASK operation (available since Linux 2.6.18) on /dev/tty[1-63]; the value is returned in the unsigned short pointed to by the third ioctl(2) argument.

These devices replace the screendump ioctl(2) operations of ioctl_console(2), so the system administrator can control access using filesystem permissions.

The devices for the first eight virtual consoles may be created by:

for x in 0 1 2 3 4 5 6 7 8; do
    mknod -m 644 /dev/vcs$x c 7 $x;
    mknod -m 644 /dev/vcsa$x c 7 $[$x+128];
done
chown root:tty /dev/vcs*

No ioctl(2) requests are supported.

FILES

/dev/vcs[0-63]
/dev/vcsa[0-63]

VERSIONS

Introduced with Linux 1.1.92.

EXAMPLES

You may do a screendump on vt3 by switching to vt1 and typing

cat /dev/vcs3 >foo

Note that the output does not contain newline characters, so some processing may be required, like in

fold -w 81 /dev/vcs3 | lpr

or (horrors)

setterm -dump 3 -file /proc/self/fd/1

The /dev/vcsa0 device is used for Braille support.

This program displays the character and screen attributes under the cursor of the second virtual console, then changes the background color there:

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/vt.h>
int
main(void)
{
    int fd;
    char *device = "/dev/vcsa2";
    char *console = "/dev/tty2";
    struct {unsigned char lines, cols, x, y;} scrn;
    unsigned short s;
    unsigned short mask;
    unsigned char attrib;
    int ch;
    fd = open(console, O_RDWR);
    if (fd < 0) {
        perror(console);
        exit(EXIT_FAILURE);
    }
    if (ioctl(fd, VT_GETHIFONTMASK, &mask) < 0) {
        perror("VT_GETHIFONTMASK");
        exit(EXIT_FAILURE);
    }
    (void) close(fd);
    fd = open(device, O_RDWR);
    if (fd < 0) {
        perror(device);
        exit(EXIT_FAILURE);
    }
    (void) read(fd, &scrn, 4);
    (void) lseek(fd, 4 + 2*(scrn.y*scrn.cols + scrn.x), SEEK_SET);
    (void) read(fd, &s, 2);
    ch = s & 0xff;
    if (s & mask)
        ch |= 0x100;
    attrib = ((s & ~mask) >> 8);
    printf("ch=%#03x attrib=%#02x

“, ch, attrib); s ^= 0x1000; (void) lseek(fd, -2, SEEK_CUR); (void) write(fd, &s, 2); exit(EXIT_SUCCESS); }

7 - Linux cli command pts

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command pts and provides detailed information about the command pts, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the pts.

NAME 🖥️ pts 🖥️

pseudoterminal master and slave

DESCRIPTION

The file /dev/ptmx (the pseudoterminal multiplexor device) is a character file with major number 5 and minor number 2, usually with mode 0666 and ownership root:root. It is used to create a pseudoterminal master and slave pair.

When a process opens /dev/ptmx, it gets a file descriptor for a pseudoterminal master and a pseudoterminal slave device is created in the /dev/pts directory. Each file descriptor obtained by opening /dev/ptmx is an independent pseudoterminal master with its own associated slave, whose path can be found by passing the file descriptor to ptsname(3).

Before opening the pseudoterminal slave, you must pass the master’s file descriptor to grantpt(3) and unlockpt(3).

Once both the pseudoterminal master and slave are open, the slave provides processes with an interface that is identical to that of a real terminal.

Data written to the slave is presented on the master file descriptor as input. Data written to the master is presented to the slave as input.

In practice, pseudoterminals are used for implementing terminal emulators such as xterm(1), in which data read from the pseudoterminal master is interpreted by the application in the same way a real terminal would interpret the data, and for implementing remote-login programs such as sshd(8), in which data read from the pseudoterminal master is sent across the network to a client program that is connected to a terminal or terminal emulator.

Pseudoterminals can also be used to send input to programs that normally refuse to read input from pipes (such as su(1), and passwd(1)).

FILES

/dev/ptmx, /dev/pts/*

NOTES

The Linux support for the above (known as UNIX 98 pseudoterminal naming) is done using the devpts filesystem, which should be mounted on /dev/pts.

8 - Linux cli command sd

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command sd and provides detailed information about the command sd, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the sd.

NAME 🖥️ sd 🖥️

driver for SCSI disk drives

SYNOPSIS

#include <linux/hdreg.h> /* for HDIO_GETGEO */
#include <linux/fs.h> /* for BLKGETSIZE and BLKRRPART */

CONFIGURATION

The block device name has the following form: sdlp, where l is a letter denoting the physical drive, and p is a number denoting the partition on that physical drive. Often, the partition number, p, will be left off when the device corresponds to the whole drive.

SCSI disks have a major device number of 8, and a minor device number of the form (16 * drive_number) + partition_number, where drive_number is the number of the physical drive in order of detection, and partition_number is as follows:

partition 0 is the whole drive
partitions 1–4 are the DOS “primary” partitions
partitions 5–8 are the DOS “extended” (or “logical”) partitions

For example, /dev/sda will have major 8, minor 0, and will refer to all of the first SCSI drive in the system; and /dev/sdb3 will have major 8, minor 19, and will refer to the third DOS “primary” partition on the second SCSI drive in the system.

At this time, only block devices are provided. Raw devices have not yet been implemented.

DESCRIPTION

The following ioctls are provided:

HDIO_GETGEO
Returns the BIOS disk parameters in the following structure:

struct hd_geometry {
    unsigned char  heads;
    unsigned char  sectors;
    unsigned short cylinders;
    unsigned long  start;
};

A pointer to this structure is passed as the ioctl(2) parameter.

The information returned in the parameter is the disk geometry of the drive as understood by DOS! This geometry is not the physical geometry of the drive. It is used when constructing the drive’s partition table, however, and is needed for convenient operation of fdisk(1), efdisk(1), and lilo(1). If the geometry information is not available, zero will be returned for all of the parameters.

BLKGETSIZE
Returns the device size in sectors. The ioctl(2) parameter should be a pointer to a long.

BLKRRPART
Forces a reread of the SCSI disk partition tables. No parameter is needed.

The SCSI ioctl(2) operations are also supported. If the ioctl(2) parameter is required, and it is NULL, then ioctl(2) fails with the error EINVAL.

FILES

/dev/sd[a-h]
the whole device

/dev/sd[a-h][0-8]
individual block partitions

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

9 - Linux cli command ram

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ram and provides detailed information about the command ram, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ram.

NAME 🖥️ ram 🖥️

ram disk device

DESCRIPTION

The ram device is a block device to access the ram disk in raw mode.

It is typically created by:

mknod -m 660 /dev/ram b 1 1
chown root:disk /dev/ram

FILES

/dev/ram

10 - Linux cli command cpuid

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command cpuid and provides detailed information about the command cpuid, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the cpuid.

NAME 🖥️ cpuid 🖥️

x86 CPUID access device

DESCRIPTION

CPUID provides an interface for querying information about the x86 CPU.

This device is accessed by lseek(2) or pread(2) to the appropriate CPUID level and reading in chunks of 16 bytes. A larger read size means multiple reads of consecutive levels.

The lower 32 bits of the file position is used as the incoming %eax, and the upper 32 bits of the file position as the incoming %ecx, the latter is intended for “counting” eax levels like eax=4.

This driver uses /dev/cpu/CPUNUM/cpuid, where CPUNUM is the minor number, and on an SMP box will direct the access to CPU CPUNUM as listed in /proc/cpuinfo.

This file is protected so that it can be read only by the user root, or members of the group root.

NOTES

The CPUID instruction can be directly executed by a program using inline assembler. However this device allows convenient access to all CPUs without changing process affinity.

Most of the information in cpuid is reported by the kernel in cooked form either in /proc/cpuinfo or through subdirectories in /sys/devices/system/cpu. Direct CPUID access through this device should only be used in exceptional cases.

The cpuid driver is not auto-loaded. On modular kernels you might need to use the following command to load it explicitly before use:

$ modprobe cpuid

There is no support for CPUID functions that require additional input registers.

Early i486 CPUs do not support the CPUID instruction; opening this device for those CPUs fails with EIO.

11 - Linux cli command lirc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command lirc and provides detailed information about the command lirc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the lirc.

NAME 🖥️ lirc 🖥️

lirc devices

DESCRIPTION

The /dev/lirc* character devices provide a low-level bidirectional interface to infra-red (IR) remotes. Most of these devices can receive, and some can send. When receiving or sending data, the driver works in two different modes depending on the underlying hardware.

Some hardware (typically TV-cards) decodes the IR signal internally and provides decoded button presses as scancode values. Drivers for this kind of hardware work in LIRC_MODE_SCANCODE mode. Such hardware usually does not support sending IR signals. Furthermore, such hardware can only decode a limited set of IR protocols, usually only the protocol of the specific remote which is bundled with, for example, a TV-card.

Other hardware provides a stream of pulse/space durations. Such drivers work in LIRC_MODE_MODE2 mode. Such hardware can be used with (almost) any kind of remote. This type of hardware can also be used in LIRC_MODE_SCANCODE mode, in which case the kernel IR decoders will decode the IR. These decoders can be written in extended BPF (see bpf(2)) and attached to the lirc device. Sometimes, this kind of hardware also supports sending IR data.

The LIRC_GET_FEATURES ioctl (see below) allows probing for whether receiving and sending is supported, and in which modes, amongst other features.

Reading input with the LIRC_MODE_MODE2 mode

In the LIRC_MODE_MODE2 mode, the data returned by read(2) provides 32-bit values representing a space or a pulse duration. The time of the duration (microseconds) is encoded in the lower 24 bits. Pulse (also known as flash) indicates a duration of infrared light being detected, and space (also known as gap) indicates a duration with no infrared. If the duration of space exceeds the inactivity timeout, a special timeout package is delivered, which marks the end of a message. The upper 8 bits indicate the type of package:

LIRC_MODE2_SPACE
Value reflects a space duration (microseconds).

LIRC_MODE2_PULSE
Value reflects a pulse duration (microseconds).

LIRC_MODE2_FREQUENCY
Value reflects a frequency (Hz); see the LIRC_SET_MEASURE_CARRIER_MODE ioctl.

LIRC_MODE2_TIMEOUT
Value reflects a space duration (microseconds). The package reflects a timeout; see the LIRC_SET_REC_TIMEOUT_REPORTS ioctl.

LIRC_MODE2_OVERFLOW
The IR receiver encountered an overflow, and as a result data is missing (since Linux 5.18).

Reading input with the LIRC_MODE_SCANCODE mode

In the LIRC_MODE_SCANCODE mode, the data returned by read(2) reflects decoded button presses, in the struct lirc_scancode. The scancode is stored in the scancode field, and the IR protocol is stored in rc_proto. This field has one the values of the enum rc_proto.

Writing output with the LIRC_MODE_PULSE mode

The data written to the character device using write(2) is a pulse/space sequence of integer values. Pulses and spaces are only marked implicitly by their position. The data must start and end with a pulse, thus it must always include an odd number of samples. The write(2) function blocks until the data has been transmitted by the hardware. If more data is provided than the hardware can send, the write(2) call fails with the error EINVAL.

Writing output with the LIRC_MODE_SCANCODE mode

The data written to the character devices must be a single struct lirc_scancode. The scancode and rc_proto fields must filled in, all other fields must be 0. The kernel IR encoders will convert the scancode to pulses and spaces. The protocol or scancode is invalid, or the lirc device cannot transmit.

IOCTL COMMANDS

#include <linux/lirc.h>    /* But see BUGS */
int ioctl(int fd, int cmd, int *val);

The following ioctl(2) operations are provided by the lirc character device to probe or change specific lirc hardware settings.

Always Supported Commands

/dev/lirc* devices always support the following commands:

LIRC_GET_FEATURES (void)
Returns a bit mask of combined features bits; see FEATURES.

If a device returns an error code for LIRC_GET_FEATURES, it is safe to assume it is not a lirc device.

Optional Commands

Some lirc devices support the commands listed below. Unless otherwise stated, these fail with the error ENOTTY if the operation isn’t supported, or with the error EINVAL if the operation failed, or invalid arguments were provided. If a driver does not announce support of certain features, invoking the corresponding ioctls will fail with the error ENOTTY.

LIRC_GET_REC_MODE (void)
If the lirc device has no receiver, this operation fails with the error ENOTTY. Otherwise, it returns the receive mode, which will be one of:

LIRC_MODE_MODE2
The driver returns a sequence of pulse/space durations.

LIRC_MODE_SCANCODE
The driver returns struct lirc_scancode values, each of which represents a decoded button press.

LIRC_SET_REC_MODE (int)
Set the receive mode. val is either LIRC_MODE_SCANCODE or LIRC_MODE_MODE2. If the lirc device has no receiver, this operation fails with the error ENOTTY.

LIRC_GET_SEND_MODE (void)
Return the send mode. LIRC_MODE_PULSE or LIRC_MODE_SCANCODE is supported. If the lirc device cannot send, this operation fails with the error ENOTTY.

LIRC_SET_SEND_MODE (int)
Set the send mode. val is either LIRC_MODE_SCANCODE or LIRC_MODE_PULSE. If the lirc device cannot send, this operation fails with the error ENOTTY.

LIRC_SET_SEND_CARRIER (int)
Set the modulation frequency. The argument is the frequency (Hz).

LIRC_SET_SEND_DUTY_CYCLE (int)
Set the carrier duty cycle. val is a number in the range [0,100] which describes the pulse width as a percentage of the total cycle. Currently, no special meaning is defined for 0 or 100, but the values are reserved for future use.

LIRC_GET_MIN_TIMEOUT(void)
LIRC_GET_MAX_TIMEOUT(void)
Some devices have internal timers that can be used to detect when there has been no IR activity for a long time. This can help lircd(8) in detecting that an IR signal is finished and can speed up the decoding process. These operations return integer values with the minimum/maximum timeout that can be set (microseconds). Some devices have a fixed timeout. For such drivers, LIRC_GET_MIN_TIMEOUT and LIRC_GET_MAX_TIMEOUT will fail with the error ENOTTY.

LIRC_SET_REC_TIMEOUT (int)
Set the integer value for IR inactivity timeout (microseconds). To be accepted, the value must be within the limits defined by LIRC_GET_MIN_TIMEOUT and LIRC_GET_MAX_TIMEOUT. A value of 0 (if supported by the hardware) disables all hardware timeouts and data should be reported as soon as possible. If the exact value cannot be set, then the next possible value greater than the given value should be set.

LIRC_GET_REC_TIMEOUT (void)
Return the current inactivity timeout (microseconds). Available since Linux 4.18.

LIRC_SET_REC_TIMEOUT_REPORTS (int)
Enable (val is 1) or disable (val is 0) timeout packages in LIRC_MODE_MODE2. The behavior of this operation has varied across kernel versions:

Since Linux 5.17: timeout packages are always enabled and this ioctl is a no-op.
Since Linux 4.16: timeout packages are enabled by default. Each time the lirc device is opened, the LIRC_SET_REC_TIMEOUT operation can be used to disable (and, if desired, to later re-enable) the timeout on the file descriptor.
In Linux 4.15 and earlier: timeout packages are disabled by default, and enabling them (via LIRC_SET_REC_TIMEOUT) on any file descriptor associated with the lirc device has the effect of enabling timeouts for all file descriptors referring to that device (until timeouts are disabled again).

LIRC_SET_REC_CARRIER (int)
Set the upper bound of the receive carrier frequency (Hz). See LIRC_SET_REC_CARRIER_RANGE.

LIRC_SET_REC_CARRIER_RANGE (int)
Sets the lower bound of the receive carrier frequency (Hz). For this to take affect, first set the lower bound using the LIRC_SET_REC_CARRIER_RANGE ioctl, and then the upper bound using the LIRC_SET_REC_CARRIER ioctl.

LIRC_SET_MEASURE_CARRIER_MODE (int)
Enable (val is 1) or disable (val is 0) the measure mode. If enabled, from the next key press on, the driver will send LIRC_MODE2_FREQUENCY packets. By default, this should be turned off.

LIRC_GET_REC_RESOLUTION (void)
Return the driver resolution (microseconds).

LIRC_SET_TRANSMITTER_MASK (int)
Enable the set of transmitters specified in val, which contains a bit mask where each enabled transmitter is a 1. The first transmitter is encoded by the least significant bit, and so on. When an invalid bit mask is given, for example a bit is set even though the device does not have so many transmitters, this operation returns the number of available transmitters and does nothing otherwise.

LIRC_SET_WIDEBAND_RECEIVER (int)
Some devices are equipped with a special wide band receiver which is intended to be used to learn the output of an existing remote. This ioctl can be used to enable (val equals 1) or disable (val equals 0) this functionality. This might be useful for devices that otherwise have narrow band receivers that prevent them to be used with certain remotes. Wide band receivers may also be more precise. On the other hand, their disadvantage usually is reduced range of reception.

Note: wide band receiver may be implicitly enabled if you enable carrier reports. In that case, it will be disabled as soon as you disable carrier reports. Trying to disable a wide band receiver while carrier reports are active will do nothing.

FEATURES

the LIRC_GET_FEATURES ioctl returns a bit mask describing features of the driver. The following bits may be returned in the mask:

LIRC_CAN_REC_MODE2
The driver is capable of receiving using LIRC_MODE_MODE2.

LIRC_CAN_REC_SCANCODE
The driver is capable of receiving using LIRC_MODE_SCANCODE.

LIRC_CAN_SET_SEND_CARRIER
The driver supports changing the modulation frequency using LIRC_SET_SEND_CARRIER.

LIRC_CAN_SET_SEND_DUTY_CYCLE
The driver supports changing the duty cycle using LIRC_SET_SEND_DUTY_CYCLE.

LIRC_CAN_SET_TRANSMITTER_MASK
The driver supports changing the active transmitter(s) using LIRC_SET_TRANSMITTER_MASK.

LIRC_CAN_SET_REC_CARRIER
The driver supports setting the receive carrier frequency using LIRC_SET_REC_CARRIER. Any lirc device since the drivers were merged in Linux 2.6.36 must have LIRC_CAN_SET_REC_CARRIER_RANGE set if LIRC_CAN_SET_REC_CARRIER feature is set.

LIRC_CAN_SET_REC_CARRIER_RANGE
The driver supports LIRC_SET_REC_CARRIER_RANGE. The lower bound of the carrier must first be set using the LIRC_SET_REC_CARRIER_RANGE ioctl, before using the LIRC_SET_REC_CARRIER ioctl to set the upper bound.

LIRC_CAN_GET_REC_RESOLUTION
The driver supports LIRC_GET_REC_RESOLUTION.

LIRC_CAN_SET_REC_TIMEOUT
The driver supports LIRC_SET_REC_TIMEOUT.

LIRC_CAN_MEASURE_CARRIER
The driver supports measuring of the modulation frequency using LIRC_SET_MEASURE_CARRIER_MODE.

LIRC_CAN_USE_WIDEBAND_RECEIVER
The driver supports learning mode using LIRC_SET_WIDEBAND_RECEIVER.

LIRC_CAN_SEND_PULSE
The driver supports sending using LIRC_MODE_PULSE or LIRC_MODE_SCANCODE

BUGS

Using these devices requires the kernel source header file lirc.h. This file is not available before Linux 4.6. Users of older kernels could use the file bundled in .

12 - Linux cli command vcsa

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command vcsa and provides detailed information about the command vcsa, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the vcsa.

NAME 🖥️ vcsa 🖥️

virtual console memory

DESCRIPTION

/dev/vcs0 is a character device with major number 7 and minor number 0, usually with mode 0644 and ownership root:tty. It refers to the memory of the currently displayed virtual console terminal.

These devices replace the screendump ioctl(2) operations of ioctl_console(2), so the system administrator can control access using filesystem permissions.

The devices for the first eight virtual consoles may be created by:

for x in 0 1 2 3 4 5 6 7 8; do
    mknod -m 644 /dev/vcs$x c 7 $x;
    mknod -m 644 /dev/vcsa$x c 7 $[$x+128];
done
chown root:tty /dev/vcs*

No ioctl(2) requests are supported.

FILES

/dev/vcs[0-63]
/dev/vcsa[0-63]

VERSIONS

Introduced with Linux 1.1.92.

EXAMPLES

You may do a screendump on vt3 by switching to vt1 and typing

cat /dev/vcs3 >foo

Note that the output does not contain newline characters, so some processing may be required, like in

fold -w 81 /dev/vcs3 | lpr

or (horrors)

setterm -dump 3 -file /proc/self/fd/1

The /dev/vcsa0 device is used for Braille support.

This program displays the character and screen attributes under the cursor of the second virtual console, then changes the background color there:

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/vt.h>
int
main(void)
{
    int fd;
    char *device = "/dev/vcsa2";
    char *console = "/dev/tty2";
    struct {unsigned char lines, cols, x, y;} scrn;
    unsigned short s;
    unsigned short mask;
    unsigned char attrib;
    int ch;
    fd = open(console, O_RDWR);
    if (fd < 0) {
        perror(console);
        exit(EXIT_FAILURE);
    }
    if (ioctl(fd, VT_GETHIFONTMASK, &mask) < 0) {
        perror("VT_GETHIFONTMASK");
        exit(EXIT_FAILURE);
    }
    (void) close(fd);
    fd = open(device, O_RDWR);
    if (fd < 0) {
        perror(device);
        exit(EXIT_FAILURE);
    }
    (void) read(fd, &scrn, 4);
    (void) lseek(fd, 4 + 2*(scrn.y*scrn.cols + scrn.x), SEEK_SET);
    (void) read(fd, &s, 2);
    ch = s & 0xff;
    if (s & mask)
        ch |= 0x100;
    attrib = ((s & ~mask) >> 8);
    printf("ch=%#03x attrib=%#02x

“, ch, attrib); s ^= 0x1000; (void) lseek(fd, -2, SEEK_CUR); (void) write(fd, &s, 2); exit(EXIT_SUCCESS); }

13 - Linux cli command hpsa

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hpsa and provides detailed information about the command hpsa, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hpsa.

NAME 🖥️ hpsa 🖥️

HP Smart Array SCSI driver

SYNOPSIS

modprobe hpsa [ hpsa_allow_any=1 ]

DESCRIPTION

hpsa is a SCSI driver for HP Smart Array RAID controllers.

Options

hpsa_allow_any=1: This option allows the driver to attempt to operate on any HP Smart Array hardware RAID controller, even if it is not explicitly known to the driver. This allows newer hardware to work with older drivers. Typically this is used to allow installation of operating systems from media that predates the RAID controller, though it may also be used to enable hpsa to drive older controllers that would normally be handled by the cciss(4) driver. These older boards have not been tested and are not supported with hpsa, and cciss(4) should still be used for these.

Supported hardware

The hpsa driver supports the following Smart Array boards:

    Smart Array P700M
    Smart Array P212
    Smart Array P410
    Smart Array P410i
    Smart Array P411
    Smart Array P812
    Smart Array P712m
    Smart Array P711m
    StorageWorks P1210m

Since Linux 4.14, the following Smart Array boards are also supported:

    Smart Array 5300
    Smart Array 5312
    Smart Array 532
    Smart Array 5i
    Smart Array 6400
    Smart Array 6400 EM
    Smart Array 641
    Smart Array 642
    Smart Array 6i
    Smart Array E200
    Smart Array E200i
    Smart Array E200i
    Smart Array E200i
    Smart Array E200i
    Smart Array E500
    Smart Array P400
    Smart Array P400i
    Smart Array P600
    Smart Array P700m
    Smart Array P800

Configuration details

FILES

Device nodes

Logical drives are accessed via the SCSI disk driver (sd(4)), tape drives via the SCSI tape driver (st(4)), and the RAID controller via the SCSI generic driver (sg(4)), with device nodes named /dev/sd*, /dev/st*, and /dev/sg*, respectively.

HPSA-specific host attribute files in /sys

/sys/class/scsi_host/host*/rescan
This is a write-only attribute. Writing to this attribute will cause the driver to scan for new, changed, or removed devices (e.g., hot-plugged tape drives, or newly configured or deleted logical drives, etc.) and notify the SCSI midlayer of any changes detected. Normally a rescan is triggered automatically by HP’s Array Configuration Utility (either the GUI or the command-line variety); thus, for logical drive changes, the user should not normally have to use this attribute. This attribute may be useful when hot plugging devices like tape drives, or entire storage boxes containing preconfigured logical drives.

/sys/class/scsi_host/host*/firmware_revision
This attribute contains the firmware version of the Smart Array.

For example:

# cd /sys/class/scsi_host/host4
# cat firmware_revision
7.14

HPSA-specific disk attribute files in /sys

/sys/class/scsi_disk/c:b:t:l/device/unique_id
This attribute contains a 32 hex-digit unique ID for each logical drive.

For example:

# cd /sys/class/scsi_disk/4:0:0:0/device
# cat unique_id
600508B1001044395355323037570F77

/sys/class/scsi_disk/c:b:t:l/device/raid_level
This attribute contains the RAID level of each logical drive.

For example:

# cd /sys/class/scsi_disk/4:0:0:0/device
# cat raid_level
RAID 0

/sys/class/scsi_disk/c:b:t:l/device/lunid
This attribute contains the 16 hex-digit (8 byte) LUN ID by which a logical drive or physical device can be addressed. c:b:t:l are the controller, bus, target, and lun of the device.

For example:

# cd /sys/class/scsi_disk/4:0:0:0/device
# cat lunid
0x0000004000000000

Supported ioctl() operations

For compatibility with applications written for the cciss(4) driver, many, but not all of the ioctls supported by the cciss(4) driver are also supported by the hpsa driver. The data structures used by these ioctls are described in the Linux kernel source file include/linux/cciss_ioctl.h.

CCISS_DEREGDISK
CCISS_REGNEWDISK
CCISS_REGNEWD
These three ioctls all do exactly the same thing, which is to cause the driver to rescan for new devices. This does exactly the same thing as writing to the hpsa-specific host “rescan” attribute.

CCISS_GETPCIINFO
Returns PCI domain, bus, device, and function and “board ID” (PCI subsystem ID).

CCISS_GETDRIVVER
Returns driver version in three bytes encoded as:

(major_version << 16) | (minor_version << 8) |
    (subminor_version)

CCISS_PASSTHRU
CCISS_BIG_PASSTHRU
Allows “BMIC” and “CISS” commands to be passed through to the Smart Array. These are used extensively by the HP Array Configuration Utility, SNMP storage agents, and so on. See cciss_vol_status at for some examples.

14 - Linux cli command rtc

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command rtc and provides detailed information about the command rtc, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the rtc.

NAME 🖥️ rtc 🖥️

real-time clock

SYNOPSIS

#include <linux/rtc.h>
int ioctl(fd, RTC_request, param);

DESCRIPTION

This is the interface to drivers for real-time clocks (RTCs).

Most computers have one or more hardware clocks which record the current “wall clock” time. These are called “Real Time Clocks” (RTCs). One of these usually has battery backup power so that it tracks the time even while the computer is turned off. RTCs often provide alarms and other interrupts.

All i386 PCs, and ACPI-based systems, have an RTC that is compatible with the Motorola MC146818 chip on the original PC/AT. Today such an RTC is usually integrated into the mainboard’s chipset (south bridge), and uses a replaceable coin-sized backup battery.

Non-PC systems, such as embedded systems built around system-on-chip processors, use other implementations. They usually won’t offer the same functionality as the RTC from a PC/AT.

RTC vs system clock

RTCs should not be confused with the system clock, which is a software clock maintained by the kernel and used to implement gettimeofday(2) and time(2), as well as setting timestamps on files, and so on. The system clock reports seconds and microseconds since a start point, defined to be the POSIX Epoch: 1970-01-01 00:00:00 +0000 (UTC). (One common implementation counts timer interrupts, once per “jiffy”, at a frequency of 100, 250, or 1000 Hz.) That is, it is supposed to report wall clock time, which RTCs also do.

A key difference between an RTC and the system clock is that RTCs run even when the system is in a low power state (including “off”), and the system clock can’t. Until it is initialized, the system clock can only report time since system boot … not since the POSIX Epoch. So at boot time, and after resuming from a system low power state, the system clock will often be set to the current wall clock time using an RTC. Systems without an RTC need to set the system clock using another clock, maybe across the network or by entering that data manually.

RTC functionality

RTCs can be read and written with hwclock(8), or directly with the ioctl(2) requests listed below.

Besides tracking the date and time, many RTCs can also generate interrupts

on every clock update (i.e., once per second);
at periodic intervals with a frequency that can be set to any power-of-2 multiple in the range 2 Hz to 8192 Hz;
on reaching a previously specified alarm time.

Each of those interrupt sources can be enabled or disabled separately. On many systems, the alarm interrupt can be configured as a system wakeup event, which can resume the system from a low power state such as Suspend-to-RAM (STR, called S3 in ACPI systems), Hibernation (called S4 in ACPI systems), or even “off” (called S5 in ACPI systems). On some systems, the battery backed RTC can’t issue interrupts, but another one can.

The /dev/rtc (or /dev/rtc0, /dev/rtc1, etc.) device can be opened only once (until it is closed) and it is read-only. On read(2) and select(2) the calling process is blocked until the next interrupt from that RTC is received. Following the interrupt, the process can read a long integer, of which the least significant byte contains a bit mask encoding the types of interrupt that occurred, while the remaining 3 bytes contain the number of interrupts since the last read(2).

ioctl(2) interface

The following ioctl(2) requests are defined on file descriptors connected to RTC devices:

RTC_RD_TIME
Returns this RTC’s time in the following structure:

struct rtc_time {
    int tm_sec;
    int tm_min;
    int tm_hour;
    int tm_mday;
    int tm_mon;
    int tm_year;
    int tm_wday;     /* unused */
    int tm_yday;     /* unused */
    int tm_isdst;    /* unused */
};

The fields in this structure have the same meaning and ranges as for the tm structure described in gmtime(3). A pointer to this structure should be passed as the third ioctl(2) argument.

RTC_SET_TIME
Sets this RTC’s time to the time specified by the rtc_time structure pointed to by the third ioctl(2) argument. To set the RTC’s time the process must be privileged (i.e., have the CAP_SYS_TIME capability).

RTC_ALM_READ
RTC_ALM_SET
Read and set the alarm time, for RTCs that support alarms. The alarm interrupt must be separately enabled or disabled using the RTC_AIE_ON, RTC_AIE_OFF requests. The third ioctl(2) argument is a pointer to an rtc_time structure. Only the tm_sec, tm_min, and tm_hour fields of this structure are used.

RTC_IRQP_READ
RTC_IRQP_SET
Read and set the frequency for periodic interrupts, for RTCs that support periodic interrupts. The periodic interrupt must be separately enabled or disabled using the RTC_PIE_ON, RTC_PIE_OFF requests. The third ioctl(2) argument is an unsigned long * or an unsigned long, respectively. The value is the frequency in interrupts per second. The set of allowable frequencies is the multiples of two in the range 2 to 8192. Only a privileged process (i.e., one having the CAP_SYS_RESOURCE capability) can set frequencies above the value specified in /proc/sys/dev/rtc/max-user-freq. (This file contains the value 64 by default.)

RTC_AIE_ON
RTC_AIE_OFF
Enable or disable the alarm interrupt, for RTCs that support alarms. The third ioctl(2) argument is ignored.

RTC_UIE_ON
RTC_UIE_OFF
Enable or disable the interrupt on every clock update, for RTCs that support this once-per-second interrupt. The third ioctl(2) argument is ignored.

RTC_PIE_ON
RTC_PIE_OFF
Enable or disable the periodic interrupt, for RTCs that support these periodic interrupts. The third ioctl(2) argument is ignored. Only a privileged process (i.e., one having the CAP_SYS_RESOURCE capability) can enable the periodic interrupt if the frequency is currently set above the value specified in /proc/sys/dev/rtc/max-user-freq.

RTC_EPOCH_READ
RTC_EPOCH_SET
Many RTCs encode the year in an 8-bit register which is either interpreted as an 8-bit binary number or as a BCD number. In both cases, the number is interpreted relative to this RTC’s Epoch. The RTC’s Epoch is initialized to 1900 on most systems but on Alpha and MIPS it might also be initialized to 1952, 1980, or 2000, depending on the value of an RTC register for the year. With some RTCs, these operations can be used to read or to set the RTC’s Epoch, respectively. The third ioctl(2) argument is an unsigned long * or an unsigned long, respectively, and the value returned (or assigned) is the Epoch. To set the RTC’s Epoch the process must be privileged (i.e., have the CAP_SYS_TIME capability).

RTC_WKALM_RD
RTC_WKALM_SET
Some RTCs support a more powerful alarm interface, using these ioctls to read or write the RTC’s alarm time (respectively) with this structure:

struct rtc_wkalrm { unsigned char enabled; unsigned char pending; struct rtc_time time; };

The enabled flag is used to enable or disable the alarm interrupt, or to read its current status; when using these calls, RTC_AIE_ON and RTC_AIE_OFF are not used. The pending flag is used by RTC_WKALM_RD to report a pending interrupt (so it’s mostly useless on Linux, except when talking to the RTC managed by EFI firmware). The time field is as used with RTC_ALM_READ and RTC_ALM_SET except that the tm_mday, tm_mon, and tm_year fields are also valid. A pointer to this structure should be passed as the third ioctl(2) argument.

FILES

/dev/rtc
/dev/rtc0
/dev/rtc1
. . .
RTC special character device files.

/proc/driver/rtc
status of the (first) RTC.

NOTES

When the kernel’s system time is synchronized with an external reference using adjtimex(2) it will update a designated RTC periodically every 11 minutes. To do so, the kernel has to briefly turn off periodic interrupts; this might affect programs using that RTC.

An RTC’s Epoch has nothing to do with the POSIX Epoch which is used only for the system clock.

If the year according to the RTC’s Epoch and the year register is less than 1970 it is assumed to be 100 years later, that is, between 2000 and 2069.

Some RTCs support “wildcard” values in alarm fields, to support scenarios like periodic alarms at fifteen minutes after every hour, or on the first day of each month. Such usage is nonportable; portable user-space code expects only a single alarm interrupt, and will either disable or reinitialize the alarm after receiving it.

Some RTCs support periodic interrupts with periods that are multiples of a second rather than fractions of a second; multiple alarms; programmable output clock signals; nonvolatile memory; and other hardware capabilities that are not currently exposed by this API.

15 - Linux cli command tty

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command tty and provides detailed information about the command tty, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the tty.

NAME 🖥️ tty 🖥️

controlling terminal

DESCRIPTION

The file /dev/tty is a character file with major number 5 and minor number 0, usually with mode 0666 and ownership root:tty. It is a synonym for the controlling terminal of a process, if any.

In addition to the ioctl(2) requests supported by the device that tty refers to, the ioctl(2) request TIOCNOTTY is supported.

TIOCNOTTY

Detach the calling process from its controlling terminal.

If the process is the session leader, then SIGHUP and SIGCONT signals are sent to the foreground process group and all processes in the current session lose their controlling tty.

This ioctl(2) call works only on file descriptors connected to /dev/tty. It is used by daemon processes when they are invoked by a user at a terminal. The process attempts to open /dev/tty. If the open succeeds, it detaches itself from the terminal by using TIOCNOTTY, while if the open fails, it is obviously not attached to a terminal and does not need to detach itself.

FILES

/dev/tty

16 - Linux cli command msr

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command msr and provides detailed information about the command msr, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the msr.

NAME 🖥️ msr 🖥️

x86 CPU MSR access device

DESCRIPTION

/dev/cpu/CPUNUM/msr provides an interface to read and write the model-specific registers (MSRs) of an x86 CPU. CPUNUM is the number of the CPU to access as listed in /proc/cpuinfo.

The register access is done by opening the file and seeking to the MSR number as offset in the file, and then reading or writing in chunks of 8 bytes. An I/O transfer of more than 8 bytes means multiple reads or writes of the same register.

This file is protected so that it can be read and written only by the user root, or members of the group root.

NOTES

The msr driver is not auto-loaded. On modular kernels you might need to use the following command to load it explicitly before use:

$ modprobe msr

17 - Linux cli command console_ioctl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command console_ioctl and provides detailed information about the command console_ioctl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the console_ioctl.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

18 - Linux cli command urandom

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command urandom and provides detailed information about the command urandom, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the urandom.

NAME 🖥️ urandom 🖥️

kernel random number source devices

SYNOPSIS

#include <linux/random.h>
int ioctl(fd, RNDrequest, param);

DESCRIPTION

The character special files /dev/random and /dev/urandom (present since Linux 1.3.30) provide an interface to the kernel’s random number generator. The file /dev/random has major device number 1 and minor device number 8. The file /dev/urandom has major device number 1 and minor device number 9.

The random number generator gathers environmental noise from device drivers and other sources into an entropy pool. The generator also keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool, random numbers are created.

Linux 3.17 and later provides the simpler and safer getrandom(2) interface which requires no special files; see the getrandom(2) manual page for details.

When read, the /dev/urandom device returns random bytes using a pseudorandom number generator seeded from the entropy pool. Reads from this device do not block (i.e., the CPU is not yielded), but can incur an appreciable delay when requesting large amounts of data.

When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. If this is of concern in your application, use getrandom(2) or /dev/random instead.

The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted. It will return random bytes only within the estimated number of bits of fresh noise in the entropy pool, blocking if necessary. /dev/random is suitable for applications that need high quality randomness, and can afford indeterminate delays.

When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered. Since Linux 5.6, the O_NONBLOCK flag is ignored as /dev/random will no longer block except during early boot process. In earlier versions, if open(2) is called for /dev/random with the O_NONBLOCK flag, a subsequent read(2) will not block if the requested number of bytes is not available. Instead, the available bytes are returned. If no byte is available, read(2) will return -1 and errno will be set to EAGAIN.

The O_NONBLOCK flag has no effect when opening /dev/urandom. When calling read(2) for the device /dev/urandom, reads of up to 256 bytes will return as many bytes as are requested and will not be interrupted by a signal handler. Reads with a buffer over this limit may return less than the requested number of bytes or fail with the error EINTR, if interrupted by a signal handler.

Since Linux 3.16, a read(2) from /dev/urandom will return at most 32 MB. A read(2) from /dev/random will return at most 512 bytes (340 bytes before Linux 2.6.12).

Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, but this will not result in a higher entropy count. This means that it will impact the contents read from both files, but it will not make reads from /dev/random faster.

Usage

The /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time; for these applications, getrandom(2) must be used instead, because it will block until the entropy pool is initialized.

If a seed file is saved across reboots as recommended below, the output is cryptographically secure against attackers without local root access as soon as it is reloaded in the boot sequence, and perfectly adequate for network encryption session keys. (All major Linux distributions have saved the seed file across reboots since 2000 at least.) Since reads from /dev/random may block, users will usually want to open it in nonblocking mode (or perform a read with timeout), and provide some sort of user notification if the desired entropy is not immediately available.

Configuration

If your system does not have /dev/random and /dev/urandom created already, they can be created with the following commands:

mknod -m 666 /dev/random c 1 8
mknod -m 666 /dev/urandom c 1 9
chown root:root /dev/random /dev/urandom

When a Linux system starts up without much operator interaction, the entropy pool may be in a fairly predictable state. This reduces the actual amount of noise in the entropy pool below the estimate. In order to counteract this effect, it helps to carry entropy pool information across shut-downs and start-ups. To do this, add the lines to an appropriate script which is run during the Linux system start-up sequence:

echo "Initializing random number generator..."
random_seed=/var/run/random-seed
# Carry a random seed from start-up to start-up
# Load and then save the whole entropy pool
if [ -f $random_seed ]; then
    cat $random_seed >/dev/urandom
else
    touch $random_seed
fi
chmod 600 $random_seed
poolfile=/proc/sys/kernel/random/poolsize
[ -r $poolfile ] && bits=$(cat $poolfile) || bits=4096
bytes=$(expr $bits / 8)
dd if=/dev/urandom of=$random_seed count=1 bs=$bytes

Also, add the following lines in an appropriate script which is run during the Linux system shutdown:

# Carry a random seed from shut-down to start-up
# Save the whole entropy pool
echo "Saving random seed..."
random_seed=/var/run/random-seed
touch $random_seed
chmod 600 $random_seed
poolfile=/proc/sys/kernel/random/poolsize
[ -r $poolfile ] && bits=$(cat $poolfile) || bits=4096
bytes=$(expr $bits / 8)
dd if=/dev/urandom of=$random_seed count=1 bs=$bytes

In the above examples, we assume Linux 2.6.0 or later, where /proc/sys/kernel/random/poolsize returns the size of the entropy pool in bits (see below).

/proc interfaces

The files in the directory /proc/sys/kernel/random (present since Linux 2.3.16) provide additional information about the /dev/random device:

entropy_avail
This read-only file gives the available entropy, in bits. This will be a number in the range 0 to 4096.

poolsize
This file gives the size of the entropy pool. The semantics of this file vary across kernel versions:

Linux 2.4:
This file gives the size of the entropy pool in bytes. Normally, this file will have the value 512, but it is writable, and can be changed to any value for which an algorithm is available. The choices are 32, 64, 128, 256, 512, 1024, or 2048.

Linux 2.6 and later:
This file is read-only, and gives the size of the entropy pool in bits. It contains the value 4096.

read_wakeup_threshold
This file contains the number of bits of entropy required for waking up processes that sleep waiting for entropy from /dev/random. The default is 64.

write_wakeup_threshold
This file contains the number of bits of entropy below which we wake up processes that do a select(2) or poll(2) for write access to /dev/random. These values can be changed by writing to the files.

uuid and boot_id
These read-only files contain random strings like 6fd5a44b-35f4-4ad4-a9b9-6b9be13e1fe9. The former is generated afresh for each read, the latter was generated once.

ioctl(2) interface

The following ioctl(2) requests are defined on file descriptors connected to either /dev/random or /dev/urandom. All requests performed will interact with the input entropy pool impacting both /dev/random and /dev/urandom. The CAP_SYS_ADMIN capability is required for all requests except RNDGETENTCNT.

RNDGETENTCNT
Retrieve the entropy count of the input pool, the contents will be the same as the entropy_avail file under proc. The result will be stored in the int pointed to by the argument.

RNDADDTOENTCNT
Increment or decrement the entropy count of the input pool by the value pointed to by the argument.

RNDGETPOOL
Removed in Linux 2.6.9.

RNDADDENTROPY
Add some additional entropy to the input pool, incrementing the entropy count. This differs from writing to /dev/random or /dev/urandom, which only adds some data but does not increment the entropy count. The following structure is used:

struct rand_pool_info {
    int    entropy_count;
    int    buf_size;
    __u32  buf[0];
};

Here entropy_count is the value added to (or subtracted from) the entropy count, and buf is the buffer of size buf_size which gets added to the entropy pool.

RNDZAPENTCNT
RNDCLEARPOOL
Zero the entropy count of all pools and add some system data (such as wall clock) to the pools.

FILES

/dev/random
/dev/urandom

NOTES

For an overview and comparison of the various interfaces that can be used to obtain randomness, see random(7).

BUGS

During early boot time, reads from /dev/urandom may return data prior to the entropy pool being initialized.

19 - Linux cli command kmem

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command kmem and provides detailed information about the command kmem, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the kmem.

NAME 🖥️ kmem 🖥️

system memory, kernel memory and system ports

DESCRIPTION

/dev/mem is a character device file that is an image of the main memory of the computer. It may be used, for example, to examine (and even patch) the system.

Byte addresses in /dev/mem are interpreted as physical memory addresses. References to nonexistent locations cause errors to be returned.

Examining and patching is likely to lead to unexpected results when read-only or write-only bits are present.

Since Linux 2.6.26, and depending on the architecture, the CONFIG_STRICT_DEVMEM kernel configuration option limits the areas which can be accessed through this file. For example: on x86, RAM access is not allowed but accessing memory-mapped PCI regions is.

It is typically created by:

mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem

The file /dev/kmem is the same as /dev/mem, except that the kernel virtual memory rather than physical memory is accessed. Since Linux 2.6.26, this file is available only if the CONFIG_DEVKMEM kernel configuration option is enabled.

It is typically created by:

mknod -m 640 /dev/kmem c 1 2
chown root:kmem /dev/kmem

/dev/port is similar to /dev/mem, but the I/O ports are accessed.

It is typically created by:

mknod -m 660 /dev/port c 1 4
chown root:kmem /dev/port

FILES

/dev/mem
/dev/kmem
/dev/port

20 - Linux cli command random

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command random and provides detailed information about the command random, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the random.

NAME 🖥️ random 🖥️

kernel random number source devices

SYNOPSIS

#include <linux/random.h>
int ioctl(fd, RNDrequest, param);

DESCRIPTION

Linux 3.17 and later provides the simpler and safer getrandom(2) interface which requires no special files; see the getrandom(2) manual page for details.

When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. If this is of concern in your application, use getrandom(2) or /dev/random instead.

Since Linux 3.16, a read(2) from /dev/urandom will return at most 32 MB. A read(2) from /dev/random will return at most 512 bytes (340 bytes before Linux 2.6.12).

Usage

Configuration

If your system does not have /dev/random and /dev/urandom created already, they can be created with the following commands:

mknod -m 666 /dev/random c 1 8
mknod -m 666 /dev/urandom c 1 9
chown root:root /dev/random /dev/urandom

echo "Initializing random number generator..."
random_seed=/var/run/random-seed
# Carry a random seed from start-up to start-up
# Load and then save the whole entropy pool
if [ -f $random_seed ]; then
    cat $random_seed >/dev/urandom
else
    touch $random_seed
fi
chmod 600 $random_seed
poolfile=/proc/sys/kernel/random/poolsize
[ -r $poolfile ] && bits=$(cat $poolfile) || bits=4096
bytes=$(expr $bits / 8)
dd if=/dev/urandom of=$random_seed count=1 bs=$bytes

Also, add the following lines in an appropriate script which is run during the Linux system shutdown:

# Carry a random seed from shut-down to start-up
# Save the whole entropy pool
echo "Saving random seed..."
random_seed=/var/run/random-seed
touch $random_seed
chmod 600 $random_seed
poolfile=/proc/sys/kernel/random/poolsize
[ -r $poolfile ] && bits=$(cat $poolfile) || bits=4096
bytes=$(expr $bits / 8)
dd if=/dev/urandom of=$random_seed count=1 bs=$bytes

In the above examples, we assume Linux 2.6.0 or later, where /proc/sys/kernel/random/poolsize returns the size of the entropy pool in bits (see below).

/proc interfaces

The files in the directory /proc/sys/kernel/random (present since Linux 2.3.16) provide additional information about the /dev/random device:

entropy_avail
This read-only file gives the available entropy, in bits. This will be a number in the range 0 to 4096.

poolsize
This file gives the size of the entropy pool. The semantics of this file vary across kernel versions:

Linux 2.6 and later:
This file is read-only, and gives the size of the entropy pool in bits. It contains the value 4096.

read_wakeup_threshold
This file contains the number of bits of entropy required for waking up processes that sleep waiting for entropy from /dev/random. The default is 64.

uuid and boot_id
These read-only files contain random strings like 6fd5a44b-35f4-4ad4-a9b9-6b9be13e1fe9. The former is generated afresh for each read, the latter was generated once.

ioctl(2) interface

RNDGETENTCNT
Retrieve the entropy count of the input pool, the contents will be the same as the entropy_avail file under proc. The result will be stored in the int pointed to by the argument.

RNDADDTOENTCNT
Increment or decrement the entropy count of the input pool by the value pointed to by the argument.

RNDGETPOOL
Removed in Linux 2.6.9.

struct rand_pool_info {
    int    entropy_count;
    int    buf_size;
    __u32  buf[0];
};

Here entropy_count is the value added to (or subtracted from) the entropy count, and buf is the buffer of size buf_size which gets added to the entropy pool.

RNDZAPENTCNT
RNDCLEARPOOL
Zero the entropy count of all pools and add some system data (such as wall clock) to the pools.

FILES

/dev/random
/dev/urandom

NOTES

For an overview and comparison of the various interfaces that can be used to obtain randomness, see random(7).

BUGS

During early boot time, reads from /dev/urandom may return data prior to the entropy pool being initialized.

21 - Linux cli command veth

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command veth and provides detailed information about the command veth, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the veth.

NAME 🖥️ veth 🖥️

Virtual Ethernet Device

DESCRIPTION

The veth devices are virtual Ethernet devices. They can act as tunnels between network namespaces to create a bridge to a physical network device in another namespace, but can also be used as standalone network devices.

veth devices are always created in interconnected pairs. A pair can be created using the command:

# ip link add <p1-name> type veth peer name <p2-name>

In the above, p1-name and p2-name are the names assigned to the two connected end points.

Packets transmitted on one device in the pair are immediately received on the other device. When either device is down, the link state of the pair is down.

veth device pairs are useful for combining the network facilities of the kernel together in interesting ways. A particularly interesting use case is to place one end of a veth pair in one network namespace and the other end in another network namespace, thus allowing communication between network namespaces. To do this, one can provide the netns parameter when creating the interfaces:

# ip link add <p1-name> netns <p1-ns> type veth peer <p2-name> netns <p2-ns>

or, for an existing veth pair, move one side to the other namespace:

# ip link set <p2-name> netns <p2-ns>

ethtool(8) can be used to find the peer of a veth network interface, using commands something like:

# ip link add ve_A type veth peer name ve_B   # Create veth pair
# ethtool -S ve_A         # Discover interface index of peer
NIC statistics:
     peer_ifindex: 16
# ip link | grep '^16:'   # Look up interface
16: ve_B@ve_A: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc ...

22 - Linux cli command tty_ioctl

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command tty_ioctl and provides detailed information about the command tty_ioctl, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the tty_ioctl.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

23 - Linux cli command initrd

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command initrd and provides detailed information about the command initrd, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the initrd.

NAME 🖥️ initrd 🖥️

boot loader initialized RAM disk

CONFIGURATION

/dev/initrd is a read-only block device assigned major number 1 and minor number 250. Typically /dev/initrd is owned by root:disk with mode 0400 (read access by root only). If the Linux system does not have /dev/initrd already created, it can be created with the following commands:

mknod -m 400 /dev/initrd b 1 250
chown root:disk /dev/initrd

Also, support for both “RAM disk” and “Initial RAM disk” (e.g., CONFIG_BLK_DEV_RAM=y and CONFIG_BLK_DEV_INITRD=y) must be compiled directly into the Linux kernel to use /dev/initrd. When using /dev/initrd, the RAM disk driver cannot be loaded as a module.

DESCRIPTION

The special file /dev/initrd is a read-only block device. This device is a RAM disk that is initialized (e.g., loaded) by the boot loader before the kernel is started. The kernel then can use /dev/initrd’s contents for a two-phase system boot-up.

In the first boot-up phase, the kernel starts up and mounts an initial root filesystem from the contents of /dev/initrd (e.g., RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device’s contents. After loading the additional modules, a new root filesystem (i.e., the normal root filesystem) is mounted from a different device.

Boot-up operation

When booting up with initrd, the system boots as follows:

The boot loader loads the kernel program and /dev/initrd’s contents into memory.
On kernel startup, the kernel uncompresses and copies the contents of the device /dev/initrd onto device /dev/ram0 and then frees the memory used by /dev/initrd.
The kernel then read-write mounts the device /dev/ram0 as the initial root filesystem.
If the indicated normal root filesystem is also the initial root filesystem (e.g., /dev/ram0) then the kernel skips to the last step for the usual boot sequence.
If the executable file /linuxrc is present in the initial root filesystem, /linuxrc is executed with UID 0. (The file /linuxrc must have executable permission. The file /linuxrc can be any valid executable, including a shell script.)
If /linuxrc is not executed or when /linuxrc terminates, the normal root filesystem is mounted. (If /linuxrc exits with any filesystems mounted on the initial root filesystem, then the behavior of the kernel is UNSPECIFIED. See the NOTES section for the current kernel behavior.)
If the normal root filesystem has a directory /initrd, the device /dev/ram0 is moved from / to /initrd. Otherwise, if the directory /initrd does not exist, the device /dev/ram0 is unmounted. (When moved from / to /initrd, /dev/ram0 is not unmounted and therefore processes can remain running from /dev/ram0. If directory /initrd does not exist on the normal root filesystem and any processes remain running from /dev/ram0 when /linuxrc exits, the behavior of the kernel is UNSPECIFIED. See the NOTES section for the current kernel behavior.)
The usual boot sequence (e.g., invocation of /sbin/init) is performed on the normal root filesystem.

Options

The following boot loader options, when used with initrd, affect the kernel’s boot-up operation:

**initrd=**filename
Specifies the file to load as the contents of /dev/initrd. For LOADLIN this is a command-line option. For LILO you have to use this command in the LILO configuration file /etc/lilo.config. The filename specified with this option will typically be a gzipped filesystem image.

noinitrd
This boot option disables the two-phase boot-up operation. The kernel performs the usual boot sequence as if /dev/initrd was not initialized. With this option, any contents of /dev/initrd loaded into memory by the boot loader contents are preserved. This option permits the contents of /dev/initrd to be any data and need not be limited to a filesystem image. However, device /dev/initrd is read-only and can be read only one time after system startup.

**root=**device-name
Specifies the device to be used as the normal root filesystem. For LOADLIN this is a command-line option. For LILO this is a boot time option or can be used as an option line in the LILO configuration file /etc/lilo.config. The device specified by this option must be a mountable device having a suitable root filesystem.

Changing the normal root filesystem

By default, the kernel’s settings (e.g., set in the kernel file with rdev(8) or compiled into the kernel file), or the boot loader option setting is used for the normal root filesystems. For an NFS-mounted normal root filesystem, one has to use the nfs_root_name and nfs_root_addrs boot options to give the NFS settings. For more information on NFS-mounted root see the kernel documentation file Documentation/filesystems/nfs/nfsroot.txt (or Documentation/filesystems/nfsroot.txt before Linux 2.6.33). For more information on setting the root filesystem see also the LILO and LOADLIN documentation.

It is also possible for the /linuxrc executable to change the normal root device. For /linuxrc to change the normal root device, /proc must be mounted. After mounting /proc, /linuxrc changes the normal root device by writing into the proc files /proc/sys/kernel/real-root-dev, /proc/sys/kernel/nfs-root-name, and /proc/sys/kernel/nfs-root-addrs. For a physical root device, the root device is changed by having /linuxrc write the new root filesystem device number into /proc/sys/kernel/real-root-dev. For an NFS root filesystem, the root device is changed by having /linuxrc write the NFS setting into files /proc/sys/kernel/nfs-root-name and /proc/sys/kernel/nfs-root-addrs and then writing 0xff (e.g., the pseudo-NFS-device number) into file /proc/sys/kernel/real-root-dev. For example, the following shell command line would change the normal root device to /dev/hdb1:

echo 0x365 >/proc/sys/kernel/real-root-dev

For an NFS example, the following shell command lines would change the normal root device to the NFS directory /var/nfsroot on a local networked NFS server with IP number 193.8.232.7 for a system with IP number 193.8.232.2 and named “idefix”:

echo /var/nfsroot >/proc/sys/kernel/nfs-root-name
echo 193.8.232.2:193.8.232.7::255.255.255.0:idefix \
    >/proc/sys/kernel/nfs-root-addrs
echo 255 >/proc/sys/kernel/real-root-dev

Note: The use of /proc/sys/kernel/real-root-dev to change the root filesystem is obsolete. See the Linux kernel source file Documentation/admin-guide/initrd.rst (or Documentation/initrd.txt before Linux 4.10) as well as pivot_root(2) and pivot_root(8) for information on the modern method of changing the root filesystem.

Usage

The main motivation for implementing initrd was to allow for modular kernel configuration at system installation.

A possible system installation scenario is as follows:

The loader program boots from floppy or other media with a minimal kernel (e.g., support for /dev/ram, /dev/initrd, and the ext2 filesystem) and loads /dev/initrd with a gzipped version of the initial filesystem.
The executable /linuxrc determines what is needed to (1) mount the normal root filesystem (i.e., device type, device drivers, filesystem) and (2) the distribution media (e.g., CD-ROM, network, tape, …). This can be done by asking the user, by auto-probing, or by using a hybrid approach.
The executable /linuxrc loads the necessary modules from the initial root filesystem.
The executable /linuxrc creates and populates the root filesystem. (At this stage the normal root filesystem does not have to be a completed system yet.)
The executable /linuxrc sets /proc/sys/kernel/real-root-dev, unmounts /proc, the normal root filesystem and any other filesystems it has mounted, and then terminates.
The kernel then mounts the normal root filesystem.
Now that the filesystem is accessible and intact, the boot loader can be installed.
The boot loader is configured to load into /dev/initrd a filesystem with the set of modules that was used to bring up the system. (e.g., device /dev/ram0 can be modified, then unmounted, and finally, the image is written from /dev/ram0 to a file.)
The system is now bootable and additional installation tasks can be performed.

The key role of /dev/initrd in the above is to reuse the configuration data during normal system operation without requiring initial kernel selection, a large generic kernel or, recompiling the kernel.

A second scenario is for installations where Linux runs on systems with different hardware configurations in a single administrative network. In such cases, it may be desirable to use only a small set of kernels (ideally only one) and to keep the system-specific part of configuration information as small as possible. In this case, create a common file with all needed modules. Then, only the /linuxrc file or a file executed by /linuxrc would be different.

A third scenario is more convenient recovery disks. Because information like the location of the root filesystem partition is not needed at boot time, the system loaded from /dev/initrd can use a dialog and/or auto-detection followed by a possible sanity check.

Last but not least, Linux distributions on CD-ROM may use initrd for easy installation from the CD-ROM. The distribution can use LOADLIN to directly load /dev/initrd from CD-ROM without the need of any floppies. The distribution could also use a LILO boot floppy and then bootstrap a bigger RAM disk via /dev/initrd from the CD-ROM.

FILES

/dev/initrd
/dev/ram0
/linuxrc
/initrd

NOTES

With the current kernel, any filesystems that remain mounted when /dev/ram0 is moved from / to /initrd continue to be accessible. However, the /proc/mounts entries are not updated.
With the current kernel, if directory /initrd does not exist, then /dev/ram0 will not be fully unmounted if /dev/ram0 is used by any process or has any filesystem mounted on it. If /dev/ram0 is not fully unmounted, then /dev/ram0 will remain in memory.
Users of /dev/initrd should not depend on the behavior given in the above notes. The behavior may change in future versions of the Linux kernel.

24 - Linux cli command ptmx

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ptmx and provides detailed information about the command ptmx, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ptmx.

NAME 🖥️ ptmx 🖥️

pseudoterminal master and slave

DESCRIPTION

Before opening the pseudoterminal slave, you must pass the master’s file descriptor to grantpt(3) and unlockpt(3).

Once both the pseudoterminal master and slave are open, the slave provides processes with an interface that is identical to that of a real terminal.

Data written to the slave is presented on the master file descriptor as input. Data written to the master is presented to the slave as input.

Pseudoterminals can also be used to send input to programs that normally refuse to read input from pipes (such as su(1), and passwd(1)).

FILES

/dev/ptmx, /dev/pts/*

NOTES

The Linux support for the above (known as UNIX 98 pseudoterminal naming) is done using the devpts filesystem, which should be mounted on /dev/pts.

25 - Linux cli command smartpqi

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command smartpqi and provides detailed information about the command smartpqi, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the smartpqi.

NAME 🖥️ smartpqi 🖥️

Microchip Smart Storage SCSI driver

SYNOPSIS

modprobe smartpqi [disable_device_id_wildcards={0|1}] [disable_heartbeat={0|1}] [disable_ctrl_shutdown={0|1}] [lockup_action={none|reboot|panic}] [expose_ld_first={0|1}] [hide_vsep={0|1}] [disable_managed_interrupts={0|1}] [ctrl_ready_timeout={0|[30,1800]}]

DESCRIPTION

smartpqi is a SCSI driver for Microchip Smart Storage controllers.

Supported ioctl() operations

For compatibility with applications written for the cciss(4) and hpsa(4) drivers, many, but not all of the ioctl(2) operations supported by the hpsa driver are also supported by the smartpqi driver. The data structures used by these operations are described in the Linux kernel source file include/linux/cciss_ioctl.h.

CCISS_DEREGDISK
CCISS_REGNEWDISK
CCISS_REGNEWD
These operations all do exactly the same thing, which is to cause the driver to re-scan for new devices. This does exactly the same thing as writing to the smartpqi-specific host rescan attribute.

CCISS_GETPCIINFO
This operation returns the PCI domain, bus, device, and function and “board ID” (PCI subsystem ID).

CCISS_GETDRIVVER
This operation returns the driver version in four bytes, encoded as:

(major_version << 28) | (minor_version << 24) |
        (release << 16) | revision

CCISS_PASSTHRU
Allows BMIC and CISS commands to be passed through to the controller.

Boot options

disable_device_id_wildcards={0|1}
Disables support for device ID wildcards. The default value is 0 (wildcards are enabled).

disable_heartbeat={0|1}
Disables support for the controller’s heartbeat check. This parameter is used for debugging purposes. The default value is 0 (the controller’s heartbeat check is enabled).

disable_ctrl_shutdown={0|1}
Disables support for shutting down the controller in the event of a controller lockup. The default value is 0 (controller will be shut down).

lockup_action={none|reboot|panic}
Specifies the action the driver takes when a controller lockup is detected. The default action is none.

parameter	action
none	take controller offline only
reboot	reboot the system
panic	panic the system

expose_ld_first={0|1}
This option exposes logical devices to the OS before physical devices. The default value is 0 (physical devices exposed first).

hide_vsep={0|1}
This option disables exposure of the virtual SEP to the OS. The default value is 0 (virtual SEP is exposed).

disable_managed_interrupts={0|1}
Disables driver utilization of Linux kernel managed interrupts for controllers. The managed interrupts feature automatically distributes interrupts to all available CPUs and assigns SMP affinity. The default value is 0 (managed interrupts enabled).

ctrl_ready_timeout={0|[30,1800]}
This option specifies the timeout in seconds for the driver to wait for the controller to be ready. The valid range is 0 or [30, 1800]. The default value is 0, which causes the driver to use a timeout of 180 seconds.

FILES

Device nodes

Disk drives are accessed via the SCSI disk driver (sd), tape drives via the SCSI tape driver (st), and the RAID controller via the SCSI generic driver (sg), with device nodes named /dev/sd*, /dev/st*, and /dev/sg*, respectively.

SmartPQI-specific host attribute files in /sys

/sys/class/scsi_host/host*/rescan
The host rescan attribute is a write-only attribute. Writing to this attribute will cause the driver to scan for new, changed, or removed devices (e.g., hot-plugged tape drives, or newly configured or deleted logical volumes) and notify the SCSI mid-layer of any changes detected. Usually this action is triggered automatically by configuration changes, so the user should not normally have to write to this file. Doing so may be useful when hot-plugging devices such as tape drives or entire storage boxes containing pre-configured logical volumes.

/sys/class/scsi_host/host*/lockup_action
The host lockup_action attribute is a read/write attribute. This attribute will cause the driver to perform a specific action in the unlikely event that a controller lockup has been detected. See OPTIONS above for an explanation of the lockup_action values.

/sys/class/scsi_host/host*/driver_version
The driver_version attribute is read-only. This attribute contains the smartpqi driver version.

For example:

$ 
cat /sys/class/scsi_host/host1/driver_version
1.1.2-126

/sys/class/scsi_host/host*/firmware_version
The firmware_version attribute is read-only. This attribute contains the controller firmware version.

For example:

$ 
cat /sys/class/scsi_host/host1/firmware_version
1.29-112

/sys/class/scsi_host/host*/model
The model attribute is read-only. This attribute contains the product identification string of the controller.

For example:

$ 
cat /sys/class/scsi_host/host1/model
1100-16i

/sys/class/scsi_host/host*/serial_number
The serial_number attribute is read-only. This attribute contains the unique identification number of the controller.

For example:

$ 
cat /sys/class/scsi_host/host1/serial_number
6A316373777

/sys/class/scsi_host/host*/vendor
The vendor attribute is read-only. This attribute contains the vendor identification string of the controller.

For example:

$ 
cat /sys/class/scsi_host/host1/vendor
Adaptec

/sys/class/scsi_host/host*/enable_stream_detection
The enable_stream_detection attribute is read-write. This attribute enables/disables stream detection in the driver. Enabling stream detection can improve sequential write performance for ioaccel-enabled volumes. See the ssd_smart_path_enabled disk attribute section for details on ioaccel-enabled volumes. The default value is 1 (stream detection enabled).

Enable example:

$ 
echo 1 > /sys/class/scsi_host/host1/enable_stream_detection

/sys/class/scsi_host/host*/enable_r5_writes
The enable_r5_writes attribute is read-write. This attribute enables/disables RAID 5 write operations for ioaccel-enabled volumes. Enabling can improve sequential write performance. See the ssd_smart_path_enabled disk attribute section for details on ioaccel-enabled volumes. The default value is 1 (RAID 5 writes enabled).

Enable example:

$ 
echo 1 > /sys/class/scsi_host/host1/enable_r5_writes

/sys/class/scsi_host/host*/enable_r6_writes
The enable_r6_writes attribute is read-write. This attribute enables/disables RAID 6 write operations for ioaccel-enabled volumes. Enabling can improve sequential write performance. See the ssd_smart_path_enabled disk attribute section for details on ioaccel-enabled volumes. The default value is 1 (RAID 6 writes enabled).

Enable example:

$ 
echo 1 > /sys/class/scsi_host/host1/enable_r6_writes

SmartPQI-specific disk attribute files in /sys

In the file specifications below, c stands for the number of the appropriate SCSI controller, b is the bus number, t the target number, and l is the logical unit number (LUN).

/sys/class/scsi_disk/c:b:t:l/device/raid_level
The raid_level attribute is read-only. This attribute contains the RAID level of the logical volume.

For example:

$ 
cat /sys/class/scsi_disk/4:0:0:0/device/raid_level
RAID 0

/sys/class/scsi_disk/c:b:t:l/device/sas_address
The sas_address attribute is read-only. This attribute contains the SAS address of the device.

For example:

$ 
cat /sys/class/scsi_disk/1:0:3:0/device/sas_address
0x5001173d028543a2

/sys/class/scsi_disk/c:b:t:l/device/ssd_smart_path_enabled
The ssd_smart_path_enabled attribute is read-only. This attribute is for ioaccel-enabled volumes. (Ioaccel is an alternative driver submission path that allows the driver to send I/O requests directly to backend SCSI devices, bypassing the controller firmware. This results in an increase in performance. This method is used for HBA disks and for logical volumes comprised of SSDs.) Contains 1 if ioaccel is enabled for the volume and 0 otherwise.

For example:

$ 
cat /sys/class/scsi_disk/1:0:3:0/device/ssd_smart_path_enabled
0

/sys/class/scsi_disk/c:b:t:l/device/lunid
The lunid attribute is read-only. This attribute contains the SCSI LUN ID for the device.

For example:

$ 
cat /sys/class/scsi_disk/13:1:0:3/device/lunid
0x0300004000000000

/sys/class/scsi_disk/c:b:t:l/device/unique_id
The unique_id attribute is read-only. This attribute contains a 16-byte ID that uniquely identifies the device within the controller.

For example:

$ 
cat /sys/class/scsi_disk/13:1:0:3/device/unique_id
600508B1001C6D4723A8E98D704FDB94

/sys/class/scsi_disk/c:b:t:l/device/path_info
The path_info attribute is read-only. This attribute contains the c:b:t:l of the device along with the device type and whether the device is Active or Inactive. If the device is an HBA device, path_info will also display the PORT, BOX, and BAY the device is plugged into.

For example:

$ 
cat /sys/class/scsi_disk/13:1:0:3/device/path_info
[13:1:0:3]    Direct-Access     Active
$ 
cat /sys/class/scsi_disk/12:0:9:0/device/path_info
[12:0:9:0]  Direct-Access   PORT: C1 BOX: 1 BAY: 14 Inactive
[12:0:9:0]  Direct-Access   PORT: C0 BOX: 1 BAY: 14 Active

/sys/class/scsi_disk/c:b:t:l/device/raid_bypass_cnt
The raid_bypass_cnt attribute is read-only. This attribute contains the number of I/O requests that have gone through the ioaccel path for ioaccel-enabled volumes. See the ssd_smart_path_enabled disk attribute section for details on ioaccel-enabled volumes.

For example:

$ 
cat /sys/class/scsi_disk/13:1:0:3/device/raid_bypass_cnt
0x300

/sys/class/scsi_disk/c:b:t:l/device/sas_ncq_prio_enable
The sas_ncq_prio_enable attribute is read/write. This attribute enables SATA NCQ priority support. This attribute works only when device has NCQ support and controller firmware can handle IO with NCQ priority attribute.

For example:

$ 
echo 1 > /sys/class/scsi_disk/13:1:0:3/device/sas_ncq_prio_enable

VERSIONS

The smartpqi driver was added in Linux 4.9.

NOTES

Configuration

To configure a Microchip Smart Storage controller, refer to the User Guide for the controller, which can be found by searching for the specific controller at .

HISTORY

/sys/class/scsi_host/host*/version was replaced by two sysfs entries:

/sys/class/scsi_host/host*/driver_version

/sys/class/scsi_host/host*/firmware_version

26 - Linux cli command null

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command null and provides detailed information about the command null, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the null.

NAME 🖥️ null 🖥️

data sink

DESCRIPTION

Data written to the /dev/null and /dev/zero special files is discarded.

Reads from /dev/null always return end of file (i.e., read(2) returns 0), whereas reads from /dev/zero always return bytes containing zero (‘�’ characters).

These devices are typically created by:

mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/zero c 1 5
chown root:root /dev/null /dev/zero

FILES

/dev/null
/dev/zero

NOTES

If these devices are not writable and readable for all users, many programs will act strangely.

Since Linux 2.6.31, reads from /dev/zero are interruptible by signals. (This change was made to help with bad latencies for large reads from /dev/zero.)

27 - Linux cli command mouse

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mouse and provides detailed information about the command mouse, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mouse.

NAME 🖥️ mouse 🖥️

serial mouse interface

CONFIGURATION

Serial mice are connected to a serial RS232/V24 dialout line, see ttyS(4) for a description.

DESCRIPTION

Introduction

The pinout of the usual 9 pin plug as used for serial mice is:

pin	name	used for
2	RX	Data
3	TX	-12 V, Imax = 10 mA
4	DTR	+12 V, Imax = 10 mA
7	RTS	+12 V, Imax = 10 mA
5	GND	Ground

This is the specification, in fact 9 V suffices with most mice.

The mouse driver can recognize a mouse by dropping RTS to low and raising it again. About 14 ms later the mouse will send 0x4D (‘M’) on the data line. After a further 63 ms, a Microsoft-compatible 3-button mouse will send 0x33 (‘3’).

The relative mouse movement is sent as dx (positive means right) and dy (positive means down). Various mice can operate at different speeds. To select speeds, cycle through the speeds 9600, 4800, 2400, and 1200 bit/s, each time writing the two characters from the table below and waiting 0.1 seconds. The following table shows available speeds and the strings that select them:

bit/s	string
9600	*q
4800	*p
2400	*o
1200	*n

The first byte of a data packet can be used for synchronization purposes.

Microsoft protocol

The Microsoft protocol uses 1 start bit, 7 data bits, no parity and one stop bit at the speed of 1200 bits/sec. Data is sent to RxD in 3-byte packets. The dx and dy movements are sent as two’s-complement, lb (rb) are set when the left (right) button is pressed:

byte	d6	d5	d4	d3	d2	d1	d0
1	1	lb	rb	dy7	dy6	dx7	dx6
2	0	dx5	dx4	dx3	dx2	dx1	dx0
3	0	dy5	dy4	dy3	dy2	dy1	dy0

3-button Microsoft protocol

Original Microsoft mice only have two buttons. However, there are some three button mice which also use the Microsoft protocol. Pressing or releasing the middle button is reported by sending a packet with zero movement and no buttons pressed. (Thus, unlike for the other two buttons, the status of the middle button is not reported in each packet.)

Logitech protocol

Logitech serial 3-button mice use a different extension of the Microsoft protocol: when the middle button is up, the above 3-byte packet is sent. When the middle button is down a 4-byte packet is sent, where the 4th byte has value 0x20 (or at least has the 0x20 bit set). In particular, a press of the middle button is reported as 0,0,0,0x20 when no other buttons are down.

Mousesystems protocol

The Mousesystems protocol uses 1 start bit, 8 data bits, no parity, and two stop bits at the speed of 1200 bits/sec. Data is sent to RxD in 5-byte packets. dx is sent as the sum of the two two’s-complement values, dy is send as negated sum of the two two’s-complement values. lb (mb, rb) are cleared when the left (middle, right) button is pressed:

byte	d7	d6	d5	d4	d3	d2	d1	d0
1	1	0	0	0	0	lb	mb	rb
2	0	dxa6	dxa5	dxa4	dxa3	dxa2	dxa1	dxa0
3	0	dya6	dya5	dya4	dya3	dya2	dya1	dya0
4	0	dxb6	dxb5	dxb4	dxb3	dxb2	dxb1	dxb0
5	0	dyb6	dyb5	dyb4	dyb3	dyb2	dyb1	dyb0

Bytes 4 and 5 describe the change that occurred since bytes 2 and 3 were transmitted.

Sun protocol

The Sun protocol is the 3-byte version of the above 5-byte Mousesystems protocol: the last two bytes are not sent.

MM protocol

The MM protocol uses 1 start bit, 8 data bits, odd parity, and one stop bit at the speed of 1200 bits/sec. Data is sent to RxD in 3-byte packets. dx and dy are sent as single signed values, the sign bit indicating a negative value. lb (mb, rb) are set when the left (middle, right) button is pressed:

byte	d7	d6	d5	d4	d3	d2	d1	d0
1	1	0	0	dxs	dys	lb	mb	rb
2	0	dx6	dx5	dx4	dx3	dx2	dx1	dx0
3	0	dy6	dy5	dy4	dy3	dy2	dy1	dy0

FILES

/dev/mouse
A commonly used symbolic link pointing to a mouse device.

28 - Linux cli command console_codes

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command console_codes and provides detailed information about the command console_codes, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the console_codes.

NAME 🖥️ console_codes 🖥️

Linux console escape and control sequences

DESCRIPTION

The Linux console implements a large subset of the VT102 and ECMA-48 / ISO/IEC 6429 / ANSI X3.64 terminal controls, plus certain private-mode sequences for changing the color palette, character-set mapping, and so on. In the tabular descriptions below, the second column gives ECMA-48 or DEC mnemonics (the latter if prefixed with DEC) for the given function. Sequences without a mnemonic are neither ECMA-48 nor VT102.

After all the normal output processing has been done, and a stream of characters arrives at the console driver for actual printing, the first thing that happens is a translation from the code used for processing to the code used for printing.

If the console is in UTF-8 mode, then the incoming bytes are first assembled into 16-bit Unicode codes. Otherwise, each byte is transformed according to the current mapping table (which translates it to a Unicode value). See the Character Sets section below for discussion.

In the normal case, the Unicode value is converted to a font index, and this is stored in video memory, so that the corresponding glyph (as found in video ROM) appears on the screen. Note that the use of Unicode (and the design of the PC hardware) allows us to use 512 different glyphs simultaneously.

If the current Unicode value is a control character, or we are currently processing an escape sequence, the value will treated specially. Instead of being turned into a font index and rendered as a glyph, it may trigger cursor movement or other control functions. See the Linux Console Controls section below for discussion.

It is generally not good practice to hard-wire terminal controls into programs. Linux supports a terminfo(5) database of terminal capabilities. Rather than emitting console escape sequences by hand, you will almost always want to use a terminfo-aware screen library or utility such as ncurses(3), tput(1), or reset(1).

Linux console controls

This section describes all the control characters and escape sequences that invoke special functions (i.e., anything other than writing a glyph at the current cursor location) on the Linux console.

Control characters

A character is a control character if (before transformation according to the mapping table) it has one of the 14 codes 00 (NUL), 07 (BEL), 08 (BS), 09 (HT), 0a (LF), 0b (VT), 0c (FF), 0d (CR), 0e (SO), 0f (SI), 18 (CAN), 1a (SUB), 1b (ESC), 7f (DEL). One can set a “display control characters” mode (see below), and allow 07, 09, 0b, 18, 1a, 7f to be displayed as glyphs. On the other hand, in UTF-8 mode all codes 00–1f are regarded as control characters, regardless of any “display control characters” mode.

If we have a control character, it is acted upon immediately and then discarded (even in the middle of an escape sequence) and the escape sequence continues with the next character. (However, ESC starts a new escape sequence, possibly aborting a previous unfinished one, and CAN and SUB abort any escape sequence.) The recognized control characters are BEL, BS, HT, LF, VT, FF, CR, SO, SI, CAN, SUB, ESC, DEL, CSI. They do what one would expect:

BEL (0x07, ^G)
beeps;

BS (0x08, ^H)
backspaces one column (but not past the beginning of the line);

HT (0x09, ^I)
goes to the next tab stop or to the end of the line if there is no earlier tab stop;

LF (0x0A, ^J)
VT (0x0B, ^K)
FF (0x0C, ^L)
all give a linefeed, and if LF/NL (new-line mode) is set also a carriage return;

CR (0x0D, ^M)
gives a carriage return;

SO (0x0E, ^N)
activates the G1 character set;

SI (0x0F, ^O)
activates the G0 character set;

CAN (0x18, ^X)
SUB (0x1A, ^Z)
abort escape sequences;

ESC (0x1B, ^[)
starts an escape sequence;

DEL (0x7F)
is ignored;

CSI (0x9B)
is equivalent to ESC [.

ESC- but not CSI-sequences

ESC c	RIS	Reset.
ESC D	IND	Linefeed.
ESC E	NEL	Newline.
ESC H	HTS	Set tab stop at current column.
ESC M	RI	Reverse linefeed.
ESC Z	DECID	DEC private identification. The kernel returns the string ESC [ ? 6 c, claiming that it is a VT102.
ESC 7	DECSC	Save current state (cursor coordinates, attributes, character sets pointed at by G0, G1).
ESC 8	DECRC	Restore state most recently saved by ESC 7.
ESC %		Start sequence selecting character set
ESC % @		Select default (ISO/IEC 646 / ISO/IEC 8859-1)
ESC % G		Select UTF-8
ESC % 8		Select UTF-8 (obsolete)
ESC # 8	DECALN	DEC screen alignment test - fill screen with E's.
ESC (		Start sequence defining G0 character set (followed by one of B, 0, U, K, as below)
ESC ( B		Select default (ISO/IEC 8859-1 mapping).
ESC ( 0		Select VT100 graphics mapping.
ESC ( U		Select null mapping - straight to character ROM.
ESC ( K		Select user mapping - the map that is loaded by the utility mapscrn(8).
ESC )		Start sequence defining G1 (followed by one of B, 0, U, K, as above).
ESC >	DECPNM	Set numeric keypad mode
ESC =	DECPAM	Set application keypad mode
ESC ]	OSC	Operating System Command prefix.
ESC ] R		Reset palette.
ESC ] P		Set palette, with parameter given in 7 hexadecimal digits nrrggbb after the final P. Here n is the color (0–15), and rrggbb indicates the red/green/blue values (0–255).

ECMA-48 CSI sequences

CSI (or ESC [) is followed by a sequence of parameters, at most NPAR (16), that are decimal numbers separated by semicolons. An empty or absent parameter is taken to be 0. The sequence of parameters may be preceded by a single question mark.

However, after CSI [ (or ESC [ [) a single character is read and this entire sequence is ignored. (The idea is to ignore an echoed function key.)

The action of a CSI sequence is determined by its final character.

@	ICH	Insert the indicated # of blank characters.
A	CUU	Move cursor up the indicated # of rows.
B	CUD	Move cursor down the indicated # of rows.
C	CUF	Move cursor right the indicated # of columns.
D	CUB	Move cursor left the indicated # of columns.
E	CNL	Move cursor down the indicated # of rows, to column 1.
F	CPL	Move cursor up the indicated # of rows, to column 1.
G	CHA	Move cursor to indicated column in current row.
H	CUP	Move cursor to the indicated row, column (origin at 1,1).
J	ED	Erase display (default: from cursor to end of display).
		ESC [ 1 J: erase from start to cursor.
		ESC [ 2 J: erase whole display.
		ESC [ 3 J: erase whole display including scroll-back buffer (since Linux 3.0).
K	EL	Erase line (default: from cursor to end of line).
		ESC [ 1 K: erase from start of line to cursor.
		ESC [ 2 K: erase whole line.
L	IL	Insert the indicated # of blank lines.
M	DL	Delete the indicated # of lines.
P	DCH	Delete the indicated # of characters on current line.
X	ECH	Erase the indicated # of characters on current line.
a	HPR	Move cursor right the indicated # of columns.
c	DA	Answer ESC [ ? 6 c: "I am a VT102".
d	VPA	Move cursor to the indicated row, current column.
e	VPR	Move cursor down the indicated # of rows.
f	HVP	Move cursor to the indicated row, column.
g	TBC	Without parameter: clear tab stop at current position.
		ESC [ 3 g: delete all tab stops.
h	SM	Set Mode (see below).
l	RM	Reset Mode (see below).
m	SGR	Set attributes (see below).
n	DSR	Status report (see below).
q	DECLL	Set keyboard LEDs.
		ESC [ 0 q: clear all LEDs
		ESC [ 1 q: set Scroll Lock LED
		ESC [ 2 q: set Num Lock LED
		ESC [ 3 q: set Caps Lock LED
r	DECSTBM	Set scrolling region; parameters are top and bottom row.
s	?	Save cursor location.
u	?	Restore cursor location.
`	HPA	Move cursor to indicated column in current row.

ECMA-48 Select Graphic Rendition

The ECMA-48 SGR sequence ESC [ parameters m sets display attributes. Several attributes can be set in the same sequence, separated by semicolons. An empty parameter (between semicolons or string initiator or terminator) is interpreted as a zero.

param	result
0	reset all attributes to their defaults
1	set bold
2	set half-bright (simulated with color on a color display)
3	set italic (since Linux 2.6.22; simulated with color on a color display)
4	set underscore (simulated with color on a color display) (the colors used to simulate dim or underline are set using ESC ] ...)
5	set blink
7	set reverse video
10	reset selected mapping, display control flag, and toggle meta flag (ECMA-48 says "primary font").
11	select null mapping, set display control flag, reset toggle meta flag (ECMA-48 says "first alternate font").
12	select null mapping, set display control flag, set toggle meta flag (ECMA-48 says "second alternate font"). The toggle meta flag causes the high bit of a byte to be toggled before the mapping table translation is done.
21	set underline; before Linux 4.17, this value set normal intensity (as is done in many other terminals)
22	set normal intensity
23	italic off (since Linux 2.6.22)
24	underline off
25	blink off
27	reverse video off
30	set black foreground
31	set red foreground
32	set green foreground
33	set brown foreground
34	set blue foreground
35	set magenta foreground
36	set cyan foreground
37	set white foreground
38	256/24-bit foreground color follows, shoehorned into 16 basic colors (before Linux 3.16: set underscore on, set default foreground color)
39	set default foreground color (before Linux 3.16: set underscore off, set default foreground color)
40	set black background
41	set red background
42	set green background
43	set brown background
44	set blue background
45	set magenta background
46	set cyan background
47	set white background
48	256/24-bit background color follows, shoehorned into 8 basic colors
49	set default background color
90..97	set foreground to bright versions of 30..37
100..107	set background, same as 40..47 (bright not supported)

Commands 38 and 48 require further arguments:

;5;x	256 color: values 0..15 are IBGR (black, red, green, ... white), 16..231 a 6x6x6 color cube, 232..255 a grayscale ramp
;2;r;g;b	24-bit color, r/g/b components are in the range 0..255

ECMA-48 Mode Switches

ESC [ 3 h
DECCRM (default off): Display control chars.

ESC [ 4 h
DECIM (default off): Set insert mode.

ESC [ 20 h
LF/NL (default off): Automatically follow echo of LF, VT, or FF with CR.

ECMA-48 Status Report Commands

ESC [ 5 n
Device status report (DSR): Answer is ESC [ 0 n (Terminal OK).

ESC [ 6 n
Cursor position report (CPR): Answer is ESC [ y ; x R, where x,y is the cursor location.

DEC Private Mode (DECSET/DECRST) sequences

These are not described in ECMA-48. We list the Set Mode sequences; the Reset Mode sequences are obtained by replacing the final ‘h’ by ’l’.

ESC [ ? 1 h
DECCKM (default off): When set, the cursor keys send an ESC O prefix, rather than ESC [.

ESC [ ? 3 h
DECCOLM (default off = 80 columns): 80/132 col mode switch. The driver sources note that this alone does not suffice; some user-mode utility such as resizecons(8) has to change the hardware registers on the console video card.

ESC [ ? 5 h
DECSCNM (default off): Set reverse-video mode.

ESC [ ? 6 h
DECOM (default off): When set, cursor addressing is relative to the upper left corner of the scrolling region.

ESC [ ? 7 h
DECAWM (default on): Set autowrap on. In this mode, a graphic character emitted after column 80 (or column 132 of DECCOLM is on) forces a wrap to the beginning of the following line first.

ESC [ ? 8 h
DECARM (default on): Set keyboard autorepeat on.

ESC [ ? 9 h
X10 Mouse Reporting (default off): Set reporting mode to 1 (or reset to 0)—see below.

ESC [ ? 25 h
DECTECM (default on): Make cursor visible.

ESC [ ? 1000 h
X11 Mouse Reporting (default off): Set reporting mode to 2 (or reset to 0)—see below.

Linux Console Private CSI Sequences

The following sequences are neither ECMA-48 nor native VT102. They are native to the Linux console driver. Colors are in SGR parameters: 0 = black, 1 = red, 2 = green, 3 = brown, 4 = blue, 5 = magenta, 6 = cyan, 7 = white; 8–15 = bright versions of 0–7.

ESC [ 1 ; n ]	Set color n as the underline color.
ESC [ 2 ; n ]	Set color n as the dim color.
ESC [ 8 ]	Make the current color pair the default attributes.
ESC [ 9 ; n ]	Set screen blank timeout to n minutes.
ESC [ 10 ; n ]	Set bell frequency in Hz.
ESC [ 11 ; n ]	Set bell duration in msec.
ESC [ 12 ; n ]	Bring specified console to the front.
ESC [ 13 ]	Unblank the screen.
ESC [ 14 ; n ]	Set the VESA powerdown interval in minutes.
ESC [ 15 ]	Bring the previous console to the front (since Linux 2.6.0).
ESC [ 16 ; n ]	Set the cursor blink interval in milliseconds (since Linux 4.2).

Character sets

The kernel knows about 4 translations of bytes into console-screen symbols. The four tables are: a) Latin1 -> PC, b) VT100 graphics -> PC, c) PC -> PC, d) user-defined.

There are two character sets, called G0 and G1, and one of them is the current character set. (Initially G0.) Typing ^N causes G1 to become current, ^O causes G0 to become current.

These variables G0 and G1 point at a translation table, and can be changed by the user. Initially they point at tables a) and b), respectively. The sequences ESC ( B and ESC ( 0 and ESC ( U and ESC ( K cause G0 to point at translation table a), b), c), and d), respectively. The sequences ESC ) B and ESC ) 0 and ESC ) U and ESC ) K cause G1 to point at translation table a), b), c), and d), respectively.

The sequence ESC c causes a terminal reset, which is what you want if the screen is all garbled. The oft-advised “echo ^V^O” will make only G0 current, but there is no guarantee that G0 points at table a). In some distributions there is a program reset(1) that just does “echo ^[c”. If your terminfo entry for the console is correct (and has an entry rs1=c), then “tput reset” will also work.

The user-defined mapping table can be set using mapscrn(8). The result of the mapping is that if a symbol c is printed, the symbol s = map[c] is sent to the video memory. The bitmap that corresponds to s is found in the character ROM, and can be changed using setfont(8).

Mouse tracking

The mouse tracking facility is intended to return xterm(1)-compatible mouse status reports. Because the console driver has no way to know the device or type of the mouse, these reports are returned in the console input stream only when the virtual terminal driver receives a mouse update ioctl. These ioctls must be generated by a mouse-aware user-mode application such as the gpm(8) daemon.

The mouse tracking escape sequences generated by xterm(1) encode numeric parameters in a single character as value+040. For example, ‘!’ is 1. The screen coordinate system is 1-based.

The X10 compatibility mode sends an escape sequence on button press encoding the location and the mouse button pressed. It is enabled by sending ESC [ ? 9 h and disabled with ESC [ ? 9 l. On button press, xterm(1) sends ESC [ M bxy (6 characters). Here b is button-1, and x and y are the x and y coordinates of the mouse when the button was pressed. This is the same code the kernel also produces.

Normal tracking mode (not implemented in Linux 2.0.24) sends an escape sequence on both button press and release. Modifier information is also sent. It is enabled by sending ESC [ ? 1000 h and disabled with ESC [ ? 1000 l. On button press or release, xterm(1) sends ESC [ M bxy. The low two bits of b encode button information: 0=MB1 pressed, 1=MB2 pressed, 2=MB3 pressed, 3=release. The upper bits encode what modifiers were down when the button was pressed and are added together: 4=Shift, 8=Meta, 16=Control. Again x and y are the x and y coordinates of the mouse event. The upper left corner is (1,1).

Comparisons with other terminals

Many different terminal types are described, like the Linux console, as being “VT100-compatible”. Here we discuss differences between the Linux console and the two most important others, the DEC VT102 and xterm(1).

Control-character handling

The VT102 also recognized the following control characters:

NUL (0x00)
was ignored;

ENQ (0x05)
triggered an answerback message;

DC1 (0x11, ^Q, XON)
resumed transmission;

DC3 (0x13, ^S, XOFF)
caused VT100 to ignore (and stop transmitting) all codes except XOFF and XON.

VT100-like DC1/DC3 processing may be enabled by the terminal driver.

The xterm(1) program (in VT100 mode) recognizes the control characters BEL, BS, HT, LF, VT, FF, CR, SO, SI, ESC.

Escape sequences

VT100 console sequences not implemented on the Linux console:

ESC N	SS2	Single shift 2. (Select G2 character set for the next character only.)
ESC O	SS3	Single shift 3. (Select G3 character set for the next character only.)
ESC P	DCS	Device control string (ended by ESC \)
ESC X	SOS	Start of string.
ESC ^	PM	Privacy message (ended by ESC \)
ESC \	ST	String terminator
ESC * ...		Designate G2 character set
ESC + ...		Designate G3 character set

The program xterm(1) (in VT100 mode) recognizes ESC c, ESC # 8, ESC >, ESC =, ESC D, ESC E, ESC H, ESC M, ESC N, ESC O, ESC P … ESC \ ESC Z (it answers ESC [ ? 1 ; 2 c, “I am a VT100 with advanced video option”) and ESC ^ … ESC \ with the same meanings as indicated above. It accepts ESC (, ESC ), ESC *, ESC + followed by 0, A, B for the DEC special character and line drawing set, UK, and US-ASCII, respectively.

The user can configure xterm(1) to respond to VT220-specific control sequences, and it will identify itself as a VT52, VT100, and up depending on the way it is configured and initialized.

It accepts ESC ] (OSC) for the setting of certain resources. In addition to the ECMA-48 string terminator (ST), xterm(1) accepts a BEL to terminate an OSC string. These are a few of the OSC control sequences recognized by xterm(1):

ESC ] 0 ; txt ST	Set icon name and window title to txt.
ESC ] 1 ; txt ST	Set icon name to txt.
ESC ] 2 ; txt ST	Set window title to txt.
ESC ] 4 ; num; txt ST	Set ANSI color num to txt.
ESC ] 10 ; txt ST	Set dynamic text color to txt.
ESC ] 4 6 ; name ST	Change log file to name (normally disabled by a compile-time option).
ESC ] 5 0 ; fn ST	Set font to fn.

It recognizes the following with slightly modified meaning (saving more state, behaving closer to VT100/VT220):

ESC 7 DECSC	Save cursor
ESC 8 DECRC	Restore cursor

It also recognizes

ESC F		Cursor to lower left corner of screen (if enabled by xterm(1)'s hpLowerleftBugCompat resource).
ESC l		Memory lock (per HP terminals).
		Locks memory above the cursor.
ESC m		Memory unlock (per HP terminals).
ESC n	LS2	Invoke the G2 character set.
ESC o	LS3	Invoke the G3 character set.
ESC \|	LS3R	Invoke the G3 character set as GR.
		Has no visible effect in xterm.
ESC }	LS2R	Invoke the G2 character set as GR.
		Has no visible effect in xterm.
ESC ~	LS1R	Invoke the G1 character set as GR.

It also recognizes ESC % and provides a more complete UTF-8 implementation than Linux console.

CSI Sequences

Old versions of xterm(1), for example, from X11R5, interpret the blink SGR as a bold SGR. Later versions which implemented ANSI colors, for example, XFree86 3.1.2A in 1995, improved this by allowing the blink attribute to be displayed as a color. Modern versions of xterm implement blink SGR as blinking text and still allow colored text as an alternate rendering of SGRs. Stock X11R6 versions did not recognize the color-setting SGRs until the X11R6.8 release, which incorporated XFree86 xterm. All ECMA-48 CSI sequences recognized by Linux are also recognized by xterm, however xterm(1) implements several ECMA-48 and DEC control sequences not recognized by Linux.

The xterm(1) program recognizes all of the DEC Private Mode sequences listed above, but none of the Linux private-mode sequences. For discussion of xterm(1)’s own private-mode sequences, refer to the Xterm Control Sequences document by Edward Moy, Stephen Gildea, and Thomas E. Dickey available with the X distribution. That document, though terse, is much longer than this manual page. For a chronological overview,

details changes to xterm.

The vttest program

demonstrates many of these control sequences. The xterm(1) source distribution also contains sample scripts which exercise other features.

NOTES

ESC 8 (DECRC) is not able to restore the character set changed with ESC %.

BUGS

In Linux 2.0.23, CSI is broken, and NUL is not ignored inside escape sequences.

Some older kernel versions (after Linux 2.0) interpret 8-bit control sequences. These “C1 controls” use codes between 128 and 159 to replace ESC [, ESC ] and similar two-byte control sequence initiators. There are fragments of that in modern kernels (either overlooked or broken by changes to support UTF-8), but the implementation is incomplete and should be regarded as unreliable.

Linux “private mode” sequences do not follow the rules in ECMA-48 for private mode control sequences. In particular, those ending with ] do not use a standard terminating character. The OSC (set palette) sequence is a greater problem, since xterm(1) may interpret this as a control sequence which requires a string terminator (ST). Unlike the setterm(1) sequences which will be ignored (since they are invalid control sequences), the palette sequence will make xterm(1) appear to hang (though pressing the return-key will fix that). To accommodate applications which have been hardcoded to use Linux control sequences, set the xterm(1) resource brokenLinuxOSC to true.

An older version of this document implied that Linux recognizes the ECMA-48 control sequence for invisible text. It is ignored.

29 - Linux cli command st

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command st and provides detailed information about the command st, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the st.

NAME 🖥️ st 🖥️

SCSI tape device

SYNOPSIS

#include <sys/mtio.h>
int ioctl(int fd, int request [, (void *)arg3]);
int ioctl(int fd, MTIOCTOP, (struct mtop *)mt_cmd);
int ioctl(int fd, MTIOCGET, (struct mtget *)mt_status);
int ioctl(int fd, MTIOCPOS, (struct mtpos *)mt_pos);

DESCRIPTION

The st driver provides the interface to a variety of SCSI tape devices. Currently, the driver takes control of all detected devices of type “sequential-access”. The st driver uses major device number 9.

Each device uses eight minor device numbers. The lowermost five bits in the minor numbers are assigned sequentially in the order of detection. In the 2.6 kernel, the bits above the eight lowermost bits are concatenated to the five lowermost bits to form the tape number. The minor numbers can be grouped into two sets of four numbers: the principal (auto-rewind) minor device numbers, n, and the “no-rewind” device numbers, (n + 128). Devices opened using the principal device number will be sent a REWIND command when they are closed. Devices opened using the “no-rewind” device number will not. (Note that using an auto-rewind device for positioning the tape with, for instance, mt does not lead to the desired result: the tape is rewound after the mt command and the next command starts from the beginning of the tape).

Within each group, four minor numbers are available to define devices with different characteristics (block size, compression, density, etc.) When the system starts up, only the first device is available. The other three are activated when the default characteristics are defined (see below). (By changing compile-time constants, it is possible to change the balance between the maximum number of tape drives and the number of minor numbers for each drive. The default allocation allows control of 32 tape drives. For instance, it is possible to control up to 64 tape drives with two minor numbers for different options.)

Devices are typically created by:

mknod -m 666 /dev/st0 c 9 0
mknod -m 666 /dev/st0l c 9 32
mknod -m 666 /dev/st0m c 9 64
mknod -m 666 /dev/st0a c 9 96
mknod -m 666 /dev/nst0 c 9 128
mknod -m 666 /dev/nst0l c 9 160
mknod -m 666 /dev/nst0m c 9 192
mknod -m 666 /dev/nst0a c 9 224

There is no corresponding block device.

The driver uses an internal buffer that has to be large enough to hold at least one tape block. Before Linux 2.1.121, the buffer is allocated as one contiguous block. This limits the block size to the largest contiguous block of memory the kernel allocator can provide. The limit is currently 128 kB for 32-bit architectures and 256 kB for 64-bit architectures. In newer kernels the driver allocates the buffer in several parts if necessary. By default, the maximum number of parts is 16. This means that the maximum block size is very large (2 MB if allocation of 16 blocks of 128 kB succeeds).

The driver’s internal buffer size is determined by a compile-time constant which can be overridden with a kernel startup option. In addition to this, the driver tries to allocate a larger temporary buffer at run time if necessary. However, run-time allocation of large contiguous blocks of memory may fail and it is advisable not to rely too much on dynamic buffer allocation before Linux 2.1.121 (this applies also to demand-loading the driver with kerneld or kmod).

The driver does not specifically support any tape drive brand or model. After system start-up the tape device options are defined by the drive firmware. For example, if the drive firmware selects fixed-block mode, the tape device uses fixed-block mode. The options can be changed with explicit ioctl(2) calls and remain in effect when the device is closed and reopened. Setting the options affects both the auto-rewind and the nonrewind device.

Different options can be specified for the different devices within the subgroup of four. The options take effect when the device is opened. For example, the system administrator can define one device that writes in fixed-block mode with a certain block size, and one which writes in variable-block mode (if the drive supports both modes).

The driver supports tape partitions if they are supported by the drive. (Note that the tape partitions have nothing to do with disk partitions. A partitioned tape can be seen as several logical tapes within one medium.) Partition support has to be enabled with an ioctl(2). The tape location is preserved within each partition across partition changes. The partition used for subsequent tape operations is selected with an ioctl(2). The partition switch is executed together with the next tape operation in order to avoid unnecessary tape movement. The maximum number of partitions on a tape is defined by a compile-time constant (originally four). The driver contains an ioctl(2) that can format a tape with either one or two partitions.

Device /dev/tape is usually created as a hard or soft link to the default tape device on the system.

Starting from Linux 2.6.2, the driver exports in the sysfs directory /sys/class/scsi_tape the attached devices and some parameters assigned to the devices.

Data transfer

The driver supports operation in both fixed-block mode and variable-block mode (if supported by the drive). In fixed-block mode the drive writes blocks of the specified size and the block size is not dependent on the byte counts of the write system calls. In variable-block mode one tape block is written for each write call and the byte count determines the size of the corresponding tape block. Note that the blocks on the tape don’t contain any information about the writing mode: when reading, the only important thing is to use commands that accept the block sizes on the tape.

In variable-block mode the read byte count does not have to match the tape block size exactly. If the byte count is larger than the next block on tape, the driver returns the data and the function returns the actual block size. If the block size is larger than the byte count, an error is returned.

In fixed-block mode the read byte counts can be arbitrary if buffering is enabled, or a multiple of the tape block size if buffering is disabled. Before Linux 2.1.121 allow writes with arbitrary byte count if buffering is enabled. In all other cases (before Linux 2.1.121 with buffering disabled or newer kernel) the write byte count must be a multiple of the tape block size.

In Linux 2.6, the driver tries to use direct transfers between the user buffer and the device. If this is not possible, the driver’s internal buffer is used. The reasons for not using direct transfers include improper alignment of the user buffer (default is 512 bytes but this can be changed by the HBA driver), one or more pages of the user buffer not reachable by the SCSI adapter, and so on.

A filemark is automatically written to tape if the last tape operation before close was a write.

When a filemark is encountered while reading, the following happens. If there are data remaining in the buffer when the filemark is found, the buffered data is returned. The next read returns zero bytes. The following read returns data from the next file. The end of recorded data is signaled by returning zero bytes for two consecutive read calls. The third read returns an error.

Ioctls

The driver supports three ioctl(2) requests. Requests not recognized by the st driver are passed to the SCSI driver. The definitions below are from /usr/include/linux/mtio.h:

MTIOCTOP — perform a tape operation

This request takes an argument of type (struct mtop *). Not all drives support all operations. The driver returns an EIO error if the drive rejects an operation.

/* Structure for MTIOCTOP - mag tape op command: */
struct mtop {
    short   mt_op;       /* operations defined below */
    int     mt_count;    /* how many of them */
};

Magnetic tape operations for normal tape use:

MTBSF
Backward space over mt_count filemarks.

MTBSFM
Backward space over mt_count filemarks. Reposition the tape to the EOT side of the last filemark.

MTBSR
Backward space over mt_count records (tape blocks).

MTBSS
Backward space over mt_count setmarks.

MTCOMPRESSION
Enable compression of tape data within the drive if mt_count is nonzero and disable compression if mt_count is zero. This command uses the MODE page 15 supported by most DATs.

MTEOM
Go to the end of the recorded media (for appending files).

MTERASE
Erase tape. With Linux 2.6, short erase (mark tape empty) is performed if the argument is zero. Otherwise, long erase (erase all) is done.

MTFSF
Forward space over mt_count filemarks.

MTFSFM
Forward space over mt_count filemarks. Reposition the tape to the BOT side of the last filemark.

MTFSR
Forward space over mt_count records (tape blocks).

MTFSS
Forward space over mt_count setmarks.

MTLOAD
Execute the SCSI load command. A special case is available for some HP autoloaders. If mt_count is the constant MT_ST_HPLOADER_OFFSET plus a number, the number is sent to the drive to control the autoloader.

MTLOCK
Lock the tape drive door.

MTMKPART
Format the tape into one or two partitions. If mt_count is positive, it gives the size of partition 1 and partition 0 contains the rest of the tape. If mt_count is zero, the tape is formatted into one partition. From Linux 4.6, a negative mt_count specifies the size of partition 0 and the rest of the tape contains partition 1. The physical ordering of partitions depends on the drive. This command is not allowed for a drive unless the partition support is enabled for the drive (see MT_ST_CAN_PARTITIONS below).

MTNOP
No op—flushes the driver’s buffer as a side effect. Should be used before reading status with MTIOCGET.

MTOFFL
Rewind and put the drive off line.

MTRESET
Reset drive.

MTRETEN
Re-tension tape.

MTREW
Rewind.

MTSEEK
Seek to the tape block number specified in mt_count. This operation requires either a SCSI-2 drive that supports the LOCATE command (device-specific address) or a Tandberg-compatible SCSI-1 drive (Tandberg, Archive Viper, Wangtek, …). The block number should be one that was previously returned by MTIOCPOS if device-specific addresses are used.

MTSETBLK
Set the drive’s block length to the value specified in mt_count. A block length of zero sets the drive to variable block size mode.

MTSETDENSITY
Set the tape density to the code in mt_count. The density codes supported by a drive can be found from the drive documentation.

MTSETPART
The active partition is switched to mt_count. The partitions are numbered from zero. This command is not allowed for a drive unless the partition support is enabled for the drive (see MT_ST_CAN_PARTITIONS below).

MTUNLOAD
Execute the SCSI unload command (does not eject the tape).

MTUNLOCK
Unlock the tape drive door.

MTWEOF
Write mt_count filemarks.

MTWSM
Write mt_count setmarks.

Magnetic tape operations for setting of device options (by the superuser):

MTSETDRVBUFFER
Set various drive and driver options according to bits encoded in mt_count. These consist of the drive’s buffering mode, a set of Boolean driver options, the buffer write threshold, defaults for the block size and density, and timeouts (only since Linux 2.1). A single operation can affect only one item in the list below (the Booleans counted as one item.)

A value having zeros in the high-order 4 bits will be used to set the drive’s buffering mode. The buffering modes are:

0
The drive will not report GOOD status on write commands until the data blocks are actually written to the medium.

1
The drive may report GOOD status on write commands as soon as all the data has been transferred to the drive’s internal buffer.

2
The drive may report GOOD status on write commands as soon as (a) all the data has been transferred to the drive’s internal buffer, and (b) all buffered data from different initiators has been successfully written to the medium.

To control the write threshold the value in mt_count must include the constant MT_ST_WRITE_THRESHOLD bitwise ORed with a block count in the low 28 bits. The block count refers to 1024-byte blocks, not the physical block size on the tape. The threshold cannot exceed the driver’s internal buffer size (see DESCRIPTION, above).

To set and clear the Boolean options the value in mt_count must include one of the constants MT_ST_BOOLEANS, MT_ST_SETBOOLEANS, MT_ST_CLEARBOOLEANS, or MT_ST_DEFBOOLEANS bitwise ORed with whatever combination of the following options is desired. Using MT_ST_BOOLEANS the options can be set to the values defined in the corresponding bits. With MT_ST_SETBOOLEANS the options can be selectively set and with MT_ST_DEFBOOLEANS selectively cleared.

The default options for a tape device are set with MT_ST_DEFBOOLEANS. A nonactive tape device (e.g., device with minor 32 or 160) is activated when the default options for it are defined the first time. An activated device inherits from the device activated at start-up the options not set explicitly.

The Boolean options are:

MT_ST_BUFFER_WRITES (Default: true)
Buffer all write operations in fixed-block mode. If this option is false and the drive uses a fixed block size, then all write operations must be for a multiple of the block size. This option must be set false to write reliable multivolume archives.

MT_ST_ASYNC_WRITES (Default: true)
When this option is true, write operations return immediately without waiting for the data to be transferred to the drive if the data fits into the driver’s buffer. The write threshold determines how full the buffer must be before a new SCSI write command is issued. Any errors reported by the drive will be held until the next operation. This option must be set false to write reliable multivolume archives.

MT_ST_READ_AHEAD (Default: true)
This option causes the driver to provide read buffering and read-ahead in fixed-block mode. If this option is false and the drive uses a fixed block size, then all read operations must be for a multiple of the block size.

MT_ST_TWO_FM (Default: false)
This option modifies the driver behavior when a file is closed. The normal action is to write a single filemark. If the option is true, the driver will write two filemarks and backspace over the second one.

Note: This option should not be set true for QIC tape drives since they are unable to overwrite a filemark. These drives detect the end of recorded data by testing for blank tape rather than two consecutive filemarks. Most other current drives also detect the end of recorded data and using two filemarks is usually necessary only when interchanging tapes with some other systems.

MT_ST_DEBUGGING (Default: false)
This option turns on various debugging messages from the driver (effective only if the driver was compiled with DEBUG defined nonzero).

MT_ST_FAST_EOM (Default: false)
This option causes the MTEOM operation to be sent directly to the drive, potentially speeding up the operation but causing the driver to lose track of the current file number normally returned by the MTIOCGET request. If MT_ST_FAST_EOM is false, the driver will respond to an MTEOM request by forward spacing over files.

MT_ST_AUTO_LOCK (Default: false)
When this option is true, the drive door is locked when the device file is opened and unlocked when it is closed.

MT_ST_DEF_WRITES (Default: false)
The tape options (block size, mode, compression, etc.) may change when changing from one device linked to a drive to another device linked to the same drive depending on how the devices are defined. This option defines when the changes are enforced by the driver using SCSI-commands and when the drives auto-detection capabilities are relied upon. If this option is false, the driver sends the SCSI-commands immediately when the device is changed. If the option is true, the SCSI-commands are not sent until a write is requested. In this case, the drive firmware is allowed to detect the tape structure when reading and the SCSI-commands are used only to make sure that a tape is written according to the correct specification.

MT_ST_CAN_BSR (Default: false)
When read-ahead is used, the tape must sometimes be spaced backward to the correct position when the device is closed and the SCSI command to space backward over records is used for this purpose. Some older drives can’t process this command reliably and this option can be used to instruct the driver not to use the command. The end result is that, with read-ahead and fixed-block mode, the tape may not be correctly positioned within a file when the device is closed. With Linux 2.6, the default is true for drives supporting SCSI-3.

MT_ST_NO_BLKLIMS (Default: false)
Some drives don’t accept the READ BLOCK LIMITS SCSI command. If this is used, the driver does not use the command. The drawback is that the driver can’t check before sending commands if the selected block size is acceptable to the drive.

MT_ST_CAN_PARTITIONS (Default: false)
This option enables support for several partitions within a tape. The option applies to all devices linked to a drive.

MT_ST_SCSI2LOGICAL (Default: false)
This option instructs the driver to use the logical block addresses defined in the SCSI-2 standard when performing the seek and tell operations (both with MTSEEK and MTIOCPOS commands and when changing tape partition). Otherwise, the device-specific addresses are used. It is highly advisable to set this option if the drive supports the logical addresses because they count also filemarks. There are some drives that support only the logical block addresses.

MT_ST_SYSV (Default: false)
When this option is enabled, the tape devices use the System V semantics. Otherwise, the BSD semantics are used. The most important difference between the semantics is what happens when a device used for reading is closed: in System V semantics the tape is spaced forward past the next filemark if this has not happened while using the device. In BSD semantics the tape position is not changed.

MT_NO_WAIT (Default: false)
Enables immediate mode (i.e., don’t wait for the command to finish) for some commands (e.g., rewind).

An example:

struct mtop mt_cmd;
mt_cmd.mt_op = MTSETDRVBUFFER;
mt_cmd.mt_count = MT_ST_BOOLEANS |
        MT_ST_BUFFER_WRITES | MT_ST_ASYNC_WRITES;
ioctl(fd, MTIOCTOP, mt_cmd);

The default block size for a device can be set with MT_ST_DEF_BLKSIZE and the default density code can be set with MT_ST_DEFDENSITY. The values for the parameters are or’ed with the operation code.

With Linux 2.1.x and later, the timeout values can be set with the subcommand MT_ST_SET_TIMEOUT ORed with the timeout in seconds. The long timeout (used for rewinds and other commands that may take a long time) can be set with MT_ST_SET_LONG_TIMEOUT. The kernel defaults are very long to make sure that a successful command is not timed out with any drive. Because of this, the driver may seem stuck even if it is only waiting for the timeout. These commands can be used to set more practical values for a specific drive. The timeouts set for one device apply for all devices linked to the same drive.

Starting from Linux 2.4.19 and Linux 2.5.43, the driver supports a status bit which indicates whether the drive requests cleaning. The method used by the drive to return cleaning information is set using the MT_ST_SEL_CLN subcommand. If the value is zero, the cleaning bit is always zero. If the value is one, the TapeAlert data defined in the SCSI-3 standard is used (not yet implemented). Values 2–17 are reserved. If the lowest eight bits are >= 18, bits from the extended sense data are used. The bits 9–16 specify a mask to select the bits to look at and the bits 17–23 specify the bit pattern to look for. If the bit pattern is zero, one or more bits under the mask indicate the cleaning request. If the pattern is nonzero, the pattern must match the masked sense data byte.

MTIOCGET — get status

This request takes an argument of type (struct mtget *).

/* structure for MTIOCGET - mag tape get status command */
struct mtget {
    long     mt_type;
    long     mt_resid;
    /* the following registers are device dependent */
    long     mt_dsreg;
    long     mt_gstat;
    long     mt_erreg;
    /* The next two fields are not always used */
    daddr_t  mt_fileno;
    daddr_t  mt_blkno;
};

mt_type
The header file defines many values for mt_type, but the current driver reports only the generic types MT_ISSCSI1 (Generic SCSI-1 tape) and MT_ISSCSI2 (Generic SCSI-2 tape).

mt_resid
contains the current tape partition number.

mt_dsreg
reports the drive’s current settings for block size (in the low 24 bits) and density (in the high 8 bits). These fields are defined by MT_ST_BLKSIZE_SHIFT, MT_ST_BLKSIZE_MASK, MT_ST_DENSITY_SHIFT, and MT_ST_DENSITY_MASK.

mt_gstat
reports generic (device independent) status information. The header file defines macros for testing these status bits:

GMT_EOF(x)
The tape is positioned just after a filemark (always false after an MTSEEK operation).

GMT_BOT(x)
The tape is positioned at the beginning of the first file (always false after an MTSEEK operation).

GMT_EOT(x)
A tape operation has reached the physical End Of Tape.

GMT_SM(x)
The tape is currently positioned at a setmark (always false after an MTSEEK operation).

GMT_EOD(x)
The tape is positioned at the end of recorded data.

GMT_WR_PROT(x)
The drive is write-protected. For some drives this can also mean that the drive does not support writing on the current medium type.

GMT_ONLINE(x)
The last open(2) found the drive with a tape in place and ready for operation.

GMT_D_6250(x)
GMT_D_1600(x)
GMT_D_800(x)
This “generic” status information reports the current density setting for 9-track ½" tape drives only.

GMT_DR_OPEN(x)
The drive does not have a tape in place.

GMT_IM_REP_EN(x)
Immediate report mode. This bit is set if there are no guarantees that the data has been physically written to the tape when the write call returns. It is set zero only when the driver does not buffer data and the drive is set not to buffer data.

GMT_CLN(x)
The drive has requested cleaning. Implemented since Linux 2.4.19 and Linux 2.5.43.

mt_erreg
The only field defined in mt_erreg is the recovered error count in the low 16 bits (as defined by MT_ST_SOFTERR_SHIFT and MT_ST_SOFTERR_MASK). Due to inconsistencies in the way drives report recovered errors, this count is often not maintained (most drives do not by default report soft errors but this can be changed with a SCSI MODE SELECT command).

mt_fileno
reports the current file number (zero-based). This value is set to -1 when the file number is unknown (e.g., after MTBSS or MTSEEK).

mt_blkno
reports the block number (zero-based) within the current file. This value is set to -1 when the block number is unknown (e.g., after MTBSF, MTBSS, or MTSEEK).

MTIOCPOS — get tape position

This request takes an argument of type (struct mtpos *) and reports the drive’s notion of the current tape block number, which is not the same as mt_blkno returned by MTIOCGET. This drive must be a SCSI-2 drive that supports the READ POSITION command (device-specific address) or a Tandberg-compatible SCSI-1 drive (Tandberg, Archive Viper, Wangtek, … ).

/* structure for MTIOCPOS - mag tape get position command */
struct mtpos {
    long mt_blkno;    /* current block number */
};

RETURN VALUE

EACCES
An attempt was made to write or erase a write-protected tape. (This error is not detected during open(2).)

EBUSY
The device is already in use or the driver was unable to allocate a buffer.

EFAULT
The command parameters point to memory not belonging to the calling process.

EINVAL
An ioctl(2) had an invalid argument, or a requested block size was invalid.

EIO
The requested operation could not be completed.

ENOMEM
The byte count in read(2) is smaller than the next physical block on the tape. (Before Linux 2.2.18 and Linux 2.4.0 the extra bytes have been silently ignored.)

ENOSPC
A write operation could not be completed because the tape reached end-of-medium.

ENOSYS
Unknown ioctl(2).

ENXIO
During opening, the tape device does not exist.

EOVERFLOW
An attempt was made to read or write a variable-length block that is larger than the driver’s internal buffer.

EROFS
Open is attempted with O_WRONLY or O_RDWR when the tape in the drive is write-protected.

FILES

/dev/st*
the auto-rewind SCSI tape devices

/dev/nst*
the nonrewind SCSI tape devices

NOTES

When exchanging data between systems, both systems have to agree on the physical tape block size. The parameters of a drive after startup are often not the ones most operating systems use with these devices. Most systems use drives in variable-block mode if the drive supports that mode. This applies to most modern drives, including DATs, 8mm helical scan drives, DLTs, etc. It may be advisable to use these drives in variable-block mode also in Linux (i.e., use MTSETBLK or MTSETDEFBLK at system startup to set the mode), at least when exchanging data with a foreign system. The drawback of this is that a fairly large tape block size has to be used to get acceptable data transfer rates on the SCSI bus.
Many programs (e.g., tar(1)) allow the user to specify the blocking factor on the command line. Note that this determines the physical block size on tape only in variable-block mode.
In order to use SCSI tape drives, the basic SCSI driver, a SCSI-adapter driver and the SCSI tape driver must be either configured into the kernel or loaded as modules. If the SCSI-tape driver is not present, the drive is recognized but the tape support described in this page is not available.
The driver writes error messages to the console/log. The SENSE codes written into some messages are automatically translated to text if verbose SCSI messages are enabled in kernel configuration.
The driver’s internal buffering allows good throughput in fixed-block mode also with small read(2) and write(2) byte counts. With direct transfers this is not possible and may cause a surprise when moving to the 2.6 kernel. The solution is to tell the software to use larger transfers (often telling it to use larger blocks). If this is not possible, direct transfers can be disabled.

30 - Linux cli command fuse

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command fuse and provides detailed information about the command fuse, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the fuse.

NAME 🖥️ fuse 🖥️

Filesystem in Userspace (FUSE) device

SYNOPSIS

#include <linux/fuse.h>

DESCRIPTION

This device is the primary interface between the FUSE filesystem driver and a user-space process wishing to provide the filesystem (referred to in the rest of this manual page as the filesystem daemon). This manual page is intended for those interested in understanding the kernel interface itself. Those implementing a FUSE filesystem may wish to make use of a user-space library such as libfuse that abstracts away the low-level interface.

At its core, FUSE is a simple client-server protocol, in which the Linux kernel is the client and the daemon is the server. After obtaining a file descriptor for this device, the daemon may read(2) requests from that file descriptor and is expected to write(2) back its replies. It is important to note that a file descriptor is associated with a unique FUSE filesystem. In particular, opening a second copy of this device, will not allow access to resources created through the first file descriptor (and vice versa).

The basic protocol

Every message that is read by the daemon begins with a header described by the following structure:

struct fuse_in_header {
    uint32_t len;       /* Total length of the data,
                           including this header */
    uint32_t opcode;    /* The kind of operation (see below) */
    uint64_t unique;    /* A unique identifier for this request */
    uint64_t nodeid;    /* ID of the filesystem object
                           being operated on */
    uint32_t uid;       /* UID of the requesting process */
    uint32_t gid;       /* GID of the requesting process */
    uint32_t pid;       /* PID of the requesting process */
    uint32_t padding;
};

The header is followed by a variable-length data portion (which may be empty) specific to the requested operation (the requested operation is indicated by opcode).

The daemon should then process the request and if applicable send a reply (almost all operations require a reply; if they do not, this is documented below), by performing a write(2) to the file descriptor. All replies must start with the following header:

struct fuse_out_header {
    uint32_t len;       /* Total length of data written to
                           the file descriptor */
    int32_t  error;     /* Any error that occurred (0 if none) */
    uint64_t unique;    /* The value from the
                           corresponding request */
};

This header is also followed by (potentially empty) variable-sized data depending on the executed request. However, if the reply is an error reply (i.e., error is set), then no further payload data should be sent, independent of the request.

Exchanged messages

This section should contain documentation for each of the messages in the protocol. This manual page is currently incomplete, so not all messages are documented. For each message, first the struct sent by the kernel is given, followed by a description of the semantics of the message.

FUSE_INIT
struct fuse_init_in { uint32_t major; uint32_t minor; uint32_t max_readahead; /* Since protocol v7.6 / uint32_t flags; / Since protocol v7.6 */ };

This is the first request sent by the kernel to the daemon. It is used to negotiate the protocol version and other filesystem parameters. Note that the protocol version may affect the layout of any structure in the protocol (including this structure). The daemon must thus remember the negotiated version and flags for each session. As of the writing of this man page, the highest supported kernel protocol version is 7.26.

Users should be aware that the descriptions in this manual page may be incomplete or incorrect for older or more recent protocol versions.

The reply for this request has the following format:

struct fuse_init_out {
    uint32_t major;
    uint32_t minor;
    uint32_t max_readahead;   /* Since v7.6 */
    uint32_t flags;           /* Since v7.6; some flags bits
                                 were introduced later */
    uint16_t max_background;  /* Since v7.13 */
    uint16_t congestion_threshold;  /* Since v7.13 */
    uint32_t max_write;       /* Since v7.5 */
    uint32_t time_gran;       /* Since v7.6 */
    uint32_t unused[9];
};

If the major version supported by the kernel is larger than that supported by the daemon, the reply shall consist of only uint32_t major (following the usual header), indicating the largest major version supported by the daemon. The kernel will then issue a new FUSE_INIT request conforming to the older version. In the reverse case, the daemon should quietly fall back to the kernel’s major version.

The negotiated minor version is considered to be the minimum of the minor versions provided by the daemon and the kernel and both parties should use the protocol corresponding to said minor version.

FUSE_GETATTR
struct fuse_getattr_in { uint32_t getattr_flags; uint32_t dummy; uint64_t fh; /* Set only if (getattr_flags & FUSE_GETATTR_FH) };

The requested operation is to compute the attributes to be returned by stat(2) and similar operations for the given filesystem object. The object for which the attributes should be computed is indicated either by header->nodeid or, if the FUSE_GETATTR_FH flag is set, by the file handle fh. The latter case of operation is analogous to fstat(2).

For performance reasons, these attributes may be cached in the kernel for a specified duration of time. While the cache timeout has not been exceeded, the attributes will be served from the cache and will not cause additional FUSE_GETATTR requests.

The computed attributes and the requested cache timeout should then be returned in the following structure:

struct fuse_attr_out {
    /* Attribute cache duration (seconds + nanoseconds) */
    uint64_t attr_valid;
    uint32_t attr_valid_nsec;
    uint32_t dummy;
    struct fuse_attr {
        uint64_t ino;
        uint64_t size;
        uint64_t blocks;
        uint64_t atime;
        uint64_t mtime;
        uint64_t ctime;
        uint32_t atimensec;
        uint32_t mtimensec;
        uint32_t ctimensec;
        uint32_t mode;
        uint32_t nlink;
        uint32_t uid;
        uint32_t gid;
        uint32_t rdev;
        uint32_t blksize;
        uint32_t padding;
    } attr;
};

FUSE_ACCESS
struct fuse_access_in { uint32_t mask; uint32_t padding; };

If the default_permissions mount options is not used, this request may be used for permissions checking. No reply data is expected, but errors may be indicated as usual by setting the error field in the reply header (in particular, access denied errors may be indicated by returning -EACCES).

FUSE_OPEN and FUSE_OPENDIR
struct fuse_open_in { uint32_t flags; /* The flags that were passed to the open(2) */ uint32_t unused; };

The requested operation is to open the node indicated by header->nodeid. The exact semantics of what this means will depend on the filesystem being implemented. However, at the very least the filesystem should validate that the requested flags are valid for the indicated resource and then send a reply with the following format:

struct fuse_open_out {
    uint64_t fh;
    uint32_t open_flags;
    uint32_t padding;
};

The fh field is an opaque identifier that the kernel will use to refer to this resource The open_flags field is a bit mask of any number of the flags that indicate properties of this file handle to the kernel:

FOPEN_DIRECT_IO
Bypass page cache for this open file.

FOPEN_KEEP_CACHE
Don’t invalidate the data cache on open.

FOPEN_NONSEEKABLE
The file is not seekable.

FUSE_READ and FUSE_READDIR
struct fuse_read_in { uint64_t fh; uint64_t offset; uint32_t size; uint32_t read_flags; uint64_t lock_owner; uint32_t flags; uint32_t padding; };

The requested action is to read up to size bytes of the file or directory, starting at offset. The bytes should be returned directly following the usual reply header.

FUSE_INTERRUPT
struct fuse_interrupt_in { uint64_t unique; };

The requested action is to cancel the pending operation indicated by unique. This request requires no response. However, receipt of this message does not by itself cancel the indicated operation. The kernel will still expect a reply to said operation (e.g., an EINTR error or a short read). At most one FUSE_INTERRUPT request will be issued for a given operation. After issuing said operation, the kernel will wait uninterruptibly for completion of the indicated request.

FUSE_LOOKUP
Directly following the header is a filename to be looked up in the directory indicated by header->nodeid. The expected reply is of the form:

struct fuse_entry_out {
    uint64_t nodeid;            /* Inode ID */
    uint64_t generation;        /* Inode generation */
    uint64_t entry_valid;
    uint64_t attr_valid;
    uint32_t entry_valid_nsec;
    uint32_t attr_valid_nsec;
    struct fuse_attr attr;
};

The combination of nodeid and generation must be unique for the filesystem’s lifetime.

The interpretation of timeouts and attr is as for FUSE_GETATTR.

FUSE_FLUSH
struct fuse_flush_in { uint64_t fh; uint32_t unused; uint32_t padding; uint64_t lock_owner; };

The requested action is to flush any pending changes to the indicated file handle. No reply data is expected. However, an empty reply message still needs to be issued once the flush operation is complete.

FUSE_RELEASE and FUSE_RELEASEDIR
struct fuse_release_in { uint64_t fh; uint32_t flags; uint32_t release_flags; uint64_t lock_owner; };

These are the converse of FUSE_OPEN and FUSE_OPENDIR respectively. The daemon may now free any resources associated with the file handle fh as the kernel will no longer refer to it. There is no reply data associated with this request, but a reply still needs to be issued once the request has been completely processed.

FUSE_STATFS
This operation implements statfs(2) for this filesystem. There is no input data associated with this request. The expected reply data has the following structure:

struct fuse_kstatfs {
    uint64_t blocks;
    uint64_t bfree;
    uint64_t bavail;
    uint64_t files;
    uint64_t ffree;
    uint32_t bsize;
    uint32_t namelen;
    uint32_t frsize;
    uint32_t padding;
    uint32_t spare[6];
};
struct fuse_statfs_out {
    struct fuse_kstatfs st;
};

For the interpretation of these fields, see statfs(2).

ERRORS

E2BIG
Returned from read(2) operations when the kernel’s request is too large for the provided buffer and the request was FUSE_SETXATTR.

EINVAL
Returned from write(2) if validation of the reply failed. Not all mistakes in replies will be caught by this validation. However, basic mistakes, such as short replies or an incorrect unique value, are detected.

EIO
Returned from read(2) operations when the kernel’s request is too large for the provided buffer.

Note: There are various ways in which incorrect use of these interfaces can cause operations on the provided filesystem’s files and directories to fail with EIO. Among the possible incorrect uses are:

changing mode & S_IFMT for an inode that has previously been reported to the kernel; or
giving replies to the kernel that are shorter than what the kernel expected.

ENODEV
Returned from read(2) and write(2) if the FUSE filesystem was unmounted.

EPERM
Returned from operations on a /dev/fuse file descriptor that has not been mounted.

STANDARDS

Linux.

NOTES

The following messages are not yet documented in this manual page:

FUSE_BATCH_FORGET
FUSE_BMAP
FUSE_CREATE
FUSE_DESTROY
FUSE_FALLOCATE
FUSE_FORGET
FUSE_FSYNC
FUSE_FSYNCDIR
FUSE_GETLK
FUSE_GETXATTR
FUSE_IOCTL
FUSE_LINK
FUSE_LISTXATTR
FUSE_LSEEK
FUSE_MKDIR
FUSE_MKNOD
FUSE_NOTIFY_REPLY
FUSE_POLL
FUSE_READDIRPLUS
FUSE_READLINK
FUSE_REMOVEXATTR
FUSE_RENAME
FUSE_RENAME2
FUSE_RMDIR
FUSE_SETATTR
FUSE_SETLK
FUSE_SETLKW
FUSE_SYMLINK
FUSE_UNLINK
FUSE_WRITE

31 - Linux cli command port

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command port and provides detailed information about the command port, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the port.

NAME 🖥️ port 🖥️

system memory, kernel memory and system ports

DESCRIPTION

/dev/mem is a character device file that is an image of the main memory of the computer. It may be used, for example, to examine (and even patch) the system.

Byte addresses in /dev/mem are interpreted as physical memory addresses. References to nonexistent locations cause errors to be returned.

Examining and patching is likely to lead to unexpected results when read-only or write-only bits are present.

It is typically created by:

mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem

It is typically created by:

mknod -m 640 /dev/kmem c 1 2
chown root:kmem /dev/kmem

/dev/port is similar to /dev/mem, but the I/O ports are accessed.

It is typically created by:

mknod -m 660 /dev/port c 1 4
chown root:kmem /dev/port

FILES

/dev/mem
/dev/kmem
/dev/port

32 - Linux cli command dsp56k

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command dsp56k and provides detailed information about the command dsp56k, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the dsp56k.

NAME 🖥️ dsp56k 🖥️

DSP56001 interface device

SYNOPSIS

#include <asm/dsp56k.h>
ssize_t read(int fd, void *data, size_t length);
ssize_t write(int fd, void *data, size_t length);
int ioctl(int fd, DSP56K_UPLOAD, struct dsp56k_upload *program);
int ioctl(int fd, DSP56K_SET_TX_WSIZE, int wsize);
int ioctl(int fd, DSP56K_SET_RX_WSIZE, int wsize);
int ioctl(int fd, DSP56K_HOST_FLAGS, struct dsp56k_host_flags *flags);
int ioctl(int fd, DSP56K_HOST_CMD, int cmd);

CONFIGURATION

The dsp56k device is a character device with major number 55 and minor number 0.

DESCRIPTION

The Motorola DSP56001 is a fully programmable 24-bit digital signal processor found in Atari Falcon030-compatible computers. The dsp56k special file is used to control the DSP56001, and to send and receive data using the bidirectional handshaked host port.

To send a data stream to the signal processor, use write(2) to the device, and read(2) to receive processed data. The data can be sent or received in 8, 16, 24, or 32-bit quantities on the host side, but will always be seen as 24-bit quantities in the DSP56001.

The following ioctl(2) calls are used to control the dsp56k device:

DSP56K_UPLOAD
resets the DSP56001 and uploads a program. The third ioctl(2) argument must be a pointer to a struct dsp56k_upload with members bin pointing to a DSP56001 binary program, and len set to the length of the program, counted in 24-bit words.

DSP56K_SET_TX_WSIZE
sets the transmit word size. Allowed values are in the range 1 to 4, and is the number of bytes that will be sent at a time to the DSP56001. These data quantities will either be padded with bytes containing zero, or truncated to fit the native 24-bit data format of the DSP56001.

DSP56K_SET_RX_WSIZE
sets the receive word size. Allowed values are in the range 1 to 4, and is the number of bytes that will be received at a time from the DSP56001. These data quantities will either truncated, or padded with a null byte (‘�’), to fit the native 24-bit data format of the DSP56001.

DSP56K_HOST_FLAGS
read and write the host flags. The host flags are four general-purpose bits that can be read by both the hosting computer and the DSP56001. Bits 0 and 1 can be written by the host, and bits 2 and 3 can be written by the DSP56001.

To access the host flags, the third ioctl(2) argument must be a pointer to a struct dsp56k_host_flags. If bit 0 or 1 is set in the dir member, the corresponding bit in out will be written to the host flags. The state of all host flags will be returned in the lower four bits of the status member.

DSP56K_HOST_CMD
sends a host command. Allowed values are in the range 0 to 31, and is a user-defined command handled by the program running in the DSP56001.

FILES

/dev/dsp56k

33 - Linux cli command full

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command full and provides detailed information about the command full, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the full.

NAME 🖥️ full 🖥️

always full device

CONFIGURATION

If your system does not have /dev/full created already, it can be created with the following commands:

mknod -m 666 /dev/full c 1 7
chown root:root /dev/full

DESCRIPTION

The file /dev/full has major device number 1 and minor device number 7.

Writes to the /dev/full device fail with an ENOSPC error. This can be used to test how a program handles disk-full errors.

Reads from the /dev/full device will return � characters.

Seeks on /dev/full will always succeed.

FILES

/dev/full

34 - Linux cli command loop

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command loop and provides detailed information about the command loop, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the loop.

NAME 🖥️ loop 🖥️

control - loop devices

SYNOPSIS

#include <linux/loop.h>

DESCRIPTION

$ dd if=/dev/zero of=file.img bs=1MiB count=10
$ sudo losetup /dev/loop4 file.img
$ sudo mkfs -t ext4 /dev/loop4
$ sudo mkdir /myloopdev
$ sudo mount /dev/loop4 /myloopdev

See losetup(8) for another example.

A transfer function can be specified for each loop device for encryption and decryption purposes.

The following ioctl(2) operations are provided by the loop block device:

LOOP_SET_FD
Associate the loop device with the open file whose file descriptor is passed as the (third) ioctl(2) argument.

LOOP_CLR_FD
Disassociate the loop device from any file descriptor.

LOOP_SET_STATUS
Set the status of the loop device using the (third) ioctl(2) argument. This argument is a pointer to a loop_info structure, defined in <linux/loop.h> as:

struct loop_info {
    int           lo_number;      /* ioctl r/o */
    dev_t         lo_device;      /* ioctl r/o */
    unsigned long lo_inode;       /* ioctl r/o */
    dev_t         lo_rdevice;     /* ioctl r/o */
    int           lo_offset;
    int           lo_encrypt_type;
    int           lo_encrypt_key_size;  /* ioctl w/o */
    int           lo_flags;       /* ioctl r/w (r/o before
                                     Linux 2.6.25) */
    char          lo_name[LO_NAME_SIZE];
    unsigned char lo_encrypt_key[LO_KEY_SIZE];
                                  /* ioctl w/o */
    unsigned long lo_init[2];
    char          reserved[4];
};

The lo_flags field is a bit mask that can include zero or more of the following:

LO_FLAGS_READ_ONLY
The loopback device is read-only.

LO_FLAGS_AUTOCLEAR (since Linux 2.6.25)
The loopback device will autodestruct on last close.

LO_FLAGS_PARTSCAN (since Linux 3.2)
Allow automatic partition scanning.

LO_FLAGS_DIRECT_IO (since Linux 4.10)
Use direct I/O mode to access the backing file.

The only lo_flags that can be modified by LOOP_SET_STATUS are LO_FLAGS_AUTOCLEAR and LO_FLAGS_PARTSCAN.

LOOP_GET_STATUS
Get the status of the loop device. The (third) ioctl(2) argument must be a pointer to a struct loop_info.

struct loop_config {
    __u32               fd;
    __u32               block_size;
    struct loop_info64  info;
    __u64               __reserved[8];
};

In addition to doing what LOOP_SET_STATUS can do, LOOP_CONFIGURE can also be used to do the following:

set the correct block size immediately by setting loop_config.block_size;
explicitly request direct I/O mode by setting LO_FLAGS_DIRECT_IO in loop_config.info.lo_flags; and
explicitly request read-only mode by setting LO_FLAGS_READ_ONLY in loop_config.info.lo_flags.

Since Linux 2.6, there are two new ioctl(2) operations:

struct loop_info64 {
    uint64_t lo_device;           /* ioctl r/o */
    uint64_t lo_inode;            /* ioctl r/o */
    uint64_t lo_rdevice;          /* ioctl r/o */
    uint64_t lo_offset;
    uint64_t lo_sizelimit;  /* bytes, 0 == max available */
    uint32_t lo_number;           /* ioctl r/o */
    uint32_t lo_encrypt_type;
    uint32_t lo_encrypt_key_size; /* ioctl w/o */
    uint32_t lo_flags; i          /* ioctl r/w (r/o before
                                     Linux 2.6.25) */
    uint8_t  lo_file_name[LO_NAME_SIZE];
    uint8_t  lo_crypt_name[LO_NAME_SIZE];
    uint8_t  lo_encrypt_key[LO_KEY_SIZE]; /* ioctl w/o */
    uint64_t lo_init[2];
};

/dev/loop-control

LOOP_CTL_GET_FREE
Allocate or find a free loop device for use. On success, the device number is returned as the result of the call. This operation takes no argument.

FILES

/dev/loop*
The loop block special device files.

EXAMPLES

$ dd if=/dev/zero of=file.img bs=1MiB count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00609385 s, 1.7 GB/s
$ sudo ./mnt_loop file.img
loopname = /dev/loop5

Program source

#include <fcntl.h>
#include <linux/loop.h>
#include <sys/ioctl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define errExit(msg)    do { perror(msg); exit(EXIT_FAILURE); \
                        } while (0)
int
main(int argc, char *argv[])
{
    int loopctlfd, loopfd, backingfile;
    long devnr;
    char loopname[4096];
    if (argc != 2) {
        fprintf(stderr, "Usage: %s backing-file

35 - Linux cli command zero

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command zero and provides detailed information about the command zero, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the zero.

NAME 🖥️ zero 🖥️

data sink

DESCRIPTION

Data written to the /dev/null and /dev/zero special files is discarded.

Reads from /dev/null always return end of file (i.e., read(2) returns 0), whereas reads from /dev/zero always return bytes containing zero (‘�’ characters).

These devices are typically created by:

mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/zero c 1 5
chown root:root /dev/null /dev/zero

FILES

/dev/null
/dev/zero

NOTES

If these devices are not writable and readable for all users, many programs will act strangely.

Since Linux 2.6.31, reads from /dev/zero are interruptible by signals. (This change was made to help with bad latencies for large reads from /dev/zero.)

36 - Linux cli command ttyS

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command ttyS and provides detailed information about the command ttyS, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the ttyS.

NAME 🖥️ ttyS 🖥️

serial terminal lines

DESCRIPTION

ttyS[0-3] are character devices for the serial terminal lines.

They are typically created by:

mknod -m 660 /dev/ttyS0 c 4 64 # base address 0x3f8
mknod -m 660 /dev/ttyS1 c 4 65 # base address 0x2f8
mknod -m 660 /dev/ttyS2 c 4 66 # base address 0x3e8
mknod -m 660 /dev/ttyS3 c 4 67 # base address 0x2e8
chown root:tty /dev/ttyS[0-3]

FILES

/dev/ttyS[0-3]

37 - Linux cli command mem

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command mem and provides detailed information about the command mem, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the mem.

NAME 🖥️ mem 🖥️

system memory, kernel memory and system ports

DESCRIPTION

/dev/mem is a character device file that is an image of the main memory of the computer. It may be used, for example, to examine (and even patch) the system.

Byte addresses in /dev/mem are interpreted as physical memory addresses. References to nonexistent locations cause errors to be returned.

Examining and patching is likely to lead to unexpected results when read-only or write-only bits are present.

It is typically created by:

mknod -m 660 /dev/mem c 1 1
chown root:kmem /dev/mem

It is typically created by:

mknod -m 640 /dev/kmem c 1 2
chown root:kmem /dev/kmem

/dev/port is similar to /dev/mem, but the I/O ports are accessed.

It is typically created by:

mknod -m 660 /dev/port c 1 4
chown root:kmem /dev/port

FILES

/dev/mem
/dev/kmem
/dev/port

38 - Linux cli command intro

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command intro and provides detailed information about the command intro, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the intro.

NAME 🖥️ intro 🖥️

introduction to special files

DESCRIPTION

Section 4 of the manual describes special files (devices).

FILES

/dev/* — device files

NOTES

Authors and copyright conditions

Look at the header of the manual page source for the author(s) and copyright conditions. Note that these can be different from page to page!

39 - Linux cli command hd

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command hd and provides detailed information about the command hd, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the hd.

NAME 🖥️ hd 🖥️

MFM/IDE hard disk devices

DESCRIPTION

The hd* devices are block devices to access MFM/IDE hard disk drives in raw mode. The master drive on the primary IDE controller (major device number 3) is hda; the slave drive is hdb. The master drive of the second controller (major device number 22) is hdc and the slave is hdd.

General IDE block device names have the form hdX , or hdXP , where X is a letter denoting the physical drive, and P is a number denoting the partition on that physical drive. The first form, hdX , is used to address the whole drive. Partition numbers are assigned in the order the partitions are discovered, and only nonempty, nonextended partitions get a number. However, partition numbers 1–4 are given to the four partitions described in the MBR (the “primary” partitions), regardless of whether they are unused or extended. Thus, the first logical partition will be hdX5 . Both DOS-type partitioning and BSD-disklabel partitioning are supported. You can have at most 63 partitions on an IDE disk.

For example, /dev/hda refers to all of the first IDE drive in the system; and /dev/hdb3 refers to the third DOS “primary” partition on the second one.

They are typically created by:

mknod -m 660 /dev/hda b 3 0
mknod -m 660 /dev/hda1 b 3 1
mknod -m 660 /dev/hda2 b 3 2
...
mknod -m 660 /dev/hda8 b 3 8
mknod -m 660 /dev/hdb b 3 64
mknod -m 660 /dev/hdb1 b 3 65
mknod -m 660 /dev/hdb2 b 3 66
...
mknod -m 660 /dev/hdb8 b 3 72
chown root:disk /dev/hd*

FILES

/dev/hd*

40 - Linux cli command wireshark-filter

➡ A Linux man page (short for manual page) is a form of software documentation found on Linux and Unix-like operating systems. This man-page explains the command wireshark-filter and provides detailed information about the command wireshark-filter, system calls, library functions, and other aspects of the system, including usage, options, and examples of _. You can access this man page by typing man followed by the wireshark-filter.

NAME 🖥️ wireshark-filter 🖥️

filter - Wireshark display filter syntax and reference

SYNOPSIS

wireshark [other options] [ -Y “display filter expression” | –display-filter “display filter expression” ]

tshark [other options] [ -Y “display filter expression” | –display-filter “display filter expression” ]

DESCRIPTION

Wireshark and TShark share a powerful filter engine that helps remove the noise from a packet trace and lets you see only the packets that interest you. If a packet meets the requirements expressed in your filter, then it is displayed in the list of packets. Display filters let you compare the fields within a protocol against a specific value, compare fields against fields, and check the existence of specified fields or protocols.

Filters are also used by other features such as statistics generation and packet list colorization (the latter is only available to Wireshark). This manual page describes their syntax. A comprehensive reference of filter fields can be found within Wireshark and in the display filter reference at <https://www.wireshark.org/docs/dfref/>.

FILTER SYNTAX

Check whether a field or protocol exists

The simplest filter allows you to check for the existence of a protocol or field. If you want to see all packets which contain the IP protocol, the filter would be “ip” (without the quotation marks). To see all packets that contain a Token-Ring RIF field, use “tr.rif”.

Whenever a protocol or field appears as the argument of a function in a filter, an exists operator for that protocol or field implicitly appears.

Values and operators

Each field has a value, and that value can be used in operations with comparable values (which may be literals, other fields, or function results). The value of a field is not necessarily what appears in the Wireshark display or TShark output. For example, a protocol is semantically equivalent to the sequence of bytes that it spans, not its displayed text in the protocol tree.

Comparison operators

The comparison operators can be expressed either through English-like abbreviations or through C-like symbols:

eq, == Equal ne, != Not Equal gt, > Greater Than lt, < Less Than ge, >= Greater than or Equal to le, <= Less than or Equal to

The ordering depends on the value type in the usual way (e.g., lexicographic for strings and arithmetic for integers.) A field may appear more than once in a given frame. In that case equality can be strict (all fields must match the condition) or not (any field must match the condition). The inequality is the logical negation of equality. The following table contains all equality operators, their aliases and meaning:

eq, any_eq, == Any field must be equal ne, all_ne, != All fields must be not equal all_eq, === All fields must be equal any_ne, !== Any fields must be not equal

The operators “any” or “all” can be used with any comparison operator to make the test match any or all fields:

all tcp.port > 1024

any ip.addr != 1.1.1.1

The “any” and “all” modifiers take precedence over comparison operators such as “===” and “any_eq”.

Search and match operators

Additional operators exist expressed only in English, not C-like syntax:

contains Does the protocol, field or slice contain a value matches, ~ Does the string match the given case-insensitive Perl-compatible regular expression

The “contains” operator allows a filter to search for a sequence of characters, expressed as a string, or bytes, expressed as a byte array. The type of the left hand side of the “contains” operator must be comparable to that of the right hand side after any implicit or explicit conversions.

For example, to search for a given HTTP URL in a capture, the following filter can be used:

http contains “https://www.wireshark.org”

The “contains” operator cannot be used on atomic fields, such as numbers or IP addresses.

The “matches” or “~” operator allows a filter to apply to a specified Perl-compatible regular expression (PCRE2). The regular expression must be a double quoted string. The left hand side of the “matches” operator must be a string, which can be a non-stringlike field implicitly or explicitly converted to a string. Matches are case-insensitive by default. For example, to search for a given WAP WSP User-Agent, you can write:

wsp.header.user_agent matches “cldc”

This would match “cldc”, “CLDC”, “cLdC” or any other combination of upper and lower case letters.

You can force case sensitivity using

wsp.header.user_agent matches “(?-i)cldc”

This is an example of PCRE2’s (?option) construct. (?-i) performs a case-sensitive pattern match but other options can be specified as well. More information can be found in the pcre2pattern(3)|https://www.pcre.org/current/doc/html/pcre2pattern.html man page.

Functions

The filter language has the following functions:

upper(string-field) - converts a string field to uppercase lower(string-field) - converts a string field to lowercase len(field) - returns the byte length of a string or bytes field count(field) - returns the number of field occurrences in a frame string(field) - converts a non-string field to string max(f1,…,fn) - return the maximum value min(f1,…,fn) - return the minimum value abs(field) - return the absolute value of numeric fields

upper() and lower() are useful for performing case-insensitive string comparisons. For example:

upper(ncp.nds_stream_name) contains “MACRO” lower(mount.dump.hostname) == “angel”

string() converts a field value to a string, suitable for use with operators like “matches” or “contains”. Integer fields are converted to their decimal representation. It can be used with IP/Ethernet addresses (as well as others), but not with string or byte fields. For example:

string(frame.number) matches “[13579]$”

gives you all the odd packets.

max() and min() take any number of arguments and returns one value, respectively the largest/smallest. The arguments must all have the same type.

Protocol field types

Each protocol field is typed. The types are:

ASN.1 object identifier, plain or relative AX.25 address Boolean Byte sequence Character string Character, 1 byte Date and time Ethernet or other MAC address EUI64 address Fibre Channel WWN Floating point, single or double precision Frame number Globally Unique Identifier IEEE-11073 floating point, 16 or 32 bits IPv4 address IPv6 address IPX network number Label OSI System-ID Protocol Signed integer, 1, 2, 3, 4, or 8 bytes Time offset Unsigned integer, 1, 2, 3, 4, or 8 bytes VINES address

An integer may be expressed in decimal, octal, hexadecimal or binary notation, or as a C-style character constant. The following seven display filters are equivalent:

frame.len > 10 frame.len > 012 frame.len > 0xa frame.len > 0b1010 frame.len >

frame.len >

frame.len >

Boolean values are either true or false. In a display filter expression testing the value of a Boolean field, true is expressed as the word true (case-insensitive) or any non-zero number. False is expressed as false (case-insensitive) or the number zero. For example, a token-ring packet’s source route field is Boolean. To find any source-routed packets, a display filter would be any of the following:

tr.sr == 1 tr.sr == true tr.sr == TRUE

Non source-routed packets can be found with:

tr.sr == 0 tr.sr == false tr.sr == FALSE

Ethernet addresses and byte arrays are represented by hex digits. The hex digits may be separated by colons, periods, or hyphens:

eth.dst eq ff:ff:ff:ff:ff:ff aim.data == 0.1.0.d fddi.src == aa-aa-aa-aa-aa-aa echo.data == 7a

IPv4 addresses can be represented in either dotted decimal notation or by using the hostname:

ip.src == 192.168.1.1 ip.dst eq www.mit.edu

IPv4 addresses can be compared with the same logical relations as numbers: eq, ne, gt, ge, lt, and le. The IPv4 address is stored in host order, so you do not have to worry about the endianness of an IPv4 address when using it in a display filter.

Classless Inter-Domain Routing (CIDR) notation can be used to test if an IPv4 address is in a certain subnet. For example, this display filter will find all packets in the 129.111 network:

ip.addr == 129.111.0.0/16

Remember, the number after the slash represents the number of bits used to represent the network. CIDR notation can also be used with hostnames, as in this example of finding IP addresses on the same network as sneezy (requires that sneezy resolve to an IP address for filter to be valid):

ip.addr eq sneezy/24

The CIDR notation can only be used on IP addresses or hostnames, not in variable names. So, a display filter like “ip.src/24 == ip.dst/24” is not valid (yet).

Transaction and other IDs are often represented by unsigned 16 or 32 bit integers and formatted as a hexadecimal string with “0x” prefix:

(dhcp.id == 0xfe089c15) || (ip.id == 0x0373)

Strings are enclosed in double quotes:

http.request.method == “POST”

Inside double quotes, you may use a backslash to embed a double quote or an arbitrary byte represented in either octal or hexadecimal.

browser.comment == “An embedded " double-quote”

Use of hexadecimal to look for “HEAD”:

http.request.method == “HEAD”

Use of octal to look for “HEAD”:

http.request.method == “\110EAD”

This means that you must escape backslashes with backslashes inside double quotes.

smb.path contains “\SERVER\SHARE”

looks for \SERVER\SHARE in “smb.path”. This may be more conveniently written as

smb.path contains r"\SERVER\SHARE"

String literals prefixed with r are called “raw strings”. Such strings treat backslash as a literal character. Double quotes may still be escaped with backslash but note that backslashes are always preserved in the result.

The following table lists all escape sequences supported with strings and character constants:

\ single quote " double quote \ backslash audible bell backspace form feed

      line feed


          carriage return
	          horizontal tab
          vertical tab
\NNN        arbitrary octal value
\xNN        arbitrary hexadecimal value
\uNNNN      Unicode codepoint U+NNNN
\UNNNNNNNN  Unicode codepoint U+NNNNNNNN

Date and time values can be given in ISO 8601 format or using a legacy month-year-time format:

“2020-07-04T12:34:56” “Sep 26, 2004 23:18:04.954975”

The T separator in ISO 8601 can be omitted. The timezone can be given as “Z” or an offset from UTC.

When not using ISO 8601 the timezone can be given as the strings “UTC”, “GMT” or “UT” for UTC or also given as an offset from UTC, plus some North American and Nautical/Military designations ( see the specification for %z in strptime(3) <https://man.netbsd.org/strptime.3>). Note that arbitrary timezone names are not supported however.

If the timezone is omitted then date and time values are interpreted as local time.

The slice operator

You can take a slice of a field if the field base type is a text string or a byte array (the base type of most network address fields is bytes). For example, you can filter on the vendor portion of an ethernet address (the first three bytes) like this:

eth.src[0:3] == 00:00:83

Another example is:

http.content_type[0:4] == “text”

You can use the slice operator on a protocol name, too. The “frame” protocol can be useful, encompassing all the data captured by Wireshark or TShark.

token[0:5] ne 0.0.0.1.1 llc[0] eq aa frame[100-199] contains “wireshark”

The following syntax governs slices:

[i:j] i = start_offset, j = length [i-j] i = start_offset, j = end_offset, inclusive. [i] i = start_offset, length = 1 [:j] start_offset = 0, length = j [i:] start_offset = i, end_offset = end_of_field

Slice indexes are zero-based. Offsets can be negative, in which case they indicate the offset from the end of the field. The last byte of the field is at offset -1, the last but one byte is at offset -2, and so on. Here’s how to check the last four bytes of a frame:

frame[-4:4] == 0.1.2.3

frame[-4:] == 0.1.2.3

As mentioned above the slice operator can be used on string and byte fields and will respectively produce string or byte slices. String slices are indexed on UTF-8 codepoint boundaries (i.e: internationalized characters), so the following comparison is true:

“touché”[5] == “é”

The example above generates an error because the compiler rejects constant expressions but is otherwise syntactically correct and exemplifies the behaviour of string slices.

To obtain a byte slice of the same string the raw (@) operator can be used:

@“touché”[5-6] == c3:a9

A slice can always be compared against either a string or a byte sequence.

Slices can be combined. You can concatenate them using the comma operator:

ftp[1,3-5,9:] == 01:03:04:05:09:0a:0b

This concatenates offset 1, offsets 3-5, and offset 9 to the end of the ftp data.

The layer operator

A field can be restricted to a certain layer in the protocol stack using the layer operator (#), followed by a decimal number:

ip.addr#2 == 192.168.30.40

matches only the inner (second) layer in the packet. Layers use simple stacking semantics and protocol layers are counted sequentially starting from 1. For example, in a packet that contains two IPv4 headers, the outer (first) source address can be matched with “ip.src#1” and the inner (second) source address can be matched with “ip.src#2”.

For more complicated ranges the same syntax used with slices is valid:

tcp.port#[2-4]

means layers number 2, 3 or 4 inclusive. The hash symbol is required to distinguish a layer range from a slice.

The at operator

By prefixing the field name with an at sign (@) the comparison is done against the raw packet data for the field.

A character string must be decoded from a source encoding during dissection. If there are decoding errors the resulting string will usually contain replacement characters:

browser.comment == “string is ��”

The at operator allows testing the raw undecoded data:

@browser.comment == 73:74:72:69:6e:67:20:69:73:20:aa:aa:aa:aa

The syntactical rules for a bytes field type apply to the second example.

The membership operator

A field may be checked for matches against a set of values simply with the membership operator. For instance, you may find traffic on common HTTP/HTTPS ports with the following filter:

tcp.port in {80,443,8080}

as opposed to the more verbose:

tcp.port == 80 or tcp.port == 443 or tcp.port == 8080

To find HTTP requests using the HEAD or GET methods:

http.request.method in {“HEAD”, “GET”}

The set of values can also contain ranges:

tcp.port in {443, 4430..4434} ip.addr in {10.0.0.5 .. 10.0.0.9, 192.168.1.1..192.168.1.9} frame.time_delta in {10 .. 10.5}

Implicit type conversions

Fields which are sequences of bytes, including protocols, are implicitly converted to strings for comparisons against (double quoted) literal strings and raw strings.

So, for instance, the following filters are equivalent:

tcp.payload contains “GET” tcp.payload contains 47.45.54

As noted above, a slice can also be compared in either way:

frame[60:2] gt 50.51 frame[60:2] gt “PQ”

The inverse does not occur; stringlike fields are not implicitly converted to byte arrays. (Some operators allow stringlike fields to be compared with unquoted literals, which are then treated as strings; this is deprecated in general and specifically disallowed by the “matches” operator. Literal strings should be double quoted for clarity.)

A hex integer that is 0xff or less (which means it fits inside one byte) can be implicitly converted to a byte string. This is not allowed for hex integers greater than one byte, because then one would need to specify the endianness of the multi-byte integer. Also, this is not allowed for decimal or octal numbers, since they would be confused with the hex numbers that make up byte string literals. Nevertheless, single-byte hex integers can be convenient:

frame[4] == 0xff frame[1:4] contains 0x02

Bitwise operators

It is also possible to define tests with bitwise operations. Currently the following bitwise operator is supported:

bitwise_and, & Bitwise AND

The bitwise AND operation allows masking bits and testing to see if one or more bits are set. Bitwise AND operates on integer protocol fields and slices.

When testing for TCP SYN packets, you can write:

tcp.flags & 0x02

That expression will match all packets that contain a “tcp.flags” field with the 0x02 bit, i.e. the SYN bit, set.

To match locally administered unicast ethernet addresses you can use:

eth.addr[0] & 0x0f == 2

When using slices, the bit mask must be specified as a byte string, and it must have the same number of bytes as the slice itself, as in:

ip[42:2] & 40:ff

Arithmetic operators

Arithmetic expressions are supported with the usual operators:

Addition
Subtraction
Multiplication / Division % Modulo (integer remainder)

For example it is possible to filter for UDP destination ports greater or equal by one to the source port with the expression:

udp.dstport >= udp.srcport + 1

It is possible to group arithmetic expressions using curly brackets (parenthesis will not work for this):

tcp.dstport >= 4 * {tcp.srcport + 3}

Do not confuse this usage of curly brackets with set membership.

An unfortunate quirk in the filter syntax is that the subtraction operator must be preceded by a space character, so “A-B” must be written as “A -B” or “A - B”.

Protocol field references

A variable using a sigil with the form ${some.proto.field} is called a field reference. A field reference is a field value read from the currently selected frame in the GUI. This is useful to build dynamic filters such as, frames since the last five minutes to the selected frame:

frame.time_relative >= ${frame.time_relative} - 300

Field references share a similar notation to macros but are distinct syntactical elements in the filter language.

Logical expressions

Tests can be combined using logical expressions. These too are expressible in C-like syntax or with English-like abbreviations. The following table lists the logical operators from highest to lowest precedence:

not, ! Logical NOT (right-associative) and, && Logical AND (left-associative) xor, ^^ Logical XOR (left-associative) or, || Logical OR (left-associative)

The evaluation is always performed left to right. Expressions can be grouped by parentheses as well. The expression “A and B or not C or D and not E or F” is read:

(A and B) or (not C) or (D and (not E)) or F

It’s usually better to be explicit about grouping using parenthesis. The following are all valid display filter expressions:

tcp.port == 80 and ip.src == 192.168.2.1 not llc http and frame[100-199] contains “wireshark” (ipx.src.net == 0xbad && ipx.src.node == 0.0.0.0.0.1) || ip

Remember that whenever a protocol or field name occurs in an expression, the “exists” operator is implicitly called. The “exists” operator has the highest priority. This means that the first filter expression must be read as “show me the packets for which tcp.port exists and equals 80, and ip.src exists and equals 192.168.2.1”. The second filter expression means “show me the packets where not exists llc”, or in other words “where llc does not exist” and hence will match all packets that do not contain the llc protocol. The third filter expression includes the constraint that offset 199 in the frame exists, in other words the length of the frame is at least 200.

Because each comparison has an implicit exists test for field values care must be taken when using the display filter to remove noise from the packet trace. If, for example, you want to filter out all IP multicast packets to address 224.1.2.3, then using:

ip.dst ne 224.1.2.3

may be too restrictive. This is the same as writing:

ip.dst and ip.dst ne 224.1.2.3

The filter selects only frames that have the “ip.dst” field. Any other frames, including all non-IP packets, will not be displayed. To display the non-IP packets as well, you can use one of the following two expressions:

not ip.dst or ip.dst ne 224.1.2.3 not ip.dst eq 224.1.2.3

The first filter uses “not ip.dst” to include all non-IP packets and then lets “ip.dst ne 224.1.2.3” filter out the unwanted IP packets. The second filter also negates the implicit existence test and so is a shorter way to write the first.

FILTER FIELD REFERENCE

The entire list of display filters is too large to list here. You can can find references and examples at the following locations:

·
The online Display Filter Reference: <https://www.wireshark.org/docs/dfref/>

·
View:Internals:Supported Protocols in Wireshark

·
tshark -G fields on the command line

·
The Wireshark wiki: <https://gitlab.com/wireshark/wireshark/-/wikis/DisplayFilters>

NOTES

The wireshark-filter(4) manpage is part of the Wireshark distribution. The latest version of Wireshark can be found at <https://www.wireshark.org>.

Regular expressions in the “matches” operator are provided by the PCRE2 library. See <https://www.pcre.org/> for more information.

This manpage does not describe the capture filter syntax, which is different. See the manual page of pcap-filter(7) or, if that doesn’t exist, tcpdump(8), or, if that doesn’t exist, <https://gitlab.com/wireshark/wireshark/-/wikis/CaptureFilters> for a description of capture filters.

Display Filters are also described in the User’s Guide: <https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html>

AUTHORS

See the list of authors in the Wireshark man page for a list of authors of that code.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

  █║▌│║█║▌★ KALI ★ PARROT ★ DEBIAN 🔴 PENTESTING ★ HACKING ★ █║▌│║█║▌

              ██╗ ██╗ ██████╗  ██████╗ ██╗  ██╗███████╗██████╗
             ████████╗██╔══██╗██╔═══██╗╚██╗██╔╝██╔════╝██╔══██╗
             ╚██╔═██╔╝██║  ██║██║   ██║ ╚███╔╝ █████╗  ██║  ██║
             ████████╗██║  ██║██║   ██║ ██╔██╗ ██╔══╝  ██║  ██║
             ╚██╔═██╔╝██████╔╝╚██████╔╝██╔╝ ██╗███████╗██████╔╝
              ╚═╝ ╚═╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═════╝

               █║▌│║█║▌ WITH COMMANDLINE-KUNGFU POWER █║▌│║█║▌

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

man4

1 - Linux cli command extcap

NAME 🖥️ extcap 🖥️

DESCRIPTION

GRAMMAR ELEMENTS

EXAMPLES

SECURITY CONSIDERATIONS

SEE ALSO

NOTES

2 - Linux cli command wavelan

NAME 🖥️ wavelan 🖥️

SYNOPSIS

DESCRIPTION

Parameters

Wireless extensions

NWID (or domain)

Frequency & channels

Statistics spy

/proc/net/wireless

Private ioctl

Quality and level threshold

Histogram

Specific notes

SEE ALSO

3 - Linux cli command cciss

NAME 🖥️ cciss 🖥️

SYNOPSIS

DESCRIPTION

Options

Supported hardware

Configuration details

FILES

Device nodes

Files in /proc

Files in /sys

SCSI tape drive and medium changer support

Hot plug support for SCSI tape drives

SCSI error handling for tape drives and medium changers

SEE ALSO

4 - Linux cli command loop-control

NAME 🖥️ loop-control 🖥️

SYNOPSIS

DESCRIPTION

/dev/loop-control

FILES

EXAMPLES

Program source

SEE ALSO

5 - Linux cli command lp

NAME 🖥️ lp 🖥️

SYNOPSIS

CONFIGURATION

DESCRIPTION

FILES

SEE ALSO

6 - Linux cli command vcs

NAME 🖥️ vcs 🖥️

DESCRIPTION

FILES

VERSIONS

EXAMPLES

SEE ALSO

7 - Linux cli command pts

NAME 🖥️ pts 🖥️

DESCRIPTION

FILES

NOTES

SEE ALSO

8 - Linux cli command sd

NAME 🖥️ sd 🖥️

SYNOPSIS

CONFIGURATION

DESCRIPTION

FILES

9 - Linux cli command ram

NAME 🖥️ ram 🖥️

DESCRIPTION

FILES

SEE ALSO

10 - Linux cli command cpuid