ipvsadm

package: ipvsadm

title: ipvsadm(8)

summary: Linux Virtual Server administration

text:
# ipvsadm(8)

## NAME
ipvsadm - Linux Virtual Server administration

## SYNOPSIS
ipvsadm -A|E virtual-service [-s scheduler] [-p [timeout]] [-M netmask] [-b sched-flags]

ipvsadm -D virtual-service

ipvsadm -C

ipvsadm -R

ipvsadm -S [-n]

ipvsadm -a|e virtual-service -r server-address [-g|i|m] [-w weight] [-x upper] [-y lower]

ipvsadm -d virtual-service -r server-address

ipvsadm -L|l [virtual-service] [options]

ipvsadm -Z [virtual-service]

ipvsadm --set tcp tcpfin udp

ipvsadm --start-daemon state [daemon-options] [--syncid syncid]

ipvsadm --stop-daemon state

ipvsadm -h

## DESCRIPTION
Ipvsadm(8) is used to set up, maintain or inspect the virtual server table in the Linux kernel. The Linux Virtual Server can be used to build scalable network services based on a cluster of two or more nodes. The active node of the cluster redirects service requests to a collection of server hosts that will actually perform the services. Supported features include three protocols (TCP, UDP and SCTP), three packet-forwarding methods (NAT, tunneling, and direct routing), and eight load balancing algorithms (round robin, weighted round robin, least-connection, weighted least-connection, locality-based least-connection, locality-based least-connection with replication, destination-hashing, and source-hashing).

The command has two basic formats for execution:

ipvsadm COMMAND virtual-service

[scheduling-method] [persistence options]

ipvsadm command virtual-service

server-address [packet-forwarding-method] [weight options]

The first format manipulates a virtual service and the algorithm for assigning service requests to real servers. Optionally, a persistent timeout and network mask for the granularity of a persistent service may be specified. The second format manipulates a real server that is associated with an existing virtual service. When specifying a real server, the packet-forwarding method and the weight of the real server, relative to other real servers for the virtual service, may be specified, otherwise defaults will be used.

### COMMANDS
ipvsadm(8) recognises the commands described below. Upper-case commands maintain virtual services. Lower-case commands maintain real servers that are associated with a virtual service.

-A, --add-service

Add a virtual service. A service address is uniquely defined by a triplet: IP address, port number, and protocol. Alternatively, a virtual service may be defined by a firewall-mark.

-E, --edit-service

Edit a virtual service.

-D, --delete-service

Delete a virtual service, along with any associated real servers.

-C, --clear

Clear the virtual server table.

-R, --restore

Restore Linux Virtual Server rules from stdin. Each line read from stdin will be treated as the command line options to a separate invocation of ipvsadm. Lines read from stdin can optionally begin with "ipvsadm". This option is useful to avoid executing a large number or ipvsadm commands when constructing an extensive routing table.

-S, --save

Dump the Linux Virtual Server rules to stdout in a format that can be read by -R|--restore.

-a, --add-server

Add a real server to a virtual service.

-e, --edit-server

Edit a real server in a virtual service.

-d, --delete-server

Remove a real server from a virtual service.

-L, -l, --list

List the virtual server table if no argument is specified. If a service-address is selected, list this service only. If the -c option is selected, then display the connection table. The exact output is affected by the other arguments given.

-Z, --zero

Zero the packet, byte and rate counters in a service or all services.

--set tcp tcpfin udp

Change the timeout values used for IPVS connections. This command always takes 3 parameters, representing the timeout values (in seconds) for TCP sessions, TCP sessions after receiving a FIN packet, and UDP packets, respectively. A timeout value 0 means that the current timeout value of the corresponding entry is preserved.

--start-daemon state

Start the connection synchronization daemon. The state is to indicate that the daemon is started as master or backup. The connection synchronization daemon is implemented inside the Linux kernel. The master daemon running at the primary load balancer multicasts changes of connections periodically, and the backup daemon running at the backup load balancers receives multicast message and creates corresponding connections. Then, in case the primary load balancer fails, a backup load balancer will takeover, and it has state of almost all connections, so that almost all established connections can continue to access the service.

The sync daemon supports IPv4 and IPv6 connections.

--stop-daemon

Stop the connection synchronization daemon.

-h, --help

Display a description of the command syntax.

### virtual-service
Specifies the virtual service based on protocol/addr/port or firewall mark.

-t, --tcp-service service-address

Use TCP service. The service-address is of the form host[:port]. Host may be one of a plain IP address or a hostname. Port may be either a plain port number or the service name of port. The Port may be omitted, in which case zero will be used. A Port of zero is only valid if the service is persistent as the -p|--persistent option, in which case it is a wild-card port, that is connections will be accepted to any port.

-u, --udp-service service-address

Use UDP service. See the -t|--tcp-service for the description of the service-address.

--sctp-service service-address

Use SCTP service. See the -t|--tcp-service for the description of the service-address.

-f, --fwmark-service integer

Use a firewall-mark, an integer value greater than zero, to denote a virtual service instead of an address, port and protocol (UDP or TCP). The marking of packets with a firewall-mark is configured using the -m|--mark option to iptables(8). It can be used to build a virtual service associated with the same real servers, covering multiple IP address, port and protocol triplets. If IPv6 addresses are used, the -6 option must be used. Using firewall-mark virtual services provides a convenient method of grouping together different IP addresses, ports and protocols into a single virtual service. This is useful for both simplifying configuration if a large number of virtual services are required and grouping persistence across what would otherwise be multiple virtual services.

### PARAMETERS
The commands above accept or require zero or more of the following parameters.

-s, --scheduler scheduling-method

scheduling-method Algorithm for allocating TCP connections and UDP datagrams to real servers. Scheduling algorithms are implemented as kernel modules. Ten are shipped with the Linux Virtual Server: rr - Round Robin: distributes jobs equally amongst the available real servers.

wrr - Weighted Round Robin: assigns jobs to real servers proportionally to there real servers' weight. Servers with higher weights receive new jobs first and get more jobs than servers with lower weights. Servers with equal weights get an equal distribution of new jobs.

lc - Least-Connection: assigns more jobs to real servers with fewer active jobs.

wlc - Weighted Least-Connection: assigns more jobs to servers with fewer jobs and relative to the real servers' weight (Ci/Wi). This is the default.

lblc - Locality-Based Least-Connection: assigns jobs destined for the same IP address to the same server if the server is not overloaded and available; otherwise assign jobs to servers with fewer jobs, and keep it for future assignment.

lblcr - Locality-Based Least-Connection with Replication: assigns jobs destined for the same IP address to the least-connection node in the server set for the IP address. If all the node in the server set are over loaded, it picks up a node with fewer jobs in the cluster and adds it in the sever set for the target. If the server set has not been modified for the specified time, the most loaded node is removed from the server set, in order to avoid high degree of replication.

dh - Destination Hashing: assigns jobs to servers through looking up a statically assigned hash table by their destination IP addresses.

sh - Source Hashing: assigns jobs to servers through looking up a statically assigned hash table by their source IP addresses. This scheduler has two flags: sh-fallback, which enables fallback to a different server if the selected server was unavailable, and sh-port, which adds the source port number to the hash computation.

sed - Shortest Expected Delay: assigns an incoming job to the server with the shortest expected delay. The expected delay that the job will experience is (Ci + 1) / Ui if sent to the ith server, in which Ci is the number of jobs on the the ith server and Ui is the fixed service rate (weight) of the ith server.

nq - Never Queue: assigns an incoming job to an idle server if there is, instead of waiting for a fast one; if all the servers are busy, it adopts the Shortest Expected Delay policy to assign the job.

-p, --persistent [timeout]

Specify that a virtual service is persistent. If this option is specified, multiple requests from a client are redirected to the same real server selected for the first request. Optionally, the timeout of persistent sessions may be specified given in seconds, otherwise the default of 300 seconds will be used. This option may be used in conjunction with protocols such as SSL or FTP where it is important that clients consistently connect with the same real server. Note: If a virtual service is to handle FTP connections then persistence must be set for the virtual service if Direct Routing or Tunnelling is used as the forwarding mechanism. If Masquerading is used in conjunction with an FTP service than persistence is not necessary, but the ip_vs_ftp kernel module must be used. This module may be manually inserted into the kernel using insmod(8).

-M, --netmask netmask

Specify the granularity with which clients are grouped for persistent virtual services. The source address of the request is masked with this netmask to direct all clients from a network to the same real server. The default is 255.255.255.255, that is, the persistence granularity is per client host. Less specific netmasks may be used to resolve problems with non-persistent cache clusters on the client side. IPv6 netmasks should be specified as a prefix length between 1 and 128. The default prefix length is 128.

-b, --sched-flags sched-flags

Set scheduler flags for this virtual server. sched-flags is a comma-separated list of flags. See the scheduler descriptions for valid scheduler flags.

-r, --real-server server-address

Real server that an associated request for service may be assigned to. The server-address is the host address of a real server, and may plus port. Host can be either a plain IP address or a hostname. Port can be either a plain port number or the service name of port. In the case of the masquerading method, the host address is usually an RFC 1918 private IP address, and the port can be different from that of the associated service. With the tunneling and direct routing methods, port must be equal to that of the service address. For normal services, the port specified in the service address will be used if port is not specified. For fwmark services, port may be omitted, in which case the destination port on the real server will be the destination port of the request sent to the virtual service.

[packet-forwarding-method]

-g, --gatewaying Use gatewaying (direct routing). This is the default.

-i, --ipip Use ipip encapsulation (tunneling).

-m, --masquerading Use masquerading (network access translation, or NAT).

Note: Regardless of the packet-forwarding mechanism specified, real servers for addresses for which there are interfaces on the local node will be use the local forwarding method, then packets for the servers will be passed to upper layer on the local node. This cannot be specified by ipvsadm, rather it set by the kernel as real servers are added or modified.

-w, --weight weight

Weight is an integer specifying the capacity of a server relative to the others in the pool. The valid values of weight are 0 through to 65535. The default is 1. Quiescent servers are specified with a weight of zero. A quiescent server will receive no new jobs but still serve the existing jobs, for all scheduling algorithms distributed with the Linux Virtual Server. Setting a quiescent server may be useful if the server is overloaded or needs to be taken out of service for maintenance.

-x, --u-threshold uthreshold

uthreshold is an integer specifying the upper connection threshold of a server. The valid values of uthreshold are 0 through to 65535. The default is 0, which means the upper connection threshold is not set. If uthreshold is set with other values, no new connections will be sent to the server when the number of its connections exceeds its upper connection threshold.

-y, --l-threshold lthreshold

lthreshold is an integer specifying the lower connection threshold of a server. The valid values of lthreshold are 0 through to 65535. The default is 0, which means the lower connection threshold is not set. If lthreshold is set with other values, the server will receive new connections when the number of its connections drops below its lower connection threshold. If lthreshold is not set but uthreshold is set, the server will receive new connections when the number of its connections drops below three forth of its upper connection threshold.

-c, --connection

Connection output. The list command with this option will list current IPVS connections.

--timeout

Timeout output. The list command with this option will display the timeout values (in seconds) for TCP sessions, TCP sessions after receiving a FIN packet, and UDP packets.

--daemon

Daemon information output. The list command with this option will display the daemon status and its multicast interface.

--stats

Output of statistics information. The list command with this option will display the statistics information of services and their servers.

--rate

Output of rate information. The list command with this option will display the rate information (such as connections/second, bytes/second and packets/second) of services and their servers.

--thresholds

Output of thresholds information. The list command with this option will display the upper/lower connection threshold information of each server in service listing.

--persistent-conn

Output of persistent connection information. The list command with this option will display the persistent connection counter information of each server in service listing. The persistent connection is used to forward the actual connections from the same client/network to the same server. The list command with the -c, --connection option and this option will include persistence engine data, if any is present, when listing connections.

--sort

Sort the list of virtual services and real servers. The virtual service entries are sorted in ascending order by <protocol, address, port>. The real server entries are sorted in ascending order by <address, port>. (default)

--nosort

Do not sort the list of virtual services and real servers.

-n, --numeric

Numeric output. IP addresses and port numbers will be printed in numeric format rather than as as host names and services respectively, which is the default.

--exact

Expand numbers. Display the exact value of the packet and byte counters, instead of only the rounded number in K's (multiples of 1000) M's (multiples of 1000K) or G's (multiples of 1000M). This option is only relevant for the -L command.

-6, --ipv6

Use with -f to signify fwmark rule uses IPv6 addresses.

-o, --ops

One-packet scheduling. Used in conjunction with a UDP virtual service or a fwmark virtual service that handles only UDP packets. All connections are created such that they only schedule one packet.

### PARAMETERS FOR SYNCHRONIZATION DAEMON
The --start-daemon requires zero or more of the following parameters.

--syncid syncid

Specify the syncid that the sync master daemon fills in the SyncID header while sending multicast messages, or the sync backup daemon uses to filter out multicast messages not matched with the SyncID value. The valid values of syncid are 0 through to 255. The default is 0, which means no filtering at all.

--sync-maxlen length

Specify the desired length of sync messages (UDP payload size). It is expected that backup server will use value not less than the used value in master server. The valid values of length are in the 1 .. (65535 - 20 - 8) range but the kernel ensures a space for at least one sync message. If value is lower than MTU the sync messages will be fragmented by IP layer. The default value is derived from the MTU value when daemon is started but master daemon will not default to value above 1500 for compatibility reasons.

--mcast-interface interface

Specify the multicast interface that the sync master daemon sends outgoing multicasts through, or the sync backup daemon listens to for multicasts.

--mcast-group address

Specify IPv4 or IPv6 multicast address for the sync messages. The default value is 224.0.0.81.

--mcast-port port

Specify the UDP port for sync messages. The default value is 8848.

--mcast-ttl ttl

Specify the TTL value for sync messages (1 .. 255). The default value is 1.

## EXAMPLE 1 - Simple Virtual Service
The following commands configure a Linux Director to distribute incoming requests addressed to port 80 on 207.175.44.110 equally to port 80 on five real servers. The forwarding method used in this example is NAT, with each of the real servers being masqueraded by the Linux Director.

```
ipvsadm -A -t 207.175.44.110:80 -s rr
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.1:80 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.2:80 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.3:80 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.4:80 -m
ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.5:80 -m
```

Alternatively, this could be achieved in a single ipvsadm command.

```
echo "
-A -t 207.175.44.110:80 -s rr
-a -t 207.175.44.110:80 -r 192.168.10.1:80 -m
-a -t 207.175.44.110:80 -r 192.168.10.2:80 -m
-a -t 207.175.44.110:80 -r 192.168.10.3:80 -m
-a -t 207.175.44.110:80 -r 192.168.10.4:80 -m
-a -t 207.175.44.110:80 -r 192.168.10.5:80 -m
" | ipvsadm -R
```

As masquerading is used as the forwarding mechanism in this example, the default route of the real servers must be set to the linux director, which will need to be configured to forward and masquerade packets. This can be achieved using the following commands:

```
echo "1" > /proc/sys/net/ipv4/ip_forward
```

## EXAMPLE 2 - Firewall-Mark Virtual Service
The following commands configure a Linux Director to distribute incoming requests addressed to any port on 207.175.44.110 or 207.175.44.111 equally to the corresponding port on five real servers. As per the previous example, the forwarding method used in this example is NAT, with each of the real servers being masqueraded by the Linux Director.

```
ipvsadm -A -f 1  -s rr
ipvsadm -a -f 1 -r 192.168.10.1:0 -m
ipvsadm -a -f 1 -r 192.168.10.2:0 -m
ipvsadm -a -f 1 -r 192.168.10.3:0 -m
ipvsadm -a -f 1 -r 192.168.10.4:0 -m
ipvsadm -a -f 1 -r 192.168.10.5:0 -m
```

As masquerading is used as the forwarding mechanism in this example, the default route of the real servers must be set to the linux director, which will need to be configured to forward and masquerade packets. The real server should also be configured to mark incoming packets addressed to any port on 207.175.44.110 and 207.175.44.111 with firewall-mark 1. If FTP traffic is to be handled by this virtual service, then the ip_vs_ftp kernel module needs to be inserted into the kernel. These operations can be achieved using the following commands:

```
echo "1" > /proc/sys/net/ipv4/ip_forward
modprobe ip_tables
iptables  -A PREROUTING -t mangle -d 207.175.44.110/31 -j MARK --set-mark 1
modprobe ip_vs_ftp
```

## IPv6
IPv6 addresses should be surrounded by square brackets ([ and ]).

```
ipvsadm -A -t [2001:db8::80]:80 -s rr
ipvsadm -a -t [2001:db8::80]:80 -r [2001:db8::a0a0]:80 -m
```

fwmark IPv6 services require the -6 option.

## NOTES
The Linux Virtual Server implements three defense strategies against some types of denial of service (DoS) attacks. The Linux Director creates an entry for each connection in order to keep its state, and each entry occupies 128 bytes effective memory. LVS's vulnerability to a DoS attack lies in the potential to increase the number entries as much as possible until the linux director runs out of memory. The three defense strategies against the attack are: Randomly drop some entries in the table. Drop 1/rate packets before forwarding them. And use secure tcp state transition table and short timeouts. The strategies are controlled by sysctl variables and corresponding entries in the /proc filesystem:

/proc/sys/net/ipv4/vs/drop_entry /proc/sys/net/ipv4/vs/drop_packet /proc/sys/net/ipv4/vs/secure_tcp

Valid values for each variable are 0 through to 3. The default value is 0, which disables the respective defense strategy. 1 and 2 are automatic modes - when there is no enough available memory, the respective strategy will be enabled and the variable is automatically set to 2, otherwise the strategy is disabled and the variable is set to 1. A value of 3 denotes that the respective strategy is always enabled. The available memory threshold and secure TCP timeouts can be tuned using the sysctl variables and corresponding entries in the /proc filesystem:

/proc/sys/net/ipv4/vs/amemthresh /proc/sys/net/ipv4/vs/timeout_*

## FILES
/proc/net/ip_vs

/proc/net/ip_vs_app

/proc/net/ip_vs_conn

/proc/net/ip_vs_stats

/proc/sys/net/ipv4/vs/am_droprate

/proc/sys/net/ipv4/vs/amemthresh

/proc/sys/net/ipv4/vs/drop_entry

/proc/sys/net/ipv4/vs/drop_packet

/proc/sys/net/ipv4/vs/secure_tcp

/proc/sys/net/ipv4/vs/timeout_close

/proc/sys/net/ipv4/vs/timeout_closewait

/proc/sys/net/ipv4/vs/timeout_established

/proc/sys/net/ipv4/vs/timeout_finwait

/proc/sys/net/ipv4/vs/timeout_icmp

/proc/sys/net/ipv4/vs/timeout_lastack

/proc/sys/net/ipv4/vs/timeout_listen

/proc/sys/net/ipv4/vs/timeout_synack

/proc/sys/net/ipv4/vs/timeout_synrecv

/proc/sys/net/ipv4/vs/timeout_synsent

/proc/sys/net/ipv4/vs/timeout_timewait

/proc/sys/net/ipv4/vs/timeout_udp

## SEE ALSO
The LVS web site (http://www.linuxvirtualserver.org/) for more documentation about LVS.

ipvsadm-save(8), ipvsadm-restore(8), iptables(8),

insmod(8), modprobe(8)

## AUTHORS

```
ipvsadm - Wensong Zhang <wensong@linuxvirtualserver.org>
	  Peter Kese <peter.kese@ijs.si>
man page - Mike Wangsmo <wanger@redhat.com>
	   Wensong Zhang <wensong@linuxvirtualserver.org>
	   Horms <horms@verge.net.au>
```


ipvsadm-restore

title: ipvsadm-restore(8)

summary: restore the IPVS table from stdin

text:
# ipvsadm-restore(8)

## NAME
ipvsadm-restore - restore the IPVS table from stdin

## SYNOPSIS
ipvsadm-restore

## DESCRIPTION
ipvsadm-restore prints the IPVS table from stdin.

## OPTIONS
No options now.

## SEE ALSO
ipvsadm(8), the LVS-HOWTO.


ipvsadm-save

title: ipvsadm-save(8)

summary: save the IPVS table to stdout

text:
# ipvsadm-save(8)

## NAME
ipvsadm-save - save the IPVS table to stdout

## SYNOPSIS
ipvsadm-save [-n]

## DESCRIPTION
ipvsadm-save prints the IPVS table to stdout.

## OPTIONS
The option that is recognized by ipvsadm-save is:

-n

print out the table in numeric format.

## SEE ALSO
ipvsadm(8), the LVS-HOWTO.


findchip

package: irda-utils

title: findchip(8)

summary: checks the FIR chipset.

text:
# findchip(8)

## NAME
findchip - checks the FIR chipset.

## SYNOPSIS
findchip [ -d dongle ] [ -v ] [ -l ] [ <chip1 .. chipN> ] [ -h ]

## OPTIONS
-d enables debug output

-v be verbose

-l lists supported chipsets

-h prints help message

## DESCRIPTION
findchip checks the FIR chipset.

findchip must be run as root or installed setuid root, as it requires root privileges.

## EXAMPLES
N.N.

## DIAGNOSTICS
N.N.

## BUGS
N.N.

## SEE ALSO
irattach(8), irdaping(8), irdadump(8), findchip(8), irpsion5(8), modprobe(8)

Linux/IrDA Project http://irda.sourceforge.net -*- Linux/IrDA-Tutorial http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/index.html -*- Infrared-HOWTO http://tuxmobil.org/howtos.html -*- Infrared-Hardware-Survey http://tuxmobil.org/ir_misc.html

## AUTHOR
This manual page is written by Werner Heuser <wehe@tuxmobil.org>. It is based on the READMEs from irda-utils by the Linux/IrDA Project and the Linux/IrDA-Tutorial.

## COPYRIGHT
Copyright (c) 2001 Werner Heuser

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License (GFDL), Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.


irattach

title: irattach(8)

text:
# irattach(8)

## NAME
irattach - binds the Linux-IrDA stack to a IrDA port

## SYNOPSIS
irattach [ <dev> ] [ -s ] [ -d dongle ] [ -v ] [ -h ]

## DESCRIPTION
irattach binds the Linux-IrDA stack to an IrDA port. It configures the low level of the Linux-IrDA stack in the kernel. This step is usually necessary before you (or applications) can use the higher layer of the IrDA stack.

The irattach command loads the necessary Linux-IrDA driver, which configures the IrDA hardware, and configures the IrDA stack to operate on the new IrDA port. Multiple IrDA ports can be activated through multiple irattach commands.

irattach by default uses the irtty driver which connects to the Linux TTY subsystem and use the standard Linux serial driver. This works well for most machines and configurations, but limits the baud rate to 115200bps (IrDA SIR mode). The mode of operation will work with most FIR hardware (as found in laptops - they provide serial emulation) and most serial dongles (provided the proper dongle type is specified), making it a safe choice. However, USB dongles and a few FIR hardware don't support serial emulation and can't be used with the irtty driver.

irattach can also use one of the Linux FIR drivers (including USB dongle drivers) instead of the irtty driver. Most FIR drivers require proper configuration of module parameters (this is documented below). FIR drivers allow you to use higher baud rates (generally up to 4Mbps). In general, Linux FIR support is not as stable and mature, due to lack of time and documentation.

irattach must be run as root or installed setuid root, as it requires root privileges. If you have compiled the IrDA stack as modules (recommended), then you will need to edit the /etc/modules.conf file. See the Infrared-HOWTO for details.

## OPTIONS
<dev> : this is the name of a TTY, an IrDA interface or IrDA driver. irattach decides to use the irtty driver or one of the FIR drivers based on this argument.

•

TTY name : this is the serial port to be configured using the irtty driver, such as /dev/ttyS0. irattach will use the irtty driver, so only SIR will be available. You need to check your serial configuration or BIOS to know which serial port is the IrDA port that need to be passed to irattach.

•

interface name : this is the device name of an IrDA interface, such as irda0. irattach will use one of the FIR drivers (including USB dongle drivers). The selected FIR driver must be loaded prior to the call to irattach, or the proper alias for the device name must be set in /etc/modules.conf.

•

module name : this is the name of an FIR driver module, such as nsc-ircc (see list below). All new IrDA interfaces created after loading the module will be configured, so this won't work if the module is already loaded. This feature is still experimental.

-s : starts discovery of remote IrDA devices (note that the form "-s 1" is no longer supported)

-v : shows version information (this happens, when no option is given, too)

-h : shows help information.

-d dongle : attaches an additional dongle driver to the IrDA port.

You need a dongle driver if you have an infrared device that connects to your computer's serial port (normal 9-pin serial port connector). These devices are called dongles, and can currently be used by any SIR driver (IrTTY or irport). This option is not compatible with FIR drivers, and only works with the irtty and irport drivers.

The currently known (serial) dongles are:

•

esi Extended Systems JetEye PC ESI-9680

•

tekram Tekram IrMate IR-210B dongle

•

actisys ACTiSYS IR-220L dongle

•

actisys+ ACTiSYS IR-220L+ dongle

•

girbil Greenwich GIrBIL dongle

•

litelink Parallax LiteLink dongle & Extended Systems JetEye PC ESI-9680B

•

airport N.N.

•

old_belkin Belkin (old) SmartBeam dongle or any dongle only capable of 9600 bauds

•

ep7211 IR port driver for the Cirrus Logic EP7211 processor (ARM based)

•

mcp2120 Dongles based on the MCP2120 (Microchip)

•

act200l ACTiSYS Ir-200L dongles

•

ma600 Mobile Action ma600 dongles

•

toim3232 Vishay/Temic TOIM3232 and TOIM4232 based dongles

## FIR DRIVER MODULES
If you are one of the lucky people which have a FIR chipset or USB dongle that is supported by one of the Linux-IrDA drivers, you can use irattach with the interface name of the IrDA port to configure. You will need to configure /etc/conf.modules appropriately, with at least an alias of irda0 to the driver name, or load the driver manually beforehand.

You don't strictly need to use irattach with FIR drivers, you can use modprobe to load the driver, ifconfig to bring up the interface and set the various sysctl by hand, but irattach offer a convenient way to do it.

Of course, you need to know which FIR driver applies to your hardware. You may use findchip to get information about the FIR chip. If this doesn't help, the Infrared-HOWTO shows other means to retrieve these data.

Also, you often need to configure the Linux-serial driver to ignore the IrDA port, otherwise both drivers will conflict. This can usually be done with setserial /dev/ttySx uart none.

The currently known FIR drivers are:

•

ali-ircc ALi FIR Controller Driver for ALi M5123 (options: io, irq, dma). This driver supports SIR, MIR and FIR (4Mbps) speeds. This chipset is used by e.g.: The ALi M5123 FIR Controller is embedded in ALi M1543C, M1535, M1535D, M1535+, M1535D South Bridge.

•

irda-usb IrDA-USB device driver, for USB devices/dongles that comply with the official IrDA-USB class specification. Note: USB 2.0 is not yet tested. (options: qos_mtt_bits int, description "Minimum Turn Time"). This is used, for e.g.: ACTiSYS ACT-IR2000U

KC Technology KC-180

Extended Systems XTNDAccess ESI-9685

Note that there is another USB driver for those devices called ir-usb which is NOT compatible with the IrDA stack and conflict with irda-usb. Because it always loads first, you have to remove ir-usb completely.

Devices based on the SigmaTel chip are not not compliant with the IrDA-USB class specification and therfore not supported by this driver.

•

nsc-ircc NSC IrDA device driver (options: io, irq, dma, dongle_id, qos_mtt_bits). This chipset is used by e.g.: IBM ThinkPad dongle_id=0x09

HP OmniBook 6000 dongle_id=0x08

•

sa1100_ir Infrared driver for devices based on the StrongARM SA1100 embedded microprocessor (options: power_level, tx_lpm). This driver may support FIR on devices that can do it. This chipset is used by e.g.: Samsung YOPY, COMPAQ iPAQ, SHARP Zaurus SL5000/5500

•

smc-ircc SMC IrCC controller driver (options: ircc_dma, ircc_irq). This chipset is used by e.g.: Fujitsu-Siemens Lifebook 635t Sony PCG-505TX

•

w83977af_ir Winbond W83977AF IrDA device driver (options: io, irq, qos_mtt_bits). This chipset is used by e.g.: Corel NetWinder

•

toshoboe Toshiba OBOE IrDA device driver, supports Toshiba Type-O IR chipset. (options: max_baud). This chipset is used by e.g.: Toshiba Libretto 100CT., and many more old Toshiba laptops.

•

donauboe is a new version of toshoboe and has better FIR support and compability with the Donauoboe chip http://libxg.free.fr/lib-irda.html (options: ..). This chipset is used by e.g.: Toshiba Libretto 100CT., Tecra 8100, Portege 7020 and many more Toshiba laptops.

•

vlsi_ir VLSI 82C147 SIR/MIR/FIR device driver This chipset is used by e.g.: HP Omnibook 800

(options: ..).

•

clksrc int, description "clock input source selection"

•

ringsize int array (min = 1, max = 2), description "tx, rx ring descriptor size"

•

sirpulse int, description "sir pulse width tuning"

•

mtt_bits int, description "IrLAP bitfield representing min-turn-time"

## EXAMPLES
Attach the IrDA stack to the second serial port (integrated IrDA port using serial emulation) and start discovery:

•

irattach /dev/ttyS1 -s

Attach the IrDA stack to the first serial port where you have an external ACTiSYS serial dongle and start discovery:

•

irattach /dev/ttyS0 -d actisys+ -s

Attach the IrDA stack to the first IrDA-USB dongle and start discovery:

•

modprobe irda-usb ; irattach irda0 -s

Attach the IrDA stack to the NSC FIR (4Mbps) device driver on a Thinkpad laptop:

•

modprobe nsc-ircc dongle_id=0x9 ; irattach irda0 -s.

Attach the IrDA stack to the NSC FIR (4Mbps) device driver on a Thinkpad laptop:

•

irattach irda0 -s. This assume that you have added the following entries to /etc/conf.modules:

options nsc-ircc dongle_id=0x09

alias irda0 nsc-ircc

## CAVEATS
The following hints are a very short introduction into the configuration of Linux/IrDA. If this doesn't help read the Linux/IrDA-Tutorial and/or the Infrared-HOWTO . Before configuring Linux/IrDA make sure whether you want to configure SIR or FIR. It's recommended to try SIR first, unless your device is not compatible with SIR (for example USB dongles).

To get the SIR "serial" device have a look into the BIOS. Then run dmesg | grep tty to get a survey of tty devices supported by your machine. Now try to choose the one, which is probably the IrDA device and use irattach /dev/ttySx -s.

If you don't succeed with SIR (which seems a rare case) you may try FIR. First look up the BIOS. Then run findchip to get information about the IrDA controller chip. Use setserial /dev/ttySx uart none to avoid conflicts with the serial driver. Note: don't use setserial if you configure SIR. Now you may use irattach.

Finally irdadump should show at least your computer itself. If it doesn't start at the beginning.

This man page deal only with the low level of the IrDA stack (IrDA ports and IrDA drivers). After this step is done, you usually need to setup your favorite application to access the high level IrDA stack (via IrCOMM, IrLPT, IrNET, IrLAN or IrSOCK), which is documented elsewhere.

This man page doesn't document the usage of the irport driver. The irport driver support the same hardware as the irtty driver, but is configured like a FIR driver.

## DIAGNOSTICS
This section currently contains the raw error messages from source code only.

"ioctl(TIOCGETD): %m"

"irattach: tty: set_disc(%d): %s"

"tcsetattr: %m"

"Failed to open %s: %m"

"Couldn't get device fd flags: %m"

"Couldn't set device to non-blocking mode: %m"

## BUGS
N.N.

## SEE ALSO
irattach(8), irdaping(8), irdadump(8), findchip(8), irpsion5(8), modprobe(8)

Linux/IrDA Project http://irda.sourceforge.net -*- Linux/IrDA-Tutorial http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/index.html -*- Infrared-HOWTO http://tuxmobil.org/howtos.html -*- Infrared-Hardware-Survey http://tuxmobil.org/ir_misc.html

## AUTHOR
This manual page is written by Werner Heuser <wehe@tuxmobil.org>. It is based on the READMEs from irda-utils by the Linux/IrDA Project and the Linux/IrDA-Tutorial. It was subsequently updated and modified by Jean Tourrilhes <jt@hpl.hp.com>.

## COPYRIGHT
Copyright (c) 2001 Werner Heuser Copyright (c) 2002 Jean Tourrilhes

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License (GFDL), Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.


irdadump

title: irdadump(8)

text:
# irdadump(8)

## NAME
irdadump - monitors the IrDA traffic on one or more links.

## SYNOPSIS
irdadump [ -b ] [ -c n ] [ -d ] [ -x ] [ -s n ] [ -t ] [ -l ] [ -v ] [ -i device ]

## OPTIONS
-b dump bytes in columns

-c n set snapcols for byte printing with -b option

-d prints the time difference between the current and the previous frame

-x dump frame (bytes and ascii)

-s n set snaplen for -b and -x option

-t force TTP decoding of unknown connections

-l set line buffering on output file

-v verbose

-i device interface

## DESCRIPTION
irdadump is a tool for monitoring the IrDA traffic on one or more links. Just write "make" to compile the program. When you run the program, you should be able to see the IrDA traffic (if any).

One advantage of implementing IrDA device drivers as network device drivers is that you should be able to attach sniffers to the device (or actually the packet type). That way, it is possible to use a really handy utility called irdadump (instead of tcpdump). This will make debugging MUCH easier. Linux-2.2 implements the BPF (Berkeley Packet Filter), so its possible to filter out exactly the frames you want to see. You may use hostname to separate different machines names. Or grep to filter the output, too.

irdadump must be run as root or installed setuid root, as it requires root privileges.

## EXAMPLES
The output should look something like this:

```
/ # ./irdadump
20:11:45.412199 xid:cmd 0x0015c23b > 0xffffffff S=6 s=0
20:11:45.492137 xid:cmd 0x0015c23b > 0xffffffff S=6 s=1
20:11:45.572137 xid:cmd 0x0015c23b > 0xffffffff S=6 s=2
20:11:45.652208 xid:cmd 0x0015c23b > 0xffffffff S=6 s=3
20:11:45.732137 xid:cmd 0x0015c23b > 0xffffffff S=6 s=4
20:11:45.812137 xid:cmd 0x0015c23b > 0xffffffff S=6 s=5
20:11:45.892175 xid:cmd 0x0015c23b > 0xffffffff S=6 s=255 Linux
20:11:45.902362 xid:rsp 0xf7be8388 < 0x0015c23b S=6 s=5 ACTiSYS IR100M
20:11:48.412197 xid:cmd 0x0015c23b > 0xffffffff S=6 s=0
20:11:48.492656 xid:cmd 0x0015c23b > 0xffffffff S=6 s=1
20:11:48.572177 xid:cmd 0x0015c23b > 0xffffffff S=6 s=2
20:11:48.652169 xid:cmd 0x0015c23b > 0xffffffff S=6 s=3
20:11:48.732177 xid:cmd 0x0015c23b > 0xffffffff S=6 s=4
20:11:48.812153 xid:cmd 0x0015c23b > 0xffffffff S=6 s=5
20:11:48.822371 xid:rsp 0xf7be8388 < 0x0015c23b S=6 s=4 ACTiSYS IR100M
15 packets received by filter
```

Turning on the "-d" option will make irdadump print the time difference between the current and the previous frame:

```
/ # ./irdadump -d
20:11:18.412475 (0982.06 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=0
20:11:18.492345 (0079.87 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=1
20:11:18.572376 (0080.03 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=2
20:11:18.652979 (0080.60 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=3
20:11:18.732354 (0079.38 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=4
20:11:18.755093 (0022.74 ms) xid:rsp 0xf7be8388 < 0x0015c23b S=6 s=3 ACTiSYS IR100M
20:11:18.812350 (0057.26 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=5
20:11:18.892518 (0080.17 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=255 Linux
20:11:21.412486 (2519.97 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=0
20:11:21.492395 (0079.91 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=1
20:11:21.572368 (0079.97 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=2
20:11:21.652405 (0080.04 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=3
20:11:21.732458 (0080.05 ms) xid:cmd 0x0015c23b > 0xffffffff S=6 s=4
```

irdadump must be run as root or installed setuid root, as it requires root privileges. irdadump -d -x -s 256 will check the contents of the frames. This should tell us if the frames have malformed content, or if the irda stack is doing something wrong.

## DIAGNOSTICS
N.N.

## BUGS
N.N.

## SEE ALSO
irattach(8), irdaping(8), irdadump(8), findchip(8), irpsion5(8), modprobe(8)

Linux/IrDA Project http://irda.sourceforge.net -*- Linux/IrDA-Tutorial http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/index.html -*- Infrared-HOWTO http://tuxmobil.org/howtos.html

## AUTHOR
This manual page is written by Werner Heuser <wehe@tuxmobil.org>. It is based on the READMEs from irda-utils by the Linux/IrDA Project and the Linux/IrDA-Tutorial.

## COPYRIGHT
Copyright (c) 2001 Werner Heuser

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License (GFDL), Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.


irdaping

title: irdaping(8)

summary: sends IrDA test frames

text:
# irdaping(8)

## NAME
irdaping - sends IrDA test frames

## SYNOPSIS
irdaping [ daddr ] [ -s framesize ]

## OPTIONS
daddr ...

-s framesize ...

## DESCRIPTION
This is a program similar to ping(8). It sends IrDA test frames (added some userdata which contains the frame number and the time the frame was sent). You can change the size of the frame by using the -s option. To get daddr you may use irdadump.

irdaping must be run as root or installed setuid root, as it requires root privileges.

## EXAMPLES
irdaping <daddr> [-s <framesize>]

You may use an alias, which does not use any parameter alias irping="irdaping \`grep daddr /proc/net/irda/discovery|sed s/.*daddr://\`" It works fine when there is only one discovered client.

## DIAGNOSTICS
N.N.

## BUGS
N.N.

## SEE ALSO
irattach(8), irdaping(8), irdadump(8), findchip(8), irpsion5(8), modprobe(8)

Linux/IrDA Project http://irda.sourceforge.net -*- Linux/IrDA-Tutorial http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/index.html -*- Infrared-HOWTO http://tuxmobil.org/howtos.html

## AUTHOR
This manual page is written by Werner Heuser <wehe@tuxmobil.org>. It is based on the READMEs from irda-utils by the Linux/IrDA Project and the Linux/IrDA-Tutorial.

## COPYRIGHT
Copyright (c) 2001 Werner Heuser

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License (GFDL), Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.


irnetd

title: irnetd(8)

text:
# irnetd(8)

## NAME
irnetd - Handle automatically incoming IrNET connections

## SYNOPSIS
irnetd [ppp-options]

## DESCRIPTION
Irnetd is a very simple daemon automatically handling incoming IrNET connections. Every time a peer attempt to connect to the local computer, irnetd generates the relevant pppd(8) command to starts an IrNET server handling this peer.

## PARAMETERS
ppp-options

Override the default pppd(8) options. These options will just be passed on the command line of pppd(8). The default options are "noauth nolock connect-delay 0 idle 10" which should fit most usages.

## AUTHOR
Jean Tourrilhes - jt@hpl.hp.com

## FILES
/dev/irnet

## SEE ALSO
irda(7), irnet(4), pppd(8), irattach(8), irdadump(8).


title: irpsion5(8)

summary: IrDA connectivity to a Psion V PDA

text:
# irpsion5(8)

## NAME
irpsion5 - IrDA connectivity to a Psion V PDA

## SYNOPSIS
irpsion5 [ -s file ] [ -r ] [ -b ] [ -v ] [ -q ] [ -S ms ] [ -D n ]

## OPTIONS
-s file send file to the Psion

-r receive a file from the Psion

-b receive multiple files (batch mode)

-v verbose mode, progress indication

-q quiet mode, no progress indication

-S ms set discovery slot timeout, standard 80ms, default 120ms

-D n debug level

## DESCRIPTION
N.N.

irpsion5 must be run as root or installed setuid root, as it requires root privileges.

## EXAMPLES
N.N.

## DIAGNOSTICS
Error: unknown switch %s

Call without args for usage: %s

## SEE ALSO
irattach(8), irdaping(8), irdadump(8), findchip(8), irpsion5(8), modprobe(8)

Linux/IrDA Project http://irda.sourceforge.net -*- Linux/IrDA-Tutorial http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/index.html -*- Infrared-HOWTO http://tuxmobil.org/howtos.html

## AUTHOR
This manual page is written by Werner Heuser <wehe@tuxmobil.org>. It is based on the READMEs from irda-utils by the Linux/IrDA Project and the Linux/IrDA-Tutorial.

## COPYRIGHT
Copyright (c) 2001 Werner Heuser

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License (GFDL), Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.


smcinit

title: smcinit(8)

text:
# smcinit(8)

## NAME
smcinit - initialize the SMSC IrDA controler on various laptops

## SYNOPSIS
smcinit [OPTIONS]

## DESCRIPTION
Toshiba Satellite 1800, Satellite 5100, Tecra 9100 laptops and may be many other models are provided with a SMCS LPC47N227 SuperIO chip which is IrDA SIR/FIR capable. The IrDA subsystem of the SuperIO chip is supported by the smc-ircc Linux kernel module. Unfortunately the BIOS neither configurates the SuperIO chip IrDA subsystem (SIR port, FIR port, dma, irq, IrDA mode, power) nor sets the PCI-ISA bridge to decode any usable port. Linux kernel is thus prevented to detect the second UART making impossible to use it in SIR mode. For the same reason, the FIR mode smc-ircc is able to detect the SuperIO chip but, once found the IrDA subsystem unconfigured, fails to install.

While this problem will be fixed in Linux 2.6.x kernel series, the 2.4.x users are frustrated. Daniele Peri, Rob Miller and Paul Hampson mananged to build little utilities that initialize the LPC47N227 SuperIO allowing smc-ircc IrDA kernel driver to detect and use the SMSC chip.

My sole work was to put these utilities as one package, easy to install and use.

## OPTIONS
-V, --version

Show program version and exit

-h, --help

Show a little help on options and exit

-v, --verbose

Increase the details about actions performed

-t, --tty=device

If specified, the serial device will be unbound from the kernel stock serial driver. It is there to replace an external call to setserial(1) to unset the UART of the device. There is no default value.

-s, --sirio=IO

Set the SIR (serial infrared) I/O port address to IO. Default value is 0x3f8.

-f, --firio=IO

Set the FIR (fast infrared) I/O port address to IO. Default value is 0x130.

-i, --firirq=IRQ

Set the FIR (fast infrared) IRQ line to IRQ. Default value is 3.

-d, --firdma=DMA

Set the FIR (fast infrared) DMA channel to DMA. Default value is 3.

## CONFIGURATION
When system startup a script is run from /etc/init.d and which run appropriate SMC intialization utility. This is done before PCMCIA startup because on Tecra 9100 and other models the orinoco_cs wireless driver will block the I/O region used 47N227 SuperIO.

The only configuration file is /etc/sysconfig/smcinit and the variable SMCCONFIG can be set to "1800" or "5100". By default "5100" value is used.

1800

for Toshiba Satellite 1800

5100

for Toshiba Satellite 5100 and Toshiba Tecra 9100

The next step is to configure the kernel IrDA stack package to attach the smc-ircc driver. This is Linux distribution specific. The main thing is that the device should be set to "irda0". Run the following command:

```
irattach irda0 -s
```

Distribution specific configuration:

SuSE

Edit the /etc/sysconfig/irda and set IRDA_PORT=irda0

RedHat

Edit the /etc/sysconfig/irda and set DEVICE=irda0

## NOTES
The smc-ircc driver is preloaded in kernel. I tested the package only on Tecra 9100 without any additional step, but for Toshiba Satellite 1800 Daniele Peri sugest to put the following line in your /etc/modules.conf (on one line):

```
options smc-ircc ircc_dma=3 ircc_irq=7 ircc_cfg=0x2e \

        ircc_sir=0x2e8 ircc_fir=0x2f8
```

After that run the command:

```
prompt# depmod -a
```

If the laptop enter suspend mode, then resume operation the smc-ircc driver will stop working. You need to stop IrDA service, then SMCINIT, start SMCINIT, and finally start IrDA service. Simply put, the kernel driver must be unloaded, then reloaded.

## FILES
/etc/sysconfig/smcinit

Configuration file for SMCINIT startup script. It's shell script.

## AUTHOR
This document is made by Claudiu Costin <claudiuc@kde.org> The utilities authors are Daniele Peri, Rob Miller and Paul Hampson. Thomas Pinz made improvements to tosh-smcinit (the former tosh5100-smcinit) to expand the number of Toshiba Satellite models supported.

## SEE ALSO
smcinit(7),

tosh1800-smcinit(8),

irattach(1),

irdadump(1),

http://irda.sourceforge.net/smcinit/ the SMCINIT package home page.


title: tosh1800-smcinit(8)

text:
# tosh1800-smcinit(8)

## NAME
tosh1800-smcinit - initialize the IrDA controler on Toshiba laptops

## SYNOPSIS
tosh1800-smcinit [OPTION]

## DESCRIPTION
IrDA configurator for laptops with ALI1533 bridge (LPC47N227 SuperIO), smc-ircc and not initializing BIOS (tested on Toshiba Satellite 1800-514, Toshiba Satellite 5100 and Toshiba Tecra 9100) to be used with Linux kernel.

Toshiba Satellite 1800 laptops are provided with a SMCS LPC47N227 SuperIO chip which is IrDA SIR/FIR capable. The chip is connected through an ALI1533 PCI-ISA bridge. The IrDA subsystem of the SuperIO chip is supported by the smc-ircc Linux kernel module. Unfortunately the BIOS neither configurates the SuperIO chip IrDA subsystem (SIR port, FIR port, dma, irq, IrDA mode, power) nor sets the PCI-ISA bridge to decode any usable port. Linux kernel is thus prevented to detect the second UART making impossible to use it in SIR mode. For the same reason, the FIR mode smc-ircc is able to detect the SuperIO chip but, once found the IrDA subsystem unconfigured, fails to install.

tosh1800-smcinit sets SIR and FIR ioport addresses, DMA and IRQ of the SuperIO chip IrDA subsystem then powers on the second UART. It also configures the PCI-ISA bridge to decode SIR and FIR ports. All this configuration work should be rather done into the kernel but it was more practical and safe to make a small testing tool of it. It can be probably extended to include configuration kludges for other similar SuperIO and ISA bridge combination.

Testing was carried on a Toshiba Satellite 1800-514 with Linux kernel 2.4.17. I hope this work could be helpful, it was quite funny to do it however.

## OPTIONS
-a, --skip-decoding-cfg

Skip ISA bridge decoding configuration.

-b, --skip-smc-ircc-cfg

Skip SMC-IRCC configuration.

-v, --vendor=VALUE

Look for the specified ISA bridge PCI vendor ID

-x, --device=VALUE

Look for the specified ISA bridge PCI device ID

-c, --cfgbase=VALUE

Set SMC-IRCC IO cfgbase address. Usual value can be 0x2e.

-s, --sirbase=VALUE

Set SMC-IRCC IO sirbase address. Usual value can be 0x2e8.

-f, --firbase=VALUE

Set SMC-IRCC IO firbase address. Usual value can be 0x2f8.

-m, --dma=VALUE

Set SMC-IRCC DMA channel. Usual value can be 3.

-i, --irq=VALUE

Set SMC-IRCC IRQ. Usual value can be 7.

-p, --print

Print ISA bridge configuration.

-V, --version

Show program version.

-h, --help

Show program options.

## AUTHOR
This program was made by Daniele Peri <peri@csai.unipa.it>

## CREDITS
SMSC for the downloadable datasheets

Paul Hampson for its Linux IrDA mailing list messages.

Manual page written by Claudiu Costin <claudiuc@kde.org>. Documentation based on original README by Daniele Peri.

## SEE ALSO
irattach(1),

irdadump(1),

http://lancelot.csai.unipa.it/~peri/ Daniele Peri's home page,

http://irda.sourceforge.net/smcinit/ the SMCINIT package home page.


iscan-registry

package: iscan-free

title: iscan-registry(8)

summary: (un)register iscan interpreter plugins

text:
# iscan-registry(8)

## NAME
iscan-registry - (un)register iscan interpreter plugins

## SYNOPSIS
iscan-registry --help | --version

iscan-registry --add <spec>

iscan-registry --remove <spec>

## DESCRIPTION
'iscan-registry' updates the run-time data for Image Scan! for Linux

Image Scan! for Linux plugins may need to (un)register themselves. This utility gives plugins a common interface to do just that. You should not need to use this utility manually.

The following options are supported:

-h, --help

displays this message and exit

-v, --version

displays program version and exit

-a, --add

adds a plugin to the run-time data

-r, --remove

removes a plugin from the run-time data

The following <spec>s are supported:

interpreter usb <vendor-id> <product-id> <plugin> [<firmware>]

The <vendor-id> and <product-id> are the USB IDs in hexadecimal notation, prefixed with '0x'. <plugin> and optional <firmware> are pathnames to the corresponding files. Note that the <plugin> pathname should not include an extension.

## AUTHOR
Written by AVASYS CORPORATION.

## COPYRIGHT
Copyright © 2008 SEIKO EPSON CORPORATION

This is free software. You may redistribute copies of it under the terms of the GNU General Public License, version 2 or later. See <http://www.gnu.org/licenses/gpl.html> for details.


title: iucode_tool(8)

summary: Tool to manipulate Intel\*R IA-32/X86-64 microcode bundles

text:
# iucode_tool(8)

## NAME
iucode_tool - Tool to manipulate Intel® IA‐32/X86‐64 microcode bundles

## SYNOPSIS
iucode_tool [options] [[-ttype] filename|dirname] ...

## DESCRIPTION
iucode_tool is an utility that can load Intel® processor microcode data from files in both text and binary microcode bundle formats.

It can output a list of the microcodes in these files, merge them, upload them to the kernel (to upgrade the microcode in the system processor cores) or write some of them out to a file in binary format for later use.

iucode_tool will load all microcodes in the specified files and directories to memory, in order to process them. Duplicated and outdated microcodes will be discarded. It can read microcode data from standard input (stdin), by specifying a file name of “-” (minus sign).

Microcode data files are assumed to be in .dat text format if they have a .dat suffix, and to be in binary format otherwise. Standard input (stdin) is assumed to be in .dat text format. The -t option can be used to change the type of the files specified after it, including for stdin.

If a directory is specified, all files whose names do not begin with a dot will be loaded, in unspecified order. Nested directories are skipped.

Empty files and directories are ignored, and will be skipped.

You can select which microcodes should be written out, listed or uploaded to the kernel using the -S, -s, --date-before and --date-after options. Should none of those options be specified, all microcodes will be selected.

You can upload the selected microcodes to the kernel, write them out to a file (in binary format), to a Linux early initramfs archive, to per-processor-signature files in a directory, or to per-microcode files in a directory using the -w, --write-earlyfw, -k, -K, and -W options.

iucode_tool will identify microcodes in its output and error messages using a “n/k” notation, where “n” is the bundle number, and “k” is the microcode number within that bundle. The output of the --list-all option when processing multiple input files is the best example of how it works.

For more information about Intel processor microcodes, please read the included documentation and the Intel manuals listed in the SEE ALSO section.

## OPTIONS
iucode_tool accepts the following options:

-q, --quiet

Inhibit usual output.

-v, --verbose

Print more information. Use more than once for added verbosity.

-h, -?, --help

List all available options and their meanings.

--usage

Show summary of options.

-V, --version

Show version of program.

-t type

Sets the file type of the following files. type can be:

b

binary format. This is the same format used by the kernel driver and the BIOS/EFI, which is described in detail by the Intel 64 and IA‐32 Architectures Software Developer's Manual, Volume 3A, section 9.11.

d

Intel microcode .dat text format. This is the format normally used by Intel to distribute microcode data files.

r

recover microcode in binary format. Search uncompressed generic binary files for microcodes in Intel microcode binary format to recover. Note: It can find microcode that will not pass strict checks, and thus cause iucode_tool to exit if the --no-strict-checks or --ignore-broken options are not in effect.

a

(default) iucode_tool will use the suffix of the file name to select the file type: .dat text format for files that have a .dat suffix, and binary type otherwise. Note that for stdin, .dat text format is assumed.

--downgrade

When multiple versions of the microcode for a specific processor are available from different files, keep the one from the file loaded last, regardless of revision levels. Files are always loaded in the order they were specified in the command line. This option has no effect when just one file has been loaded.

--no-downgrade

When multiple versions of the microcode for a specific processor are available from different files, keep the one with the highest revision level. This is the default mode of operation.

--strict-checks

Perform strict checks on the microcode data. It will refuse to load microcodes and microcode data files with unexpected size and metadata. It will also refuse to load microcode entries that have the same metadata, but different payload. This is the default mode of operation.

--no-strict-checks

Perform less strict checks on the microcode data. Use only if you happen to come across a microcode data file that has microcodes with weird sizes or incorrect non-critical metadata (such as invalid dates), which you want to retain. If you just want to skip those, use the --ignore-broken option.

--ignore-broken

Skip broken microcode entries when loading a microcode data file, instead of aborting program execution. If the microcode entry has an unsupported format or had its header severely corrupted, all remaining data in the file will have to be ignored. In that case, using a file type of recover microcode in binary format (-tr option) is recommended, as it can skip over badly mangled microcode data.

--no-ignore-broken

Abort program execution if a broken microcode is found while loading a microcode data file. This is the default mode of operation.

-s ! | [!]signature[,[pf_mask][,[lt:|eq:|gt:]revision]]

Select microcodes by the specified signature, processor flags mask (pf_mask), and revision. If the processor flags mask is specified, it will select only microcodes that are suitable for at least one of the processor flag combinations present in the mask.

If the revision is specified, optionally prefixed by one of the “eq:”, “lt:” or “gt:” operators, it will select only microcodes that have that same revision (if no operator, or if the “eq:” operator is used), or microcodes that have a revision that is less than (“lt:” operator), or greater than (“gt:” operator), the one specified.

Specify more than once to select more microcodes. This option can be combined with the --scan-system option to select more microcodes. If signature is prefixed with a “!” (exclamation mark), it will deselect microcodes instead. Ordering matters, with later -s options overriding earlier ones, including --scan-system.

When specifying signature and pf_mask, hexadecimal numbers must be prefixed with “0x”, and octal numbers with “0”. Decimal numbers must not have leading zeros, otherwise they would be interpreted as octal numbers.

The special notation -s! (with no signature parameter) instructs iucode_tool to require explicit inclusion of microcode signatures (using the non-negated form of -s, or using --scan-system).

-S, --scan-system[=mode]

Select microcodes by scanning online processors on this system for their signatures. This option can be used only once, and it can be combined with the -s option to select more microcodes. The microcodes selected by --scan-system can also be deselected by a later -s !signature option.

The optional mode argument (accepted only by the long version of the option) selects the strategy used to scan processors:

0 or auto

Currently the same as fast, but this might change in future versions if Intel ever deploys multi-signature systems that go beyond mixed-stepping. This is the default mode of operation, for backwards compatibility with previous versions of iucode_tool.

1 or fast

Uses the cpuid instruction to detect the signature of the processor iucode_tool is running on, and selects all steppings for that processor's type, family and model. Supports mixed-stepping systems.

2 or exact

Uses kernel drivers to scan the signature of every online processor directly. This mode supports multi-signature systems. This scan mode will be slow on large systems with many processors, and likely requires special permissions (such as running as the root user). Should the scan fail for any reason, as a fail-safe measure, it will issue an warning and consider all possible steppings for every signature it did manage to scan successfully.

--date-before=YYYY-MM-DD and --date-after=YYYY-MM-DD

Limit the selected microcodes by a date range. The date must be given in ISO format, with four digits for the year and two digits for the month and day and “-” (minus sign) for the separator. Dates are not range-checked, so you can use --date-after=2000-00-00 to select all microcodes dated since January 1st, 2000.

--loose-date-filtering

When a date range is specified, all revisions of the microcode will be considered for selection (ignoring just the date range, all other filters still apply) should any of the microcode's revisions be within the date range.

--strict-date-filtering

When a date range is specified, select only microcodes which are within the date range. This is the default mode of operation.

-l, --list

List selected microcode signatures to standard output (stdout).

-L, --list-all

List all microcode signatures while they're being processed to standard output (stdout).

-k[device], --kernel[=device]

Upload selected microcodes to the kernel. Optionally, the device path can be specified (default: /dev/cpu/microcode). This update method is deprecated: it will be removed eventually from the kernel and from iucode_tool.

-K[directory], --write-firmware[=directory]

Write selected microcodes with the file names expected by the Linux kernel firmware loader. Optionally, the destination directory can be specified (default: /lib/firmware/intel‐ucode).

-wfile, --write-to=file

Write selected microcodes to a file in binary format.

--write-earlyfw=file

Write selected microcodes to an early initramfs archive, which should be prepended to the regular initramfs to allow the kernel to update processor microcode very early during system boot.

-Wdirectory, --write-named-to=directory

Write selected microcodes to the specified directory, one microcode per file, in binary format. The file names reflect the microcode signature, processor flags mask and revision.

--write-all-named-to=directory

Write every microcode to the specified directory, one microcode per file, in binary format. The file names reflect the microcode signature, processor flags mask and revision. This is the only way to write out every revision of the same microcode.

--overwrite

Remove the destination file before writing, if it exists and is not a directory. The destination file is not overwritten in-place. Hardlinks will be severed, and any existing access permissions, ACLs and other extended attributes of the old destination file will be lost.

--no-overwrite

Abort if the destination file already exists. This is the default mode of operation. Do note that iucode_tool does not follow non-directory symlinks when writing files.

--mini-earlyfw

Optimize the early initramfs cpio container for minimal size. It will change the cpio block size to 16 bytes, and remove header entries for the parent directories of the microcode data file. As a result, the microcode data file will not be available to the regular initramfs, and tools might complain about the non-standard cpio block size. This will typically reduce the early initramfs size by 736 bytes.

--normal-earlyfw

Optimize the early initramfs size for tool compatibility. This is the default mode of operation. The microcode data file will be available inside the regular initramfs as well.

## NOTES
iucode_tool reads all data to memory before doing any processing. It enforces a sanity limit of a maximum of 1GiB worth of binary microcode data per microcode data file.

All informational and error messages are sent to standard error (stderr), while user-requested output (such as output generated by the list options) is sent to standard output (stdout).

iucode_tool creates files with permissions 0644 (rw-r--r--), modified by the current umask.

iucode_tool's selected microcode listing and microcode output files are sorted first by processor signature (in ascending order), and then by processor flags mask (in descending order).

When multiple revisions of a microcode are selected, the older ones will be skipped. Only the newest selected revision of a microcode (or the last one in load order when the --downgrade option is active) will be written to a file or uploaded to the kernel.

Intel microcode data files, both in binary and text formats, can be concatenated to generate a bigger and still valid microcode data file.

iucode_tool does not follow symlinks when writing microcode data files. It will either refuse to write the file and abort (default mode of operation), or (when the --overwrite option is active) it will remove the target symlink or file (and therefore breaking hardlinks) before writing the new file.

iucode_tool does follow directory symlinks to locate the directory to write files into.

### Linux Notes
Before Linux v4.4, the microcode update driver was split in two parts: the early microcode update driver (which gets microcode data from the initramfs) and the late microcode update driver, which could be a module and got microcode data from the firmware subsystem. The two drivers were unified in Linux v4.4.

The microcode update driver needs to be present in the system at all times to ensure microcode updates are reapplied on resume from suspend and CPU hotplug. Do not unload the microcode module, unless you really know better. Since Linux v4.4, the late microcode driver cannot be a module anymore and will always be present in the system when enabled.

Updating microcode early is safer. It can only be done at boot and it requires an initramfs, but it is strongly recommended: late microcode updates (which read microcode data from /lib/firmware) cannot safely change visible processor features.

Early microcode updates are available since Linux v3.9. They can safely change visible processor features (such as the microcode updates that disabled Intel TSX instructions on Intel Haswell cores do). They require an uncompressed initramfs image with the microcode update data in /kernel/x86/microcode/GenuineIntel.bin. This uncompressed initramfs image must come before any compressed initramfs image(s), and it has an special name: early initramfs.

The microcode update data inside the early initramfs image must be aligned to a 16‐byte boundary due to a bug in several versions of the Linux kernel early microcode update driver. This requires special steps when creating the initramfs archive with the microcode data, and will be handled automatically by the iucode_tool --write-earlyfw option.

Since Linux v4.2, it is also possible to build a kernel with the microcode update data as built-in firmware, using the CONFIG_FIRMWARE_IN_KERNEL facility. This feature is not yet mature as of Linux v4.2.8, v4.4.11, v4.5.5 and v4.6, and might not work in every case.

The /dev/cpu/microcode update interface has been deprecated and should not be used. It has one special requirement: each write syscall must contain whole microcode(s). It can be accessed through iucode_tool --kernel.

Up to Linux v3.5, late microcode updates were required to be triggered per-core, by writing the number 1 to /sys/devices/system/cpu/*/microcode/reload for every cpu. Depending on kernel version, you must either trigger it on every core to avoid a dangerous situation where some cores are using outdated microcode, or the kernel will accept the request only for the boot processor and use it to trigger an update on all system processor cores.

Since Linux v3.6, the late microcode update driver has a new interface that explicitly triggers an update for every core at once when the number 1 is written to /sys/devices/system/cpu/microcode/reload.

## EXAMPLES

### Updating files in /lib/firmware/intel‐ucode:
iucode_tool -K/lib/firmware/intel-ucode \

/lib/firmware/intel-ucode \

/tmp/file-with-new-microcodes.bin

### Processing several compressed files at once:
zcat intel-microcode*.dat.gz | iucode_tool -l -

zcat intel-microcode*.bin.gz | iucode_tool -l -tb -

### Selecting microcodes and creating an early initramfs:
iucode_tool --scan-system \

--write-earlyfw=/tmp/early.cpio \

/lib/firmware/intel-ucode

iucode_tool -s 0x106a5 -s 0x106a4 -l /lib/firmware/intel-ucode

### Using the recovery loader to load and to update microcode in an early initramfs:
iucode_tool -L -tr /boot/intel-ucode.img

iucode_tool -Ll -S --write-earlyfw=/boot/intel-ucode.img.new \

-tr /boot/intel-ucode.img -tb /lib/firmware/intel-ucode && \

mv /boot/intel-ucode.img.new /boot/intel-ucode.img

## BUGS
Microcode with negative revision numbers is not special-cased, and will not be preferred over regular microcode.

The downgrade mode should be used only for microcodes with the same processor flags mask. It cannot handle the corner cases where modifying a processor flags mask would be required to force the kernel to load a lower revision of a microcode, and iucode_tool will issue an warning when that happens. So far, this has not proved to be a relevant limitation as changes to the processor flags mask of post-launch, production microcode updates are very rare.

The loader version microcode metadata field is ignored by iucode_tool. This shouldn't cause problems as long as the same signature never needs more than a single type of loader.

Files are not replaced atomically: if iucode_tool is interrupted while writing to a file, that file will be corrupted.

## SEE ALSO
The Intel 64 and IA‐32 Architectures Software Developer's Manual, Volume 3A: System Programming Guide, Part 1 (order number 253668), section 9.11.

## AUTHOR
Henrique de Moraes Holschuh <hmh@hmh.eng.br>


iw

package: iw

title: iw(8)

text:
# iw(8)

## NAME
iw - show / manipulate wireless devices and their configuration

## SYNOPSIS

iw [ OPTIONS ] { help [ command ] | OBJECT COMMAND }

OBJECT := { dev | phy | reg }

OPTIONS := { --version | --debug }

## OPTIONS
--version

print version information and exit.

--debug

enable netlink message debugging.

## IW - COMMAND SYNTAX

### OBJECT
dev <interface name>

- network interface.

phy <phy name>

- wireless hardware device (by name).

phy#<phy index>

- wireless hardware device (by index).

reg

- regulatory agent.

### COMMAND
Specifies the action to perform on the object. The set of possible actions depends on the object type. iw help will print all supported commands, while iw help command will print the help for all matching commands.

## SEE ALSO
ip(8), crda(8), regdbdump(8), regulatory.bin(5).

Documentation at kernel wiki.


iwpmd

package: iwpmd

title: iwpmd(8)

summary: port mapping services for iWARP.

text:
# iwpmd(8)

## NAME
iwpmd - port mapping services for iWARP.

## SYNOPSIS

```
iwpmd
```

## DESCRIPTION
The iWARP Port Mapper Daemon provides a user space service (iwpmd) for the iWarp drivers to claim tcp ports through the standard socket interface.

The kernel space support for the port mapper is part of the iw_cm module. The ib_core module includes netlink support, which is used by the port mapper clients to exchange messages with iwpmd. Both modules iw_cm and ib_core need to be loaded in order for the libiwpm service to start successfully.

## IWARP PORT MAPPING DETAILS
The iWARP Port Mapper implementation is based on the port mapper specification section in the Sockets Direct Protocol: http://www.rdmaconsortium.org/home/draft-pinkerton-iwarp-sdp-v1.0.pdf

Existing iWARP RDMA providers use the same IP address as the native TCP/IP stack when creating RDMA connections. They need a mechanism to claim the TCP ports used for RDMA connections to prevent TCP port collisions when other host applications use TCP ports. The iWARP Port Mapper provides a standard mechanism to accomplish this. Without this service it is possible for RDMA application to bind/listen on the same port which is already being used by native TCP host application. If that happens the incoming TCP connection data can be passed to the RDMA stack with error.

The iWARP Connection Manager (port mapper client) sends to the IWPM service the local IP address and TCP port it has received from the RDMA application, when starting a connection. The IWPM service performs a socket bind from user space to get an available TCP port, called a mapped port, and communicates it back to the client. In that sense, the IWPM service is used to map the TCP port, which the RDMA application uses to any port available from the host TCP port space. The mapped ports are used in iWARP RDMA connections to avoid collisions with native TCP stack which is aware that these ports are taken. When an RDMA connection using a mapped port is terminated, the client notifies the IWPM service, which then releases the TCP port.

The message exchange between iwpmd and the iWARP Connection Manager (between user space and kernel space) is implemented using netlink sockets.

## OPTIONS
-s, --systemd Enable systemd integration.

## SIGNALS
SIGUSR1 will force a dump of the current mappings to the system message log.

SIGTERM/SIGHUP will force iwpmd to exit.

## FILES
/etc/iwpmd.conf

## SEE ALSO
rdma_cm(7)


package: jfsutils

title: jfs_debugfs(8)

summary: shell-type JFS file system editor

text:
# jfs_debugfs(8)

## NAME
jfs_debugfs - shell-type JFS file system editor

## SYNOPSIS
jfs_debugfs device

## DESCRIPTION
jfs_debugfs is a program which can be used to perform various low-level actions on a JFS formatted device.

device is the special file name corresponding to the actual device to be edited (e.g. /dev/hdb1).

jfs_debugfs must be run as root.

## COMMANDS
a[lter] <block> <offset> <hex_string>

replaces the data located at the <offset> of <block> with <hex_string> <block> is the block number - given in decimal

<offset> is the offset within that block - given in hexadecimal

<hex_string> is an even-numbered string of hexadecimal digits to write to the disk

b[tree] <block> [<offset>]

* not implemented yet *

displays one node of the btree located at <offset> of <block> and enters a subcommand mode to navigate the btree SUBCOMMANDS:

l => visit left sibling

m => modify current node

p => visit parent node

r => visit right sibling

[0-9] => visit the n'th child node

x => exit subcommand mode

cb[blfsck]

displays the area used by ClearBadBlockList for communication with fsck SUBCOMMANDS:

m => modify entries

x => exit subcommand mode

dir[ectory] <inode_number> [<file_set>]

displays the directory entries at <inode_number> and enters subcommand mode <inode_number> is the directory's inode - given in decimal

<file_set> currently must be zero

SUBCOMMANDS:

m => modify entries

x => exit subcommand mode

d[isplay] [<block> [<offset> [<format> [<count>]]]]

displays <count> objects located at the <offset> of <block> in <format> <block> is the block number - given in decimal

<offset> is the offset within <block> - given in hexadecimal

<format> is one of the following:

a => ascii

b => block allocation map

d => decimal

i => inode

I => inode allocation map

s => superblock

x => hexadecimal

X => extent allocation descriptor

<count> is the number of objects to display - given in decimal

dm[ap]

displays aggregate disk (block) map SUBCOMMANDS

m => modify map fields

f => display free count

t => display tree levels

x => exit subcommand mode

dt[ree] <inode_number> [<file_set>]

displays root of the directory btree located at <inode_number> and enters a subcommand mode to navigate the btree <inode_number> is the directory's inode - given in decimal

<file_set> currently must be zero

SUBCOMMANDS

l => visit left sibling

m => modify current node

p => visit parent node (not parent directory)

r => visit right sibling

[0-9] => visit the n'th child node

x => exit subcommand mode

fsckw[sphdr]

displays the header of the fsck workspace in the aggregate SUBCOMMANDS:

m => modify entries

x => exit subcommand mode

h[elp] [<command>]

displays help for <command>

if no command is given, all possible commands are displayed

ia[g] [<IAG_number>] [a | s | <file_set>]

displays IAG information for <IAG_number> and enters subcommand mode <IAG_number> is given in decimal

a is to use the primary aggregate inode table

s is to use the secondary aggregate inode table

<file_set> currently must be zero

SUBCOMMANDS

e => display/modify inode extents map

m => modify IAG

p => display/modify persistent map

w => display/modify working map

x => exit subcommand mode

i[node] [<inode_number>] [a | s | <file_set>]

displays inode information for <inode_number> and enters subcommand mode <inode_number> is given in decimal

a is to use the primary aggregate inode table

s is to use the secondary aggregate inode table

<file_set> currently must be zero

SUBCOMMANDS

a => display/modify inode's ACL

m => modify inode

x => exit subcommand mode

logs[uper]

displays the journal log superblock and enters subcommand mode SUBCOMMANDS

m => modify journal log superblock

x => exit subcommand mode

q[uit]

exits jfs_debugfs

se[t] [<variable> <value>]

* not implemented yet *

set user-defined <variable> to <value>

if no arguments are given, displays all set variables <variable> must begin with an alphabetic character

su[perblock] [p | s]

displays superblock data p displays the primary superblock

s displays the secondary superblock

SUBCOMMANDS:

m => modify entries

x => exit subcommand mode

s2p[erblock] [p | s]

displays alternate superblock data p displays the primary superblock

s displays the secondary superblock

SUBCOMMANDS:

m => modify entries

x => exit subcommand mode

u[nset] <variable>

* not implemented yet *

deletes user-defined <variable>

xt[ree] <inode_number> [<file_set>]

displays root of the non-directory btree located at <inode_number> and enters a subcommand mode to navigate the btree <inode_number> is the directory's inode - given in decimal

<file_set> currently must be zero

SUBCOMMANDS

l => visit left sibling

m => modify current node

p => visit parent node (not parent directory)

r => visit right sibling

[0-9] => visit the n'th child node

x => exit subcommand mode

## REPORTING BUGS
If you find a bug in JFS or jfs_debugfs, please report it via the bug tracking system ("Report Bugs" section) of the JFS project web site:

```
http://jfs.sourceforge.net/
```

Please send as much pertinent information as possible, including the complete output of running jfs_fsck with the -v and -n options on the JFS device.

## SEE ALSO
jfs_fsck(8), jfs_mkfs(8), jfs_fscklog(8), jfs_logdump(8), jfs_tune(8),

## AUTHORS

```
Barry Arndt  (barndt@us.ibm.com)
William Braswell, Jr.
```

jfs_debugfs is maintained by IBM.

```
See the JFS project web site for more details:
http://jfs.sourceforge.net/
```


title: jfs_fsck(8)

text:
# jfs_fsck(8)

## NAME
jfs_fsck - initiate replay of the JFS transaction log, and check and repair a JFS formatted device

## SYNOPSIS
jfs_fsck [ -afnpvV ] [ -j journal_device ] [ --omit_journal_replay ] [ --replay_journal_only ] device

## DESCRIPTION
jfs_fsck is used to replay the JFS transaction log, check a JFS formatted device for errors, and fix any errors found.

device is the special file name corresponding to the actual device to be checked (e.g. /dev/hdb1).

jfs_fsck must be run as root.

## WARNING
jfs_fsck should only be used to check an unmounted file system or a file system that is mounted READ ONLY. Using jfs_fsck to check a file system mounted other than READ ONLY could seriously damage the file system!

## OPTIONS
If no options are selected, the default is -p.

-a

Autocheck mode - Replay the transaction log. Do not continue fsck processing unless the aggregate state is dirty or the log replay failed. Functionally equivalent to -p. Autocheck mode is typically the default mode used when jfs_fsck is called at boot time.

-f

Replay the transaction log and force checking even if the file system appears clean. Repair all problems automatically.

-j journal_device

Specify the journal device.

-n

Open the file system read only. Do not replay the transaction log. Report errors, but do not repair them.

--omit_journal_replay

Omit the replay of the transaction log. This option should not be used unless as a last resort (i.e. the log has been severely corrupted and replaying it causes further problems).

-p

Automatically repair ("preen") the file system. Replay the transaction log. Do not continue fsck processing unless the aggregate state is dirty or the log replay failed. Functionally equivalent to -a.

--replay_journal_only

Only replay the transaction log. Do not continue with a full file system check if the replay fails or if the file system is still dirty even after a journal replay. In general, this option should only be used for debugging purposes as it could leave the file system in an unmountable state. This option cannot be used with -f, -n, or --omit_journal_replay.

-v

Verbose messaging - print details and debug statements to stdout.

-V

Print version information and exit (regardless of any other chosen options).

## EXAMPLES
Check the 3rd partition on the 2nd hard disk, print extended information to stdout, replay the transaction log, force complete jfs_fsck checking, and give permission to repair all errors:

jfs_fsck -v -f /dev/hdb3

Check the 5th partition on the 1st hard disk, and report, but do not repair, any errors:

jfs_fsck -n /dev/hda5

## EXIT CODE
The exit code returned by jfs_fsck represents one of the following conditions:

0

No errors

1

File system errors corrected and/or transaction log replayed successfully

2

File system errors corrected, system should be rebooted if file system was mounted

4

File system errors left uncorrected

8

Operational error

16

Usage or syntax error

128

Shared library error

## REPORTING BUGS
If you find a bug in JFS or jfs_fsck, please report it via the bug tracking system ("Report Bugs" section) of the JFS project web site:

```
http://jfs.sourceforge.net/
```

Please send as much pertinent information as possible, including the complete output of running jfs_fsck with the -v option on the JFS device.

## SEE ALSO
fsck(8), jfs_mkfs(8), jfs_fscklog(8), jfs_tune(8), jfs_logdump(8), jfs_debugfs(8)

## AUTHORS

```
Barry Arndt  (barndt@us.ibm.com)
William Braswell, Jr.
```

jfs_fsck is maintained by IBM.

```
See the JFS project web site for more details:
http://jfs.sourceforge.net/
```


title: jfs_fscklog(8)

text:
# jfs_fscklog(8)

## NAME
jfs_fscklog - extract a JFS fsck service log into a file and/or format and display the extracted file

## SYNOPSIS
jfs_fscklog [ -d ] [ -e device ] [ -f output.file ] [ -p ] [ -V ]

## DESCRIPTION
jfs_fscklog with option -e device extracts the contents of either the most recent or immediately prior (specified with option -p) JFS fsck service log from the specified device, and writes the output to a file. The file name may be specified with the -f option, or the default file name is <pwd>fscklog.new. If the -p option is used, the default file name is <pwd>fscklog.old.

jfs_fscklog with option -d formats and displays the contents of the extracted file.

jfs_fscklog with options -d and -e device extracts and displays the JFS fsck service log.

## OPTIONS
-d

Format and display a previously extracted JFS fsck service log.

-e device

Extract the JFS fsck service log from device and store it in a file. (device is the special file name corresponding to the actual device from which the fsck log will be extracted (e.g. /dev/hdb1 )).

-f file.name

Specify the file name, overriding the default file name. When used with -e device, file.name specifies the name of the file into which the JFS fsck log will be extracted. When used with -d, file.name specifies the name of the extracted file whose contents will be formatted and displayed.

file.name must be 127 characters or less in length.

file.name will be created in the present working directory unless it is fully qualified.

-p

Extract the prior log (as opposed to the most recent log).

-V

Print version information and exit (regardless of any other chosen options).

## EXAMPLES

Extract the most recent JFS fsck log on /dev/hda5 into <pwd>fscklog.new:

jfs_fscklog -e /dev/hda5

Extract the most recent JFS fsck log on /dev/hdb3 into /temp/l9651107.log:

jfs_fscklog -e /dev/hdb3 -f /temp/l9651107.log

Display the JFS fsck log that was extracted into /temp/l9651107.log:

jfs_fscklog -d -f /temp/l9651107.log

Extract and display the previous JFS fsck log from /dev/hda8:

jfs_fscklog -e /dev/hda8 -d -p

## REPORTING BUGS
If you find a bug in JFS or jfs_fscklog, please report it via the bug tracking system ("Report Bugs" section) of the JFS project web site:

```
http://jfs.sourceforge.net/
```

Please send as much pertinent information as possible, including any jfs_fscklog error messages and the complete output of running jfs_fsck with the -v option on the JFS device.

## SEE ALSO
jfs_fsck(8), jfs_mkfs(8), jfs_tune(8), jfs_logdump(8), jfs_debugfs(8)

## AUTHOR

```
Barry Arndt  (barndt@us.ibm.com)
```

jfs_fscklog is maintained by IBM.

```
See the JFS project web site for more details:
http://jfs.sourceforge.net/
```


title: jfs_logdump(8)

text:
# jfs_logdump(8)

## NAME
jfs_logdump - dump a JFS formatted device's journal log

## SYNOPSIS
jfs_logdump [ -a ] device

## DESCRIPTION
jfs_logdump dumps the contents of the journal log from the specified JFS formatted device into output file ./jfslog.dmp.

device is the special file name corresponding to the actual device from which the journal log will be dumped (e.g. /dev/hdb1 ).

jfs_logdump must be run as root.

## OPTIONS
-a

Dump the entire contents of the journal log instead of just the committed transactions since the last synch point.

## EXAMPLE
Dump the entire JFS journal log from the 3rd partition of the 2nd hard disk into ./jfslog.dmp:

jfs_logdump -a /dev/hdb3

## REPORTING BUGS
If you find a bug in JFS or jfs_logdump, please report it via the bug tracking system ("Report Bugs" section) of the JFS project web site:

```
http://jfs.sourceforge.net/
```

Please send as much pertinent information as possible, including any jfs_logdump error messages and the complete output of running jfs_fsck with the -v option on the JFS device.

## SEE ALSO
jfs_fsck(8), jfs_mkfs(8), jfs_fscklog(8), jfs_tune(8), jfs_debugfs(8)

## AUTHORS

```
Barry Arndt  (barndt@us.ibm.com)
William Braswell, Jr.
```

jfs_logdump is maintained by IBM.

```
See the JFS project web site for more details:
http://jfs.sourceforge.net/
```


title: jfs_mkfs(8)

summary: create a JFS formatted partition

text:
# jfs_mkfs(8)

## NAME
jfs_mkfs - create a JFS formatted partition

## SYNOPSIS
jfs_mkfs [options] device [ blocks ]

## DESCRIPTION
jfs_mkfs is used to create (format) a JFS partition. jfs_mkfs must be run as root.

device is the special file name corresponding to the actual device (e.g. /dev/hdb1) on which a JFS file system and/or JFS journal will be created. blocks is the number of blocks to be used for the file system. If omitted, jfs_mkfs automatically figures the file system size.

The default block size is 4096.

## WARNING
jfs_mkfs will destroy all data on the specified device!

## OPTIONS
-c

Check the device for bad blocks before building the file system.

-j journal_device

Create the external JFS journal on journal_device , create the JFS file system on device , and attach the external journal to the file system.

-J journal-options

Create the JFS journal on its own device or attach an external JFS journal to the JFS file system using options specified on the command-line. The following journal options are supported:

journal_dev

Create an external JFS journal on the given device.

device=external-journal

Attach an existing external JFS journal located on external-journal to the JFS file system that will be created on device. The external journal must already have been created using the command

jfs_mkfs -J journal_dev external-journal

Attach the external journal to the file system being created by using the command

jfs_mkfs -J device=external-journal device

Instead of specifying a device name directly, external-journal can also be specified by either LABEL=label or UUID=UUID to locate the external journal by either the volume label or UUID stored in the JFS external log superblock at the start of the journal. Use jfs_tune(8) to display a journal device's volume label and UUID. (See the -l, -L, and -U options of jfs_tune(8).)

Only one of the journal_dev or device= options can be given per jfs_mkfs issuance.

-L volume_label

Set the volume label for the newly formatted device.

If -L volume_label is used along with -J journal_device, the volume label of the specified external journal device will be set to volume_label. Otherwise, the volume label of the JFS file system will be set to volume_label.

-O

Provide case-insensitive support for compatibility with OS/2.

-q

Quiet execution - do not ask for confirmation before creating the file system.

-s log_size

Set the log size (in megabytes) of the inline log. If the -s option is not used, the default log size is 0.4% of the aggregate size.

-V

Print version information and exit (regardless of any other chosen options).

## EXAMPLES
Format 3rd partition on 2nd hard disk with the volume label "JFS_hdb3":

jfs_mkfs -L JFS_hdb3 /dev/hdb3

Format 5th partition on 1st hard disk, verifying each block created:

jfs_mkfs -c /dev/hda5

Format 3rd partition on 2nd hard disk as external journal, format 4th partition on 1st hard disk as JFS file system, and attach the external journal to the file system:

jfs_mkfs -j /dev/hdb3 /dev/hda4

## REPORTING BUGS
If you find a bug in JFS or jfs_mkfs, please report it via the bug tracking system ("Report Bugs" section) of the JFS project web site:

```
http://jfs.sourceforge.net/
```

Please send as much pertinent information as possible including any error messages resulting from running jfs_mkfs.

## SEE ALSO
mkfs(8), jfs_fsck(8), jfs_fscklog(8), jfs_tune(8), jfs_logdump(8), jfs_debugfs(8)

## AUTHORS

```
Barry Arndt  (barndt@us.ibm.com)
William Braswell, Jr.
```

jfs_mkfs is maintained by IBM.

```
See the JFS project web site for more details:
http://jfs.sourceforge.net/
```


title: jfs_tune(8)

text:
# jfs_tune(8)

## NAME
jfs_tune - adjust tunable file system parameters on JFS

## SYNOPSIS
jfs_tune [options] device

## DESCRIPTION
jfs_tune adjusts tunable parameters on a Linux JFS file system or external journal. jfs_tune must be run as root.

device is the special file name corresponding to the actual device (e.g. /dev/hdb1) on which a JFS file system or JFS external journal has been created.

## OPTIONS
-J device=external-journal

Attach the JFS external journal located on external-journal to the JFS file system on device.

The external journal must already have been created using the command. More than one file system may share the same external journal.

mkfs.jfs -J journal_dev external-journal

Attach the external journal to the file system by using the command

jfs_tune -J device=external-journal device

Instead of specifying a device name directly, external-journal can also be specified by either LABEL=label or UUID=UUID (Use jfs_tune -l device to display a journal device's volume label and UUID.)

-l

List the contents of the JFS file system or external journal superblock that resides on device.

-L volume-label

Set the volume label of the JFS file system or external journal. JFS labels can be at most 16 characters long; if volume-label is longer than 16 characters, jfs_tune will truncate it and print a warning. The volume label can be used by mount(8), fsck(8), and /etc/fstab(5) (and possibly others) by specifying LABEL=volume_label instead of a block special device name like /dev/hda5.

-U UUID

Set the universally unique identifier (UUID) of the file system or external journal device to UUID. The format of the UUID is a series of hex digits separated by hyphens, like this: "c1b9d5a2-f162-11cf-9ece-0020afc76f16". The UUID parameter may also be one of the following:

clear

clear the file system UUID

random

generate a new randomly-generated UUID

time

generate a new time-based UUID

The UUID may be used by mount(8), fsck(8), and /etc/fstab(5) (and possibly others) by specifying UUID=uuid instead of a block special device name like /dev/hda1.

See uuidgen(8) for more information.

-V

Print version information and exit (regardless of any other chosen options).

## EXAMPLES
Set a randomly-generated UUID for the JFS file system on the 3rd partition of the 2nd hard disk, and view the resultant superblock:

jfs_tune -l -U random /dev/hdb3

Attach an already existing external journal on a device labeled JFSLog to a JFS file system on /dev/hda8:

jfs_tune -J device=LABEL=JFSLog /dev/hda8

## REPORTING BUGS
If you find a bug in JFS or jfs_tune, please report it via the bug tracking system ("Report Bugs" section) of the JFS project web site:

```
http://jfs.sourceforge.net/
```

Please send as much pertinent information as possible including any error messages resulting from running jfs_tune.

## SEE ALSO
jfs_fsck(8), jfs_mkfs(8), jfs_fscklog(8), jfs_logdump(8), jfs_debugfs(8)

## AUTHOR

```
Barry Arndt  (barndt@us.ibm.com)
```

jfs_tune is maintained by IBM.

```
See the JFS project web site for more details:
http://jfs.sourceforge.net/
```


jnettop

package: jnettop

title: jnettop(8)

text:
# jnettop(8)

## NAME
jnettop - View hosts/ports taking up the most network traffic

## SYNOPSIS
jnettop [options] [-i interface] [-d filename] [-f filename] [-x rule]

## DESCRIPTION
This manual page documents briefly the jnettop command. This manual page is OBSOLETE. Please use jnettop -h as a main source of information about usage.

jnettop captures traffic coming across the host it is running on and displays streams sorted by bandwidth they use. Result is a nice listing of communication on network by host and port, how many bytes went through this transport and the bandwidth it is consuming.

## OPTIONS
These programs follow the usual GNU command line syntax, with long options starting with two dashes (`-'). A summary of options is included below.

-h, --help

Show summary of options.

-v, --version

Show version of program.

-b, --bit-units

show BPS In bits per second, not bytes per second

-c, --content-filter

disable content filtering

-d, --debug filename

write debug information into file

-f, --config-file filename

reads configuration from filename. defaults to ~/.jnettop. an example can be found at /usr/share/doc/jnettop/dot.jnettop. or in .jnettop file from original distribution package.

-i, --interface name

capture packets on specified interface

--local-aggr [none|host|port]

set local aggregation to specified value

-n, --no-resolver

disable resolving of ip addresses

-p, --promiscuous

enables promiscuous mode on the sniffed interface

--remote-aggr [none|host|port]

set remote aggregation to specified value

-s, --select-rule name

selects one of the rules defined in .jnettop configuration file (by it's name)

-x, --filter rule

allows for specification of custom filtering rule. this allows for tcpdump(1) style syntax. don't forget to enclolse the filter into quotes when running from a shell.

## CONFIGURATION
Program looks for settings in the file specified by parameter -f, which defaults to ~/.jnettop. Configuration file is an ordinary text file with keywords and their arguments. You HAVE to enclose arguments into double quotes. Available keywords are:

interface "<interface_name>"

The interface keyword specifies network interface on which to start listening. Example:

interface "eth0"

local_aggregation [none|host|port]

The local_aggregation keyword specifies initial active local aggregation. Valid values are none, host and port. Example:

local_aggregation host

promisc [on|off]

The promisc keyword specifies, whether jnettop captures packets in promiscuous mode. Example:

promisc on

remote_aggregation [none|host|port]

The remote_aggregation keyword specifies initial active remote aggregation. Valid values are none, host and port. Example:

remote_aggregation port

resolve [on|off]

The resolve keyword specifies, whether resolving is performed on the IP addresses or not.

resolve off

resolve_rule "<network address>" "<network mask>" [normal|external] (<arguments> ...)

The resolve_rule keyword adds one resolver into list of resolvers for specified address. When resolving, jnettop examines all the rules in the order how they were specified in configuration file. If the network address matches specified range, declared resolver is used. Resolver can be normal, which means the standard DNS lookup or external, which executes specified external program to perform resolving. This can be used with bundled jnettop-lookup-nmb script, which looks up IP addresses using nmblookup(1) tool. If a tool returns empty string or DNS is not found, next rule is examined. If jnettop runs out of rules, than the standard DNS lookup is executed.

resolve_rule "192.168.0.0" "255.255.255.0" normal

resolve_rule "192.168.0.0" "255.255.255.0" external "/usr/share/jnettop/jnettop-lookup-nbm"

rule "<rule_name>" "<rule_definition>"

The rule keyword defines a set of predefined tcpdump(1)-like filters to apply. You can specify various filters as "show me what 192.168.1.32" sends:

rule "show 192.168.1.32" "src 192.168.1.32"

select_rule "<rule_name>"

The select_rule keyword specifies initial active predefined rule. The rule must be defined before this keyword is used. Example:

select_rule "show 192.168.1.32"

variable "<variable_name>" "<variable_contents>"

The variable keyword introduces a string variable for use in future rule definitions. It can be used to shorten rule definitions. Example:

variable "intranet" "net 192.168.0.0/16 or 10.0.0.0/8 or 172.16.0.0/12"

For more information, see README file or .jnettop example configuration file included in distribution.

## AUTHOR
This manual page was originally written by Ari Pollak <ari@debian.org>, for the Debian GNU/Linux system. Small changes were introduced by Jakub Skopal <j@kubs.cz>


clrunimap

package: kbd

title: clrunimap(8)

summary: Clear the current console unicode map

text:
# clrunimap(8)

## NAME
clrunimap - Clear the current console unicode map

## SYNOPSIS
clrunimap

## DESCRIPTION
The command clrunimap clears the unicode map (also called "Screen Font Map") for the current console.

## NOTES
If you are not the maintainer of the kbd package, it is very unlikely that you want to use this command. On many kernels the result will be that your screen is black. On some kernels a reboot will be necessary.

Use setfont -u to load a Unicode map for a console.

## SEE ALSO
setfont(8).


getkeycodes

title: getkeycodes(8)

text:
# getkeycodes(8)

## NAME
getkeycodes - print kernel scancode-to-keycode mapping table

## SYNOPSIS
getkeycodes

## DESCRIPTION
The getkeycodes command prints the kernel scancode-to-keycode mapping table.

## OPTIONS
None.

## SEE ALSO
setkeycodes(8)