vnstatd

package: vnstat-server

title: vnstatd(8)

text:
# vnstatd(8)

## NAME
vnstatd - daemon based database updating for vnStat

## SYNOPSIS
vnstatd [-Ddnpstv?] [--alwaysadd [mode]] [--config file] [--daemon] [--debug] [-g group] [--group group] [--help] [--initdb] [--noadd] [--nodaemon] [--noremove] [--pidfile file] [--startempty] [--sync] [--timestamp] [--u user] [--user user] [--version]

## DESCRIPTION
The purpose of vnstatd is to provide a flexible and robust way for gathering data to the database that vnstat(1) uses. The availability of each interface is automatically tracked which removes the need for additional scripts to be implemented and called when an interface comes online or goes offline.

vnstatd is the command for starting the daemon. The daemon can either fork itself to run as a background process or stay attached to the terminal. It supports logging directly to terminal, to a user selectable file or using syslog.

Once started, the daemon will read vnstat.conf(5) if available and then check if there is a database present in the database directory that has been specified in the configuration file. By default, if no database is found, a database will be created during startup with entries for all available interfaces excluding pseudo interfaces lo, lo0 and sit0. This automatic database entry creation behaviour can be disabled using the --noadd option. Alternatively, the --alwaysadd option can be used to instruct the daemon to create new database entries whenever interfaces not currently in the databases become visible. By default, unless the --startempty option is used, the daemon will not stay running if no interfaces are discovered during startup and the database contains no interfaces.

The daemon will proceed to track the availability of monitored interfaces, process the interface traffic statistics and write new values to the database at a configured interval. As a result, the daemon ends up spending most of the time sleeping between updates. New interfaces added to the database will be automatically picked up for monitoring without the daemon needing to be notified.

When the UseUTC configuration option isn't enabled, data is stored in the database using local time based on the daemon's execution environment when the configuration option isn't enabled. Any changes in the system clock or the system timezone configuration will result in data being inserted according to the new local time without any recalculation being done for already stored data. The daemon and the database in essence aren't aware of the used timezone or possible daylight saving time and cannot be configured to offset the timestamps to any direction. If a system clock or system timezone change or daylight saving time observation ending results in an already seen time period to repeat then the existing database values get incremented with the new data.

## OPTIONS
--alwaysadd [mode]

Enable automatic creation of new database entries for interfaces not currently in the database even if the database file already exists when the daemon is started. New database entries will also get created for new interfaces seen while the daemon is running. Pseudo interfaces lo, lo0 and sit0 are always excluded from getting added. Using the option without mode defined or with mode set to 1 will enable the feature. Setting mode to 0 will disable the feature. This command line option overrides the AlwaysAddNewInterfaces configuration option when used.

--config file

Use file as configuration file instead of using automatic configuration file search functionality.

-d, --daemon

Fork process to background and run as a daemon.

-D, --debug

Provide additional output for debug purposes. The process will stay attached to the terminal for output.

-g, --group group

Set daemon process group to group during startup. group can be either the name of the group or a numerical group id. This option can only be used when the process is started as root.

--initdb

Create a new database, import data from found legacy databases if --noadd option isn't used and exit without creating database entries for available interfaces if no legacy data was imported. If the database already exists then access to it is only verified. The daemon will not stay running when this option is used. This option cannot be used in combination with -d, --daemon, -n, --nodaemon or --startempty.

--noadd

When used in combination with -d, --daemon or -n, --nodaemon, disable the automatic creation of new database entries for all currently available interfaces when the daemon is started with no existing database or with a database containing zero interfaces. The daemon will still create an empty database if one doesn't already exist. Pseudo interfaces lo, lo0 and sit0 are always excluded from getting added regardless of this option.

When used in combination with --initdb, create only an empty database if one doesn't already exist without importing data from possible legacy databases and exit.

-n, --nodaemon

Stay in foreground attached to the current terminal and start the update process.

--noremove

Disable automatic removal of interfaces from database that aren't currently visible and haven't seen any traffic.

-p, --pidfile file

Write the process id to file and use it for locking so that another instance of the daemon cannot be started if the same file is specified. This option has no effect if used in combination with -n, --nodaemon.

--startempty

Start even when no interfaces were discovered and the database is empty. Results in the daemon staying running and waiting for interfaces to be added to the database or found if --alwaysadd option has also been used. This option cannot be used in combination with --initdb.

-s, --sync

Synchronize internal counters in the database with interface counters for all available interfaces before starting traffic monitoring. Use this option if the traffic between the previous shutdown and the current startup of the daemon needs to be ignored. This option isn't required in normal use because the daemon will automatically synchronize the internal counters after a system reboot, if enough time has passed since the daemon was previously running or if the internal counters are clearly out of sync.

-t, --timestamp

Add a timestamp to the beginning of every print from the daemon when the process is running in the foreground attached to a terminal after having been started with the -n, --nodaemon option.

-u, --user user

Set daemon process user to user during startup. user can be either the login of the user or a numerical user id. This option can only be used when the process is started as root.

-v, --version

Show current version of the daemon executable.

-?, --help

Show a command option summary.

## CONFIGURATION
The behaviour of the daemon is configured mainly using the configuration keywords UpdateInterval, PollInterval and SaveInterval in the configuration file.

UpdateInterval defines in seconds how often the interface data is fetched and updated. This is similar to the run interval for alternative cron based updating. However, the difference is that the data doesn't directly get written to disk during updates.

PollInterval defines in seconds how often the list of available interfaces is checked for possible changes. The minimum value is 2 seconds and the maximum 60 seconds. PollInterval also defines the resolution for other intervals.

SaveInterval defines in minutes how often cached interface data is written to disk. A write can only occur during the updating of interface data. Therefore, the value should be a multiple of UpdateInterval with a maximum value of 60 minutes.

The default values of UpdateInterval 30, SaveInterval 5 and PollInterval 5 are usually suitable for most systems and provide a similar behaviour as cron based updating does but with a better resolution for interface changes and fast interfaces.

For embedded and/or low power systems more tuned configurations are possible. In such cases if the interfaces are mostly static the PollInterval can be increased to around 10-30 seconds and UpdateInterval set to 60 seconds. Higher values up to 300 seconds are possible if the interface speed is 10 Mbit or less. SaveInterval can be increased for example to 15, 30 or even 60 minutes depending on how often the data needs to be viewed.

## SIGNALS
The daemon is listening to signals SIGHUP, SIGINT and SIGTERM. Sending the SIGHUP signal to the daemon will cause cached data to be written to disk, a rescan of the database directory and a reload of settings from the configuration file. However, the pid file location will not be changed even if it's configuration setting has been modified.

SIGTERM and SIGINT signals will cause the daemon to write all cached data to disk and then exit.

## FILES
/var/lib/vnstat/

Default database directory.

/etc/vnstat.conf

Config file that will be used unless $HOME/.vnstatrc exists. See the configuration chapter and vnstat.conf(5) for more information.

/var/log/vnstat/vnstat.log

Log file that will be used if logging to file is enable and no other file is specified in the config file.

/var/run/vnstat/vnstat.pid

File used for storing the process id when running as a background process and if no other file is specified in the configuration file or using the command line parameter.

## RESTRICTIONS
Updates need to be executed at least as often as it is possible for the interface to generate enough traffic to overflow the kernel interface traffic counter. Otherwise, it is possible that some traffic won't be seen. With 32-bit interface traffic counters, the maximum time between two updates depends on how fast the interface can transfer 4 GiB. Note that there is no guarantee that a 64-bit kernel has 64-bit interface traffic counters for all interfaces. Calculated theoretical times are:

10 Mbit: 54 minutes

100 Mbit: 5 minutes

1000 Mbit: 30 seconds

Virtual and aliased interfaces cannot be monitored because the kernel doesn't provide traffic information for that type of interfaces. Such interfaces are usually named eth0:0, eth0:1, eth0:2 etc. where eth0 is the actual interface being aliased.

## AUTHOR
Teemu Toivola <tst at iki dot fi>

## SEE ALSO
vnstat(1), vnstati(1), vnstat.conf(5), signal(7)


title: volume_key(8)

text:
# volume_key(8)

## NAME
volume_key - work with volume encryption secrets and escrow packets

## SYNOPIS
volume_key [OPTION]... OPERAND...

## DESCRIPTION
volume_key extracts "secrets" used for volume encryption (for example keys or passphrases) and stores them into separate encrypted "escrow packets", uses a previously created escrow packet to restore access to a volume (e.g. if the user forgets a passphrase), or manipulates the information in escrow packets.

The mode of operation and operands of volume_key are determined by specifying one of the --save, --restore, --setup-volume, --reencrypt, --dump or --secrets options. See the OPTIONS sections for details.

## OPTIONS
In all options described below, VOLUME is a LUKS device, not the plaintext device contained within:

blkid -s TYPE VOLUME

should report TYPE="crypto_LUKS". The following options determine the mode of operation and expected operands of volume_key:

--save

Expects operands VOLUME [PACKET]. Open VOLUME. If PACKET is provided, load the secrets from it. Otherwise, extract secrets from VOLUME, prompting the user if necessary. In any case, store secrets in one or more output packets.

--restore

Expects operands VOLUME PACKET. Open VOLUME and use the secrets in PACKET to make VOLUME accessible again, prompting the user if necessary (e.g. by letting the user enter a new passphrase).

--setup-volume

Expects operands VOLUME PACKET NAME. Open VOLUME and use the secrets in PACKET to set up VOLUME for use of the decrypted data as NAME. Currently NAME is a name of a dm-crypt volume, and this operation makes the decrypted volume available as /dev/mapper/NAME.

This operation should not permanently alter VOLUME (e.g. by adding a new passphrase); the user can of course access and modify the decrypted volume, modifying VOLUME in the process.

--reencrypt

Expects operand PACKET. Open PACKET, decrypting it if necessary, and store the information in one or more new output packets.

--dump

Expects operand PACKET. Open PACKET, decrypting it if necessary, and output the contents of PACKET. The secrets are not output by default.

--secrets

Expects operand PACKET. Open PACKET, decrypting it if necessary, and output secrets contained in PACKET.

--help

Show usage information.

--version

Show version of volume_key.

The following options alter the behavior of the specified operation:

-b, --batch

Run in batch mode. Read passwords and passphrases from standard input, each terminated by a NUL character. If a packet does not match a volume exactly, fail instead of prompting the user.

-d, --nss-dir DIR

Use private keys in NSS database in DIR to decrypt public key-encrypted packets.

-o, --output PACKET

Write the default secret to PACKET. Which secret is the default depends on volume format: it should not be likely to expire, and it should allow restoring access to the volume using --restore.

--output-data-encryption-key PACKET

Write the data encryption key (the key directly used to encrypt the actual volume data) to PACKET.

--output-passphrase PACKET

Write a passphrase that can be used to access the volume to PACKET.

--create-random-passphrase PACKET

Generate a random alphanumeric passphrase, add it to VOLUME (without affecting other passphrases) and store the random passphrase into PACKET.

-c, --certificate CERT

Load a certificate from the file specified by CERT and encrypt all output packets using the public key contained in the certificate. If this option is not specified, all output packets are encrypted using a passphrase. Note that CERT is a certificate file name, not a NSS certificate nickname.

--output-format FORMAT

Use FORMAT for all output packets. FORMAT can currently be one of asymmetric (use CMS to encrypt the whole packet, requires a certificate), asymmetric_wrap_secret_only (wrap only the secret, requires a certificate), passphrase (use GPG to encrypt the whole packet, requires a passphrase).

--unencrypted

Only dump the unencrypted parts of the packet, if any, with --dump. Do not require any passphrase or private key access.

--with-secrets

Include secrets in the output of --dump

## EXIT STATUS
volume_key returns with exit status 0 on success, 1 on error.

## NOTES
The only currently supported volume format is LUKS.

## EXAMPLE
Typical usage of volume_key proceeds as follows. During system installation or soon after, back up the default secret of a volume, and add a system-specific random passphrase. Encrypt both using a certificate:

volume_key --save VOLUME -c CERT -o PACKET_DEFAULT --create-random-passphrase PACKET_PASSPHRASE

Store PACKET_DEFAULT and PACKET_PASSPHRASE outside of the computer. If the user forgets a passphrase, and you can access the computer, decrypt PACKET_DEFAULT using the certificate private key (which should never leave a secure machine):

volume_key --reencrypt -d NSS_DB PACKET_DEFAULT -o PACKET_DEFAULT_PW

Then boot the computer (e.g. using a "rescue mode"), copy PACKET_DEFAULT_PW to it, and restore access to the volume: volume_key --restore VOLUME PACKET_DEFAULT_PW

If the user forgets the passphrase, and you cannot access the computer, decrypt the backup passphrase:

volume_key --secrets PACKET_PASSPHRASE

and tell the backup passphrase to the user. (You can later generate a new backup passphrase.)


vpnc

package: vpnc

title: vpnc(8)

text:
# vpnc(8)

## NAME
vpnc - client for Cisco VPN3000 Concentrator, IOS and PIX

## SYNOPSIS
vpnc [--version] [--print-config] [--help] [--long-help] [options] [config files]

## DESCRIPTION
This manual page documents briefly the vpnc and vpnc-disconnect commands.

vpnc is a VPN client for the Cisco 3000 VPN Concentrator, creating a IPSec-like connection as a tunneling network device for the local system. It uses the TUN/TAP driver in Linux kernel 2.4 and above and device tun(4) on BSD. The created connection is presented as a tunneling network device to the local system.

OBLIGATORY WARNING: the most used configuration (XAUTH authentication with pre-shared keys and password authentication) is insecure by design, be aware of this fact when you use vpnc to exchange sensitive data like passwords!

The vpnc daemon by itself does not set any routes, but it calls vpnc-script to do this job. vpnc-script displays a connect banner. If the concentrator supplies a network list for split-tunneling these networks are added to the routing table. Otherwise the default-route will be modified to point to the tunnel. Further a host route to the concentrator is added in the later case. If the client host needs DHCP, care must be taken to add another host route to the DHCP-Server around the tunnel.

The vpnc-disconnect command is used to terminate the connection previously created by vpnc and restore the previous routing configuration.

## CONFIGURATION
The daemon reads configuration data from the following places:

- command line options

- config file(s) specified on the command line

- /etc/vpnc/default.conf

- /etc/vpnc.conf

- prompting the user if not found above

vpnc can parse options and configuration files in any order. However the first place to set an option wins. configuration filenames which do not contain a / will be searched at /etc/vpnc/<filename> and /etc/vpnc/<filename>.conf. Otherwise <filename> and <filename>.conf will be used. If no configuration file is specified on the command-line at all, both /etc/vpnc/default.conf and /etc/vpnc.conf will be loaded.

Additionally, if the configuration file "-" is specified on the command-line vpnc will read configuration from stdin. The configuration is parsed and the connection proceeds when stdin is closed or the special character CEOT (CTRL-D) is read.

## OPTIONS
The program options can be either given as arguments (but not all of them for security reasons) or be stored in a configuration file.

--gateway <ip/hostname>

IP/name of your IPSec gateway

conf-variable: IPSec gateway <ip/hostname>

--id <ASCII string>

your group name

conf-variable: IPSec ID <ASCII string>

--id-type <ipv4/fqdn/user/key/#>

IKE Phase 1 Identification type

Default: 0

conf-variable: IPSec IDType <ipv4/fqdn/user/key/#>

(configfile only option)

your group password (cleartext)

conf-variable: IPSec secret <ASCII string>

(configfile only option)

your group password (obfuscated)

conf-variable: IPSec obfuscated secret <hex string>

--username <ASCII string>

your username

conf-variable: Xauth username <ASCII string>

(configfile only option)

your password (cleartext)

conf-variable: Xauth password <ASCII string>

(configfile only option)

your password (obfuscated)

conf-variable: Xauth obfuscated password <hex string>

--domain <ASCII string>

(NT-) Domain name for authentication

conf-variable: Domain <ASCII string>

--xauth-inter

enable interactive extended authentication (for challenge response auth)

conf-variable: Xauth interactive

--vendor <cisco/juniper/netscreen>

vendor of your IPSec gateway

Default: cisco

conf-variable: Vendor <cisco/juniper/netscreen>

--natt-mode <natt/none/force-natt/cisco-udp>

Which NAT-Traversal Method to use:

- natt -- NAT-T as defined in RFC3947

- none -- disable use of any NAT-T method

- force-natt -- always use NAT-T encapsulation even without presence of a NAT device (useful if the OS captures all ESP traffic)

- cisco-udp -- Cisco proprietary UDP encapsulation, commonly over Port 10000

Note: cisco-tcp encapsulation is not yet supported

Default: natt

conf-variable: NAT Traversal Mode <natt/none/force-natt/cisco-udp>

--script <command>

command is executed using system() to configure the interface, routing and so on. Device name, IP, etc. are passed using environment variables, see README. This script is executed right after ISAKMP is done, but before tunneling is enabled. It is called when vpnc terminates, too

Default: /etc/vpnc/vpnc-script

conf-variable: Script <command>

--dh <dh1/dh2/dh5>

name of the IKE DH Group

Default: dh2

conf-variable: IKE DH Group <dh1/dh2/dh5>

--pfs <nopfs/dh1/dh2/dh5/server>

Diffie-Hellman group to use for PFS

Default: server

conf-variable: Perfect Forward Secrecy <nopfs/dh1/dh2/dh5/server>

--enable-1des

enables weak single DES encryption

conf-variable: Enable Single DES

--enable-no-encryption

enables using no encryption for data traffic (key exchanged must be encrypted)

conf-variable: Enable no encryption

--application-version <ASCII string>

Application Version to report. Note: Default string is generated at runtime.

Default: Cisco Systems VPN Client 0.5.4:Linux

conf-variable: Application version <ASCII string>

--ifname <ASCII string>

visible name of the TUN/TAP interface

conf-variable: Interface name <ASCII string>

--ifmode <tun/tap>

mode of TUN/TAP interface:

- tun: virtual point to point interface (default)

- tap: virtual ethernet interface

Default: tun

conf-variable: Interface mode <tun/tap>

--ifmtu <0-65535>

Set MTU for TUN/TAP interface (default 0 == automatic detect)

conf-variable: Interface MTU <0-65535>

--debug <0/1/2/3/99>

Show verbose debug messages

-

0: Do not print debug information.

-

1: Print minimal debug information.

-

2: Show statemachine and packet/payload type information.

-

3: Dump everything exluding authentication data.

- 99: Dump everything INCLUDING AUTHENTICATION data (e.g. PASSWORDS).

conf-variable: Debug <0/1/2/3/99>

--no-detach

Don't detach from the console after login

conf-variable: No Detach

--pid-file <filename>

store the pid of background process in <filename>

Default: /var/run/vpnc.pid

conf-variable: Pidfile <filename>

--local-addr <ip/hostname>

local IP to use for ISAKMP / ESP / ... (0.0.0.0 == automatically assign)

Default: 0.0.0.0

conf-variable: Local Addr <ip/hostname>

--local-port <0-65535>

local ISAKMP port number to use (0 == use random port)

Default: 500

conf-variable: Local Port <0-65535>

--udp-port <0-65535>

Local UDP port number to use (0 == use random port). This is only relevant if cisco-udp nat-traversal is used. This is the _local_ port, the remote udp port is discovered automatically. It is especially not the cisco-tcp port.

Default: 10000

conf-variable: Cisco UDP Encapsulation Port <0-65535>

--dpd-idle <0,10-86400>

Send DPD packet after not receiving anything for <idle> seconds. Use 0 to disable DPD completely (both ways).

Default: 600

conf-variable: DPD idle timeout (our side) <0,10-86400>

--non-inter

Don't ask anything, exit on missing options

conf-variable: Noninteractive

--auth-mode <psk/cert/hybrid>

Authentication mode:

- psk: pre-shared key (default)

- cert: server + client certificate (not implemented yet)

- hybrid: server certificate + xauth (if built with openssl support)

Default: psk

conf-variable: IKE Authmode <psk/cert/hybrid>

--ca-file <filename>

filename and path to the CA-PEM-File

conf-variable: CA-File <filename>

--ca-dir <directory>

path of the trusted CA-Directory

Default: /etc/ssl/certs

conf-variable: CA-Dir <directory>

--target-network <target network/netmask>

Target network in dotted decimal or CIDR notation

Default: 0.0.0.0/0.0.0.0

conf-variable: IPSEC target network <target network/netmask>

--password-helper <executable>

path to password program or helper name

conf-variable: Password helper <executable>

--print-config

Prints your configuration; output can be used as vpnc.conf

## FILES
/etc/vpnc.conf /etc/vpnc/default.conf

The default configuration file. You can specify the same config directives as with command line options and additionally IPSec secret and Xauth password both supplying a cleartext password. Scrambled passwords from the Cisco configuration profiles can be used with IPSec obfuscated secret and Xauth obfuscated password. See EXAMPLES for further details.

/etc/vpnc/*.conf

vpnc will read configuration files in this directory when the config filename (with or without .conf) is specified on the command line.

## EXAMPLES
This is an example vpnc.conf with pre-shared keys:

IPSec gateway vpn.example.com IPSec ID ExampleVpnPSK

IKE Authmode psk

IPSec secret PskS3cret!

Xauth username user@example.com

Xauth password USecr3t

And another one with hybrid authentication (requires that vpnc was built with openssl support):

IPSec gateway vpn.example.com IPSec ID ExampleVpnHybrid

IKE Authmode hybrid

CA-Dir /etc/vpnc

or

CA-File /etc/vpnc/vpn-example-com.pem

IPSec secret HybS3cret?

Xauth username user@example.com

Xauth password 123456

The lines begin with a keyword (no leading spaces!). The values start exactly one space after the keywords, and run to the end of line. This lets you put any kind of weird character (except CR, LF and NUL) in your strings, but it does mean you can't add comments after a string, or spaces before them.

In case the the CA-Dir option is used, your certificate needs to be named something like 722d15bd.X, where X is a manually assigned number to make sure that files with colliding hashes have different names. The number can be derived from the certificate file itself:

openssl x509 -subject_hash -noout -in /etc/vpnc/vpn-example-com.pem

See also the --print-config option to generate a config file, and the example file in the package documentation directory where more advanced usage is demonstrated.

Advanced features like manual setting of multiple target routes and disabling /etc/resolv.conf rewriting is documented in the README of the vpnc package.

## AUTHOR
This man-page has been written by Eduard Bloch <blade(at)debian.org> and Christian Lackas <delta(at)lackas.net>, based on vpnc README by Maurice Massar <vpnc(at)unix-ag.uni-kl.de>. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2 any later version published by the Free Software Foundation.

On Debian systems, the complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL.

## SEE ALSO
pcf2vpnc(1), cisco-decrypt(1), ip(8), ifconfig(8), route(1), http://www.unix-ag.uni-kl.de/~massar/vpnc/


vrrpd

package: vrrpd

title: vrrpd(8)

text:
# vrrpd(8)

## NAME
vrrpd - Virtual Router Redundancy Protocol Deamon

## SYNOPSIS
vrrpd -i ifname -v vrid [-f piddir] [-s] [-a auth] [-p prio] [-m ifname] [-c delta] [-nhD] ipaddr

## DESCRIPTION
vrrpd is an implementation of VRRPv2 as specified in rfc2338. It run in userspace for linux. In short, VRRP is a protocol which elects a master server on a LAN and the master answers to a 'virtual ip address'. If it fails, a backup server takes over the ip address.

A longer answer in the rfc2338 abstract : "This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host." Copyright (C) The Internet Society (1998). All Rights Reserved.

Monitored interface functionality is useful on high availability router or firewall platforms, where single interface failure can cause asymmetrical routing issues.

Ideally, what is required is a method for a vrrpd process to detect a failure of the 'other' network interface, and lower it's own VRRP priority below that of the 'backup' vrrpd process. This allows failover to occur normally.

### OPTIONS
-h

display this short inlined help

-n

Don't handle the virtual mac address

-D

Go into background mode, daemonize

-i ifname

the interface name to run on. More than one interface can be monitored by the one vrrpd process, a list like "eth1 eth2 eth3 eth4 eth5" is acceptable. Losing link-beat on any of these will cause the priority of that vrrpd process to be decreased by the specified value, or a default of 100. Note that as MII calls are used, this implementation is limited to Fast and Gigabit Ethernet chipsets only - 10Mbps Ethernet cards will not work.

-v vrid

the id of the virtual server [1-255]

-s

iqxSwitch the preemption mode (Enabled by default)

-a auth

set the authentification type auth=(none|pw/hexkey|ah/hexkey) hexkey=0x[0-9a-fA-F]+ Password is a symbolic security, anybody with a sniffer can break it. AH is a bit stronger.

-p prio

Set the priority of this host in the virtual server (dfl: 100)

-f piddir

specify the directory where the pid file is stored (dfl: /var/run)

-d delay

Set the advertisement interval (in sec) (dfl: 1) -m ifname Interface(s) to monitor for failure. Use " " for multiple interfaces

-c delta

Set the delta to decrease priority by (dfl: 50)

ipaddr

the ip address(es) of the virtual server

## EXAMPLES
vrrpd -i eth0 -v 50 10.0.0.1

run vrrp on the interface eth0 with the virtual id 50 and 10.0.0.1 as virtual ip address

## AUTHOR
vrrpd was written by Jerome Etienne <jetienne@arobas.net>, it was later improved by Alexandre Cassert <acassen@linux-vs.org> and David Hunter <david.hunter@gen-i.co.nz>

## BUGS
Suggestions, bugs or questions should be directed to the Sourceforge project at http://sourceforge.net/projects/vrrpd/

Bug reports regarding this package should be submitted to Debian using the reportbug or bug tool.

## MORE INFO
For more information please read the documents under /usr/share/doc/vrrpd/ : README, README.Debian FAQ and TODO.


vsftpd

package: vsftpd

title: vsftpd(8)

summary: Very Secure FTP Daemon

text:
# vsftpd(8)

## NAME
vsftpd — Very Secure FTP Daemon

## SYNOPSIS
vsftpd

[configuration file and / or options]

## DESCRIPTION
vsftpd is the Very Secure File Transfer Protocol Daemon. The server can be launched via a “super-server” such as inetd(8) or xinetd(8). Alternatively, vsftpd can be launched in standalone mode, in which case vsftpd itself will listen on the network. This latter mode is easier to use, and recommended. It is activated by setting listen=YES in /etc/vsftpd.conf. Direct execution of the vsftpd binary will then launch the FTP service ready for immediate client connections.

## OPTIONS
An optional configuration file or files may be given on the command line. These files must be owned as root if running as root. Any command line option not starting with a "-" character is treated as a config file that will be loaded. Note that config files are loaded in the strict order that they are encountered on the command line. If no config files are specified, the default configuration file of /etc/vsftpd.conf will be loaded, after all other command line options are processed.

Supported options are:

-v

Print the version information and exit, even if other options are encountered.

-ooption=value

Set a single option, value pair as per the format in the config file. Multiple -o options are supported, and they are applied in strict order relative to their appearance on the command line, including intermingling with loading of config files.

## EXAMPLES
vsftpd -olisten=NO /etc/vsftpd.conf -oftpd_banner=blah

That example overrides vsftpd's built-in default for the "listen" option to be NO, but then loads /etc/vsftpd.conf which may override that setting. Finally, the "ftpd_banner" setting is set to "blah", which overrides any default vsftpd setting and any identical setting that was in the config file.

## FILES
/etc/vsftpd.conf

## SEE ALSO
vsftpd.conf(5)


wakefix

package: wakefix

title: wakefix(8)

text:
# wakefix(8)

## NAME
wakefix - is a tool to read and modify (fix) the ACPI wakeup event table (/proc/acpi/wakeup). It is intended to be installed as a system startup service to make such modifications at boot.

## SYNOPSIS
wakefix [options]

## DESCRIPTION
wakefix is a tool to read and modify (fix) the ACPI wakeup event table (/proc/acpi/wakeup). It is intended to be installed as a system startup service to make such modifications at boot.

wakefix uses /etc/sysconfig/wakefix.conf configuration file.

## OPTIONS
-l, --list

print out the contents of the kernel ACPI wakeup table (the default action);

-e NAMEs, --enable=NAMEs

enable wakeup by events from devices which name contains one of the listed NAMEs;

-d NAMEs, --disable=NAMEs disable wakeup by events from devices

which name contains one of the listed NAMEs;

-f, --fix

make modifications in accordance with the configuration file /etc/sysconfig/wakefix.conf;

-n,--dry-run

just print out which devices would be enabled or disabled without actual state changes;

-v,--verbose

print information about the actual changes;

-V,--version

print program version and exit;

-h,--help

show this text and exit.

With no options given wakefix prints out the contents of the kernel ACPI wakeup table (as with -l).

## ENVIRONMENT
WAKEFIX_CONFIG

If the WAKEFIX_CONFIG environment variable is set then it specifies a path to the configuration file instead of the default /etc/sysconfig/wakefix.conf.

## AUTHOR
Written by Paul Wolneykien <manowar@altlinux.org>

## REPORTING BUGS
Report bugs to http://bugs.altlinux.ru/

## COPYRIGHT
Copyright © 2019 Paul Wolneykien <manowar@altlinux.org>

This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

## SEE ALSO
acpi(1).


watchdog

package: watchdog

title: watchdog(8)

summary: a software watchdog daemon

text:
# watchdog(8)

## NAME
watchdog - a software watchdog daemon

## SYNOPSIS
watchdog [-F|--foreground] [-f|--force] [-c filename|--config-file filename] [-v|--verbose] [-s|--sync] [-b|--softboot] [-q|--no-action]

## DESCRIPTION
The Linux kernel can reset the system if serious problems are detected. This can be implemented via special watchdog hardware, or via a slightly less reliable software-only watchdog inside the kernel. Either way, there needs to be a daemon that tells the kernel the system is working fine. If the daemon stops doing that, the system is reset.

watchdog is such a daemon. It opens /dev/watchdog, and keeps writing to it often enough to keep the kernel from resetting, at least once per minute. Each write delays the reboot time another minute. After a minute of inactivity the watchdog hardware will cause the reset. In the case of the software watchdog the ability to reboot will depend on the state of the machines and interrupts.

The watchdog daemon can be stopped without causing a reboot if the device /dev/watchdog is closed correctly, unless your kernel is compiled with the CONFIG_WATCHDOG_NOWAYOUT option enabled.

## TESTS
The watchdog daemon does several tests to check the system status:

- Is the process table full?

- Is there enough free memory?

- Is there enough allocatable memory?

- Are some files accessible?

- Have some files changed within a given interval?

- Is the average work load too high?

- Has a file table overflow occurred?

- Is a process still running? The process is specified by a pid file.

- Do some IP addresses answer to ping?

- Do network interfaces receive traffic?

- Is the temperature too high? (Temperature data not always available.)

- Execute a user defined command to do arbitrary tests.

- Execute one or more test/repair commands found in /etc/watchdog.d. These commands are called with the argument test or repair.

If any of these checks fail watchdog will cause a shutdown. Should any of these tests except the user defined binary last longer than one minute the machine will be rebooted, too.

## OPTIONS
Available command line options are the following:

-v, --verbose

Set verbose mode. Only implemented if compiled with SYSLOG feature. This mode will log each several infos in LOG_DAEMON with priority LOG_DEBUG. This is useful if you want to see exactly what happened until the watchdog rebooted the system. Currently it logs the temperature (if available), the load average, the change date of the files it checks and how often it went to sleep. You can use this twice to enable some more verbose debug message for testing.

-s, --sync

Try to synchronize the filesystem every time the process is awake. Note that the system is rebooted if for any reason the synchronizing lasts longer than a minute.

-b, --softboot

Soft-boot the system if an error occurs during the main loop, e.g. if a given file is not accessible via the stat(2) call. Note that this does not apply to the opening of /dev/watchdog and /proc/loadavg, which are opened before the main loop starts. Now this is implemented by disabling the error re-try timer.

-F, --foreground

Run in foreground mode, useful for running under systemd (for example).

-f, --force

Force the usage of the interval given or the maximal load average given in the config file. Without this option these values are sanity checked.

-c config-file, --config-file config-file

Use config-file as the configuration file instead of the default /etc/watchdog.conf.

-q, --no-action

Do not reboot or halt the machine. This is for testing purposes. All checks are executed and the results are logged as usual, but no action is taken. Also your hardware card or the kernel software watchdog driver is not enabled. NOTE: This still allows 'repair' actions to run, but the daemon itself will not attempt a reboot.

-X num, --loop-exit num

Run for 'num' loops then exit as if SIGTERM was received. Intended for test/debug (e.g. using valgrind for checking memory access). If the daemon exits on a loop counter and you have the CONFIG_WATCHDOG_NOWAYOUT option compiled for the kernel or device-driver then an unplanned reboot will follow - be warned!

## FUNCTION
After watchdog starts, it puts itself into the background and then tries all checks specified in its configuration file in turn. Between each two tests it will write to the kernel device to prevent a reset. After finishing all tests watchdog goes to sleep for some time. The kernel drivers expects a write to the watchdog device every minute. Otherwise the system will be reset. watchdog will sleep for a configure interval that defaults to 1 second to make sure it triggers the device early enough.

Under high system load watchdog might be swapped out of memory and may fail to make it back in in time. Under these circumstances the Linux kernel will reset the machine. To make sure you won't get unnecessary reboots make sure you have the variable realtime set to yes in the configuration file watchdog.conf. This adds real time support to watchdog: it will lock itself into memory and there should be no problem even under the highest of loads.

On system running out of memory the kernel will try to free enough memory by killing process. The watchdog daemon itself is exempted from this so-called out-of-memory killer.

Also you can specify a maximal allowed load average. Once this load average is reached the system is rebooted. You may specify maximal load averages for 1 minute, 5 minutes or 15 minutes. The default values is to disable this test. Be careful not to set this parameter too low. To set a value less then the predefined minimal value of 2, you have to use the -f option.

You can also specify a minimal amount of virtual memory you want to have available as free. As soon as more virtual memory is used action is taken by watchdog. Note, however, that watchdog does not distinguish between different types of memory usage. It just checks for free virtual memory.

If you have a machine with temperature sensor(s) you can specify the maximal allowed temperature. Once this temperature is reached on any sensor the system is powered off. The default value is 90 C. Typically the temperature information is provided by the sensors package as files in the virtual filesystem /sys/device and can be found using, for example, the command

find /sys -name 'temp*input' -print

These files hold the temperature in milli-Celsius. You can have multiple sensors used in the config file. For example to change to 75C maximum and to check two virtual files for the system temperature you might have this:

max-temperature = 75

temperature-sensor = /sys/class/hwmon/hwmon0/device/temp1_input

temperature-sensor = /sys/class/hwmon/hwmon0/device/temp2_input

The watchdog will issue warnings once the temperature increases 90%, 95% and 98% of the configured maximum temperature.

When using file mode watchdog will try to stat(2) the given files. Errors returned by stat will not cause a reboot. For a reboot the stat call has to last at least the re-try time-out value (default 1 minute). This may happen if the file is located on an NFS mounted filesystem. If your system relies on an NFS mounted filesystem you might try this option. However, in such a case the sync option may not work if the NFS server is not answering.

watchdog can read the pid from a pid file and see whether the process still exists. If not, action is taken by watchdog. So you can for instance restart the server from your repair-binary.

watchdog will try periodically to fork itself to see whether the process table is full. This process will leave a zombie process until watchdog wakes up again and catches it; this is harmless, don't worry about it.

In ping mode watchdog tries to ping the given IPv4 addresses. These addresses do not have to be a single machine. It is possible to ping to a broadcast address instead to see if at least one machine in a subnet is still living.

Do not use this broadcast ping unless your MIS person a) knows about it and b) has given you explicit permission to use it!

watchdog will send out three ping packages and wait up to <interval> seconds for the reply with <interval> being the time it goes to sleep between two times triggering the watchdog device. Thus a unreachable network will not cause a hard reset but a soft reboot.

You can also test passively for an unreachable network by just monitoring a given interface for traffic. If no traffic arrives the network is considered unreachable causing a soft reboot or action from the repair binary.

watchdog can run an external command for user-defined tests. A return code not equal 0 means an error occurred and watchdog should react. If the external command is killed by an uncaught signal this is considered an error by watchdog too. The command may take longer than the time slice defined for the kernel device without a problem. However, error messages are generated into the syslog facility. If you have enabled softboot on error the machine will be rebooted if the binary doesn't exit in half the time watchdog sleeps between two tries triggering the kernel device.

If you specify a repair binary it will be started instead of shutting down the system. If this binary is not able to fix the problem watchdog will still cause a reboot afterwards.

If the machine is halted an email is sent to notify a human that the machine is going down. Starting with version 4.4 watchdog will also notify the human in charge if the machine is rebooted.

The re-try timer applies to most errors, except reset/reboot calls and too hot. It allows a given error source to recover, and treats most tests in this way. Exceptions are file handle test, load averages, and system memory. If set to the minimum time of 1 second it will still allow a single re-try at any polling interval of the system.

## SOFT REBOOT
A soft reboot (i.e. controlled shutdown and reboot) is initiated for every error that is found. Since there might be no more processes available, watchdog does it all by himself. That means:

1.

Kill all processes with SIGTERM.

2.

After a short pause kill all remaining processes with SIGKILL.

3.

Record a shutdown entry in wtmp.

4.

Save the random seed from /dev/urandom. If the device is non-existant or there is no filename for saving this step is skipped.

5.

Turn off accounting.

6.

Turn off quota and swap.

7.

Unmount all partitions

8.

Finally reboot.

## CHECK BINARY
If the return code of the check binary is not zero watchdog will assume an error and reboot the system. Be careful with this if you are using the real-time properties of watchdog since watchdog will wait for the return of this binary before proceeding. An exit code smaller than 245 is interpreted as an system error code (see errno.h for details). Values of 245 or larger than are special to watchdog:

255

(based on -1 as unsigned 8-bit number) Reboot the system. This is not exactly an error message but a command to watchdog. If the return code is this the watchdog will not try to run a shutdown script instead.

254

Reset the system. This is not exactly an error message but a command to watchdog. If the return code is this the watchdog will attempt to hard-reset the machine without attempting any sort of orderly stopping of process, unmounting of file systems, etc.

253

Maximum load average exceeded.

252

The temperature inside is too high.

251

/proc/loadavg contains no (or not enough) data.

250

The given file was not changed in the given interval.

249

/proc/meminfo contains invalid data.

248

Child process was killed by a signal.

247

Child process did not return in time.

246

Free for personal watchdog-specific use (was -10 as an unsigned 8-bit number).

245

Reserved for an unknown result, for example a slow background test that is still running so neither a success nor an error.

## REPAIR BINARY
The repair binary is started with one parameter: the error number that caused watchdog to initiate the boot process. After trying to repair the system the binary should exit with 0 if the system was successfully repaired and thus there is no need to boot anymore. A return value not equal 0 tells watchdog to reboot. The return code of the repair binary should be the error number of the error causing watchdog to reboot. Be careful with this if you are using the real-time properties since watchdog will wait for the return of this binary before proceeding.

The configuration file parameter repair-maximum controls the number of successive repair attempts that report 0 (i.e. success) but fail to clear the tested fault. If this is exceeded then a reboot takes place. If set to zero then a reboot can always be blocked by the repair program reporting success.

## TEST DIRECTORY
Executables placed in the test directory are discovered by watchdog on startup and are automatically executed. They are bounded time-wise by the test-timeout directive in watchdog.conf.

These executables are called with either "test" as the first argument (if a test is being performed) or "repair" as the first argument (if a repair for a previously-failed "test" operation on is being performed).

As with test binaries and repair binaries, expected exit codes for a successful test or repair operation is always zero.

If an executable's test operation fails, the same executable is automatically called with the "repair" argument as well as the return code of the previously-failed test operation.

For example, if the following execution returns 42:

/etc/watchdog.d/my-test test

The watchdog daemon will attempt to repair the problem by calling:

/etc/watchdog.d/my-test repair 42

This enables administrators and application developers to make intelligent test/repair commands. If the "repair" operation is not required (or is not likely to succeed), it is important that the author of the command return a non-zero value so the machine will still reboot as expected.

Note that the watchdog daemon may interpret and act upon any of the reserved return codes noted in the Check Binary section prior to calling a given command in "repair" mode.

As for the repair binary, the configuration parameter repair-maximum also controls the number of successive repair attempts that report success (return 0) but fail to clear the fault.

## BUGS
None known so far.

## AUTHORS
The original code is an example written by Alan Cox <alan@lxorguk.ukuu.org.uk>, the author of the kernel driver. All additions were written by Michael Meskes <meskes@debian.org>. Johnie Ingram <johnie@netgod.net> had the idea of testing the load average. He also took over the Debian specific work. Dave Cinege <dcinege@psychosis.com> brought up some hardware watchdog issues and helped testing this stuff.

## FILES
/dev/watchdog

The watchdog device.

/var/run/watchdog.pid

The pid file of the running watchdog.

## SEE ALSO
watchdog.conf(5)


title: wd_identify(8)

summary: get watchdog driver identity

text:
# wd_identify(8)

## NAME
wd_identify - get watchdog driver identity

## SYNOPSIS
wd_identify [-c filename|--config-file filename] [-v|--verbose]

## DESCRIPTION
This utility opens /dev/watchdog and gets the identification string from the watchdog which then is printed. The device is closed afterwards.

An exit code of zero indicates success in getting the driver identity, while a non-zero exit code indicates an error (not configured in the config file, no device driver loaded, or driver failed to respond to ioctl request).

The wd_identify tool can only be used without causing a reboot if your kernel is not compiled with the CONFIG_WATCHDOG_NOWAYOUT option enabled.

Note that the watchdog and/or wd_keepalive daemons may have to be stopped to make sure that wd_identify can access the watchdog device.

## OPTIONS
Available command line options are the following:

-c config-file, --config-file config-file

Use config-file as the configuration file instead of the default /etc/watchdog.conf.

-v, --verbose

Print more diagnostic messages. This covers parsing of the config file and also causes the program to read-back the current watchdog time-out value (if successful in opening the device).

## FILES
/dev/watchdog

The watchdog device.

## SEE ALSO
watchdog.conf(5)

watchdog(8)


title: wd_keepalive(8)

summary: a simplified software watchdog daemon

text:
# wd_keepalive(8)

## NAME
wd_keepalive - a simplified software watchdog daemon

## SYNOPSIS
wd_keepalive [-c filename|--config-file filename]

## DESCRIPTION
This is a simplified version of the watchdog daemon. Unlike the full watchdog, this daemon run no tests and only serves to keep the hardware timer refreshed. Typically this is used on system start-up to provide protection before the services that the full version tests are running, and on shutdown to continue the refresh while those services are stopped.

If configured so it only opens /dev/watchdog, and keeps writing to it often enough to keep the kernel from resetting, at least once per minute. Each write delays the reboot time another minute. After a minute of inactivity the watchdog hardware will cause a reset. In the case of the software watchdog the ability to reboot will depend on the state of the machines and interrupts.

The wd_keepalive daemon can be stopped without causing a reboot if the device /dev/watchdog is closed correctly, unless your kernel is compiled with the CONFIG_WATCHDOG_NOWAYOUT option enabled.

Under high system load wd_keepalive might be swapped out of memory and may fail to make it back in in time. Under these circumstances the Linux kernel will reset the machine. To make sure you won't get unnecessary reboots make sure you have the variable realtime set to yes in the configuration file watchdog.conf. This adds real time support to wd_keepalive: it will lock itself into memory and there should be no problem even under the highest of loads.

On system running out of memory the kernel will try to free enough memory by killing process. The wd_keepalive daemon itself is exempted from this so-called out-of-memory killer.

## OPTIONS
Available command line options are the following:

-c config-file, --config-file config-file

Use config-file as the configuration file instead of the default /etc/watchdog.conf.

-X num, --loop-exit num

Run for 'num' loops then exit as if SIG_TERM was received. Intended for test/debug (e.g. using valgrind for checking memory access). If the daemon exits on a loop counter and you have the CONFIG_WATCHDOG_NOWAYOUT option compiled for the kernel or device-driver then an unplanned reboot will follow - be warned!

## FILES
/dev/watchdog

The watchdog device.

/var/run/wd_keepalive.pid

The pid file of the running wd_keepalive.

## SEE ALSO
watchdog.conf(5)

watchdog(8)


whoson

package: whoson

title: whoson(8)

summary: whoson test client

text:
# whoson(8)

## NAME
whoson - whoson test client

## SYNOPSYS
whoson {login|logout|query} arguments...

## DESCRIPTION
The whoson command accesses the whoson(8) daemon by calling specfied whoson(3) API function.

## COPYRIGHT
Public domain

## SEE ALSO
whoson(3), whosond(8)


whosond

package: whoson-server

title: whosond(8)

summary: whoson database daemon

text:
# whosond(8)

## NAME
whosond - whoson database daemon

## SYNOPSYS
whosond [-V] [-v] [-h] [-d] [-I configfile]

## DESCRIPTION
whosond command starts the daemon that maintains the in-memory database accessible by the application programs via the whoson(3) API functions.

Command options are:

-V - print version information and exit

-v - verbose operation - print debugging output to stdout. Useful together with -d option.

-d - do not go to the background. By default, the program forks a child that closes stdin, stdout and stderr, detaches from the controlling terminal and continue in the background. The parent process finishes.

-I configfile Specify alternative location for the configuration file. Default is /etc/whoson.conf.

The daemon implements one extentions to the "whoson" protocol: if you send a command verb LIST, the daemon responds with a multiline display of some statistics information.

## COPYRIGHT
Public domain

## SEE ALSO
whoson(3), whoson.conf(5)


wg

package: wireguard-tools

title: wg(8)

text:
# wg(8)

## NAME
wg - set and retrieve configuration of WireGuard interfaces

## SYNOPSIS
wg [ COMMAND ] [ OPTIONS ]... [ ARGS ]...

## DESCRIPTION
wg is the configuration utility for getting and setting the configuration of WireGuard tunnel interfaces. The interfaces themselves can be added and removed using ip-link(8) and their IP addresses and routing tables can be set using ip-address(8) and ip-route(8). The wg utility provides a series of sub-commands for changing WireGuard-specific aspects of WireGuard interfaces.

If no COMMAND is specified, COMMAND defaults to show. Sub-commands that take an INTERFACE must be passed a WireGuard interface.

## COMMANDS
show { <interface> | all | interfaces } [public-key | private-key | listen-port | fwmark | peers | preshared-keys | endpoints | allowed-ips | latest-handshakes | persistent-keepalive | transfer | dump]

Shows current WireGuard configuration and runtime information of specified <interface>. If no <interface> is specified, <interface> defaults to all. If interfaces is specified, prints a list of all WireGuard interfaces, one per line, and quits. If no options are given after the interface specification, then prints a list of all attributes in a visually pleasing way meant for the terminal. Otherwise, prints specified information grouped by newlines and tabs, meant to be used in scripts. For this script-friendly display, if all is specified, then the first field for all categories of information is the interface name. If dump is specified, then several lines are printed; the first contains in order separated by tab: private-key, public-key, listen-port, fwmark. Subsequent lines are printed for each peer and contain in order separated by tab: public-key, preshared-key, endpoint, allowed-ips, latest-handshake, transfer-rx, transfer-tx, persistent-keepalive.

showconf <interface>

Shows the current configuration of <interface> in the format described by CONFIGURATION FILE FORMAT below.

set <interface> [listen-port <port>] [fwmark <fwmark>] [private-key <file-path>] [peer <base64-public-key> [remove] [preshared-key <file-path>] [endpoint <ip>:<port>] [persistent-keepalive <interval seconds>] [allowed-ips <ip1>/<cidr1>[,<ip2>/<cidr2>]...] ]...

Sets configuration values for the specified <interface>. Multiple peers may be specified, and if the remove argument is given for a peer, that peer is removed, not configured. If listen-port is not specified, or set to 0, the port will be chosen randomly when the interface comes up. Both private-key and preshared-key must be files, because command line arguments are not considered private on most systems but if you are using bash(1), you may safely pass in a string by specifying as private-key or preshared-key the expression: <(echo PRIVATEKEYSTRING). If /dev/null or another empty file is specified as the filename for either private-key or preshared-key, the key is removed from the device. The use of preshared-key is optional, and may be omitted; it adds an additional layer of symmetric-key cryptography to be mixed into the already existing public-key cryptography, for post-quantum resistance. If allowed-ips is specified, but the value is the empty string, all allowed ips are removed from the peer. The use of persistent-keepalive is optional and is by default off; setting it to 0 or "off" disables it. Otherwise it represents, in seconds, between 1 and 65535 inclusive, how often to send an authenticated empty packet to the peer, for the purpose of keeping a stateful firewall or NAT mapping valid persistently. For example, if the interface very rarely sends traffic, but it might at anytime receive traffic from a peer, and it is behind NAT, the interface might benefit from having a persistent keepalive interval of 25 seconds; however, most users will not need this. The use of fwmark is optional and is by default off; setting it to 0 or "off" disables it. Otherwise it is a 32-bit fwmark for outgoing packets and may be specified in hexadecimal by prepending "0x".

setconf <interface> <configuration-filename>

Sets the current configuration of <interface> to the contents of <configuration-filename>, which must be in the format described by CONFIGURATION FILE FORMAT below.

addconf <interface> <configuration-filename>

Appends the contents of <configuration-filename>, which must be in the format described by CONFIGURATION FILE FORMAT below, to the current configuration of <interface>.

syncconf <interface> <configuration-filename>

Like setconf, but reads back the existing configuration first and only makes changes that are explicitly different between the configuration file and the interface. This is much less efficient than setconf, but has the benefit of not disrupting current peer sessions. The contents of <configuration-filename> must be in the format described by CONFIGURATION FILE FORMAT below.

genkey

Generates a random private key in base64 and prints it to standard output.

genpsk

Generates a random preshared key in base64 and prints it to standard output.

pubkey

Calculates a public key and prints it in base64 to standard output from a corresponding private key (generated with genkey) given in base64 on standard input. A private key and a corresponding public key may be generated at once by calling:

$ umask 077

$ wg genkey | tee private.key | wg pubkey > public.key

help

Shows usage message.

## CONFIGURATION FILE FORMAT
The configuration file format is based on INI. There are two top level sections -- Interface and Peer. Multiple Peer sections may be specified, but only one Interface section may be specified.

The Interface section may contain the following fields:

- PrivateKey — a base64 private key generated by wg genkey. Required.

- ListenPort — a 16-bit port for listening. Optional; if not specified, chosen randomly.

- FwMark — a 32-bit fwmark for outgoing packets. If set to 0 or "off", this option is disabled. May be specified in hexadecimal by prepending "0x". Optional.

The Peer sections may contain the following fields:

- PublicKey — a base64 public key calculated by wg pubkey from a private key, and usually transmitted out of band to the author of the configuration file. Required.

- PresharedKey — a base64 preshared key generated by wg genpsk. Optional, and may be omitted. This option adds an additional layer of symmetric-key cryptography to be mixed into the already existing public-key cryptography, for post-quantum resistance.

- AllowedIPs — a comma-separated list of IP (v4 or v6) addresses with CIDR masks from which incoming traffic for this peer is allowed and to which outgoing traffic for this peer is directed. The catch-all 0.0.0.0/0 may be specified for matching all IPv4 addresses, and ::/0 may be specified for matching all IPv6 addresses. May be specified multiple times.

- Endpoint — an endpoint IP or hostname, followed by a colon, and then a port number. This endpoint will be updated automatically to the most recent source IP address and port of correctly authenticated packets from the peer. Optional.

- PersistentKeepalive — a seconds interval, between 1 and 65535 inclusive, of how often to send an authenticated empty packet to the peer for the purpose of keeping a stateful firewall or NAT mapping valid persistently. For example, if the interface very rarely sends traffic, but it might at anytime receive traffic from a peer, and it is behind NAT, the interface might benefit from having a persistent keepalive interval of 25 seconds. If set to 0 or "off", this option is disabled. By default or when unspecified, this option is off. Most users will not need this. Optional.

## CONFIGURATION FILE FORMAT EXAMPLE
This example may be used as a model for writing configuration files, following an INI-like syntax. Characters after and including a '#' are considered comments and are thus ignored.

[Interface]

PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=

ListenPort = 51820

[Peer]

PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=

Endpoint = 192.95.5.67:1234

AllowedIPs = 10.192.122.3/32, 10.192.124.1/24

[Peer]

PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=

Endpoint = [2607:5300:60:6b0::c05f:543]:2468

AllowedIPs = 10.192.122.4/32, 192.168.0.0/16

[Peer]

PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=

Endpoint = test.wireguard.com:18981

AllowedIPs = 10.10.10.230/32

## DEBUGGING INFORMATION
Sometimes it is useful to have information on the current runtime state of a tunnel. When using the Linux kernel module on a kernel that supports dynamic debugging, debugging information can be written into dmesg(1) by running as root:

\# modprobe wireguard && echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

On OpenBSD and FreeBSD, debugging information can be written into dmesg(1) on a per-interface basis by using ifconfig(1):

\# ifconfig wg0 debug

On userspace implementations, it is customary to set the LOG_LEVEL environment variable to verbose.

## ENVIRONMENT VARIABLES
WG_COLOR_MODE

If set to always, always print ANSI colorized output. If set to never, never print ANSI colorized output. If set to auto, something invalid, or unset, then print ANSI colorized output only when writing to a TTY.

WG_HIDE_KEYS

If set to never, then the pretty-printing show sub-command will show private and preshared keys in the output. If set to always, something invalid, or unset, then private and preshared keys will be printed as "(hidden)".

WG_ENDPOINT_RESOLUTION_RETRIES

If set to an integer or to infinity, DNS resolution for each peer's endpoint will be retried that many times for non-permanent errors, with an increasing delay between retries. If unset, the default is 15 retries.

## SEE ALSO
wg-quick(8), ip(8), ip-link(8), ip-address(8), ip-route(8).

## AUTHOR
wg was written by Jason A. Donenfeld. For updates and more information, a project page is available on the World Wide Web.


wg-quick

package: wireguard-tools-wg-quick

title: wg-quick(8)

text:
# wg-quick(8)

## NAME
wg-quick - set up a WireGuard interface simply

## SYNOPSIS
wg-quick [ up | down | save | strip ] [ CONFIG_FILE | INTERFACE ]

## DESCRIPTION
This is an extremely simple script for easily bringing up a WireGuard interface, suitable for a few common use cases.

Use up to add and set up an interface, and use down to tear down and remove an interface. Running up adds a WireGuard interface, brings up the interface with the supplied IP addresses, sets up mtu and routes, and optionally runs pre/post up scripts. Running down optionally saves the current configuration, removes the WireGuard interface, and optionally runs pre/post down scripts. Running save saves the configuration of an existing interface without bringing the interface down. Use strip to output a configuration file with all wg-quick(8)-specific options removed, suitable for use with wg(8).

CONFIG_FILE is a configuration file, whose filename is the interface name followed by `.conf'. Otherwise, INTERFACE is an interface name, with configuration found at `/etc/wireguard/INTERFACE.conf', searched first, followed by distro-specific search paths.

Generally speaking, this utility is just a simple script that wraps invocations to wg(8) and ip(8) in order to set up a WireGuard interface. It is designed for users with simple needs, and users with more advanced needs are highly encouraged to use a more specific tool, a more complete network manager, or otherwise just use wg(8) and ip(8), as usual.

## CONFIGURATION
The configuration file adds a few extra configuration values to the format understood by wg(8) in order to configure additional attributes of an interface. It handles the values that it understands, and then it passes the remaining ones directly to wg(8) for further processing.

It infers all routes from the list of peers' allowed IPs, and automatically adds them to the system routing table. If one of those routes is the default route (0.0.0.0/0 or ::/0), then it uses ip-rule(8) to handle overriding of the default gateway.

The configuration file will be passed directly to wg(8)'s `setconf' sub-command, with the exception of the following additions to the Interface section, which are handled by this tool:

- Address — a comma-separated list of IP (v4 or v6) addresses (optionally with CIDR masks) to be assigned to the interface. May be specified multiple times.

- DNS — a comma-separated list of IP (v4 or v6) addresses to be set as the interface's DNS servers, or non-IP hostnames to be set as the interface's DNS search domains. May be specified multiple times. Upon bringing the interface up, this runs `resolvconf -a tun.INTERFACE -m 0 -x` and upon bringing it down, this runs `resolvconf -d tun.INTERFACE`. If these particular invocations of resolvconf(8) are undesirable, the PostUp and PostDown keys below may be used instead.

- MTU — if not specified, the MTU is automatically determined from the endpoint addresses or the system default route, which is usually a sane choice. However, to manually specify an MTU to override this automatic discovery, this value may be specified explicitly.

- Table — Controls the routing table to which routes are added. There are two special values: `off' disables the creation of routes altogether, and `auto' (the default) adds routes to the default table and enables special handling of default routes.

- PreUp, PostUp, PreDown, PostDown — script snippets which will be executed by bash(1) before/after setting up/tearing down the interface, most commonly used to configure custom DNS options or firewall rules. The special string `%i' is expanded to INTERFACE. Each one may be specified multiple times, in which case the commands are executed in order.

- SaveConfig — if set to `true', the configuration is saved from the current state of the interface upon shutdown. Any changes made to the configuration file before the interface is removed will therefore be overwritten.

Recommended INTERFACE names include `wg0' or `wgvpn0' or even `wgmgmtlan0'. However, the number at the end is in fact optional, and really any free-form string [a-zA-Z0-9_=+.-]{1,15} will work. So even interface names corresponding to geographic locations would suffice, such as `cincinnati', `nyc', or `paris', if that's somehow desirable.

## EXAMPLES
These examples draw on the same syntax found for wg(8), and a more complete description may be found there. Bold lines below are for options that extend wg(8).

The following might be used for connecting as a client to a VPN gateway for tunneling all traffic:

[Interface]

Address = 10.200.100.8/24

DNS = 10.200.100.1

PrivateKey = oK56DE9Ue9zK76rAc8pBl6opph+1v36lm7cXXsQKrQM=

[Peer]

PublicKey = GtL7fZc/bLnqZldpVofMCD6hDjrK28SsdLxevJ+qtKU=

PresharedKey = /UwcSPg38hW/D9Y3tcS1FOV0K1wuURMbS0sesJEP5ak=

AllowedIPs = 0.0.0.0/0

Endpoint = demo.wireguard.com:51820

The `Address` field is added here in order to set up the address for the interface. The `DNS` field indicates that a DNS server for the interface should be configured via resolvconf(8). The peer's allowed IPs entry implies that this interface should be configured as the default gateway, which this script does.

Building on the last example, one might attempt the so-called ``kill-switch'', in order to prevent the flow of unencrypted packets through the non-WireGuard interfaces, by adding the following two lines `PostUp` and `PreDown` lines to the `[Interface]` section:

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

The `PostUp' and `PreDown' fields have been added to specify an iptables(8) command which, when used with interfaces that have a peer that specifies 0.0.0.0/0 as part of the `AllowedIPs', works together with wg-quick's fwmark usage in order to drop all packets that are either not coming out of the tunnel encrypted or not going through the tunnel itself. (Note that this continues to allow most DHCP traffic through, since most DHCP clients make use of PF_PACKET sockets, which bypass Netfilter.) When IPv6 is in use, additional similar lines could be added using ip6tables(8).

Or, perhaps it is desirable to store private keys in encrypted form, such as through use of pass(1):

PostUp = wg set %i private-key <(pass WireGuard/private-keys/%i)

For use on a server, the following is a more complicated example involving multiple peers:

[Interface]

Address = 10.192.122.1/24

Address = 10.10.0.1/16

SaveConfig = true

PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=

ListenPort = 51820

[Peer]

PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=

AllowedIPs = 10.192.122.3/32, 10.192.124.1/24

[Peer]

PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=

AllowedIPs = 10.192.122.4/32, 192.168.0.0/16

[Peer]

PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=

AllowedIPs = 10.10.10.230/32

Notice the two `Address' lines at the top, and that `SaveConfig' is set to `true', indicating that the configuration file should be saved on shutdown using the current status of the interface.

A combination of the `Table', `PostUp', and `PreDown' fields may be used for policy routing as well. For example, the following may be used to send SSH traffic (TCP port 22) traffic through the tunnel:

[Interface]

Address = 10.192.122.1/24

PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=

ListenPort = 51820

Table = 1234

PostUp = ip rule add ipproto tcp dport 22 table 1234

PreDown = ip rule delete ipproto tcp dport 22 table 1234

[Peer]

PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=

AllowedIPs = 0.0.0.0/0

These configuration files may be placed in any directory, putting the desired interface name in the filename:

\# wg-quick up /path/to/wgnet0.conf

For convenience, if only an interface name is supplied, it automatically chooses a path in `/etc/wireguard/':

\# wg-quick up wgnet0

This will load the configuration file `/etc/wireguard/wgnet0.conf'.

The strip command is useful for reloading configuration files without disrupting active sessions:

\# wg syncconf wgnet0 <(wg-quick strip wgnet0)

## SEE ALSO
wg(8), ip(8), ip-link(8), ip-address(8), ip-route(8), ip-rule(8), resolvconf(8).

## AUTHOR
wg-quick was written by Jason A. Donenfeld. For updates and more information, a project page is available on the World Wide Web.


iwconfig

package: wireless-tools

title: iwconfig(8)

summary: configure a wireless network interface

text:
# iwconfig(8)

## NAME
iwconfig - configure a wireless network interface

## SYNOPSIS
iwconfig [interface]

iwconfig interface [essid X] [nwid N] [mode M] [freq F]

[channel C][sens S ][ap A ][nick NN ]

[rate R] [rts RT] [frag FT] [txpower T]

[enc E] [key K] [power P] [retry R]

[modu M] [commit]

iwconfig --help

iwconfig --version

## DESCRIPTION
Iwconfig is similar to ifconfig(8), but is dedicated to the wireless interfaces. It is used to set the parameters of the network interface which are specific to the wireless operation (for example : the frequency). Iwconfig may also be used to display those parameters, and the wireless statistics (extracted from /proc/net/wireless).

All these parameters and statistics are device dependent. Each driver will provide only some of them depending on hardware support, and the range of values may change. Please refer to the man page of each device for details.

## PARAMETERS
essid

Set the ESSID (or Network Name - in some products it may also be called Domain ID). The ESSID is used to identify cells which are part of the same virtual network.

As opposed to the AP Address or NWID which define a single cell, the ESSID defines a group of cells connected via repeaters or infrastructure, where the user may roam transparently.

With some cards, you may disable the ESSID checking (ESSID promiscuous) with off or any (and on to reenable it).

If the ESSID of your network is one of the special keywords (off, on or any), you should use -- to escape it.

Examples :

iwconfig eth0 essid any

iwconfig eth0 essid "My Network"

iwconfig eth0 essid -- "ANY"

nwid

Set the Network ID. As all adjacent wireless networks share the same medium, this parameter is used to differentiate them (create logical colocated networks) and identify nodes belonging to the same cell.

This parameter is only used for pre-802.11 hardware, the 802.11 protocol uses the ESSID and AP Address for this function.

With some cards, you may disable the Network ID checking (NWID promiscuous) with off (and on to reenable it).

Examples :

iwconfig eth0 nwid AB34

iwconfig eth0 nwid off

nick[name]

Set the nickname, or the station name. Some 802.11 products do define it, but this is not used as far as the protocols (MAC, IP, TCP) are concerned and completely useless as far as configuration goes. Only some wireless diagnostic tools may use it.

Example :

iwconfig eth0 nickname "My Linux Node"

mode

Set the operating mode of the device, which depends on the network topology. The mode can be Ad-Hoc (network composed of only one cell and without Access Point), Managed (node connects to a network composed of many Access Points, with roaming), Master (the node is the synchronisation master or acts as an Access Point), Repeater (the node forwards packets between other wireless nodes), Secondary (the node acts as a backup master/repeater), Monitor (the node is not associated with any cell and passively monitor all packets on the frequency) or Auto.

Example :

iwconfig eth0 mode Managed

iwconfig eth0 mode Ad-Hoc

freq/channel

Set the operating frequency or channel in the device. A value below 1000 indicates a channel number, a value greater than 1000 is a frequency in Hz. You may append the suffix k, M or G to the value (for example, "2.46G" for 2.46 GHz frequency), or add enough '0'.

Channels are usually numbered starting at 1, and you may use iwlist(8) to get the total number of channels, list the available frequencies, and display the current frequency as a channel. Depending on regulations, some frequencies/channels may not be available.

When using Managed mode, most often the Access Point dictates the channel and the driver may refuse the setting of the frequency. In Ad-Hoc mode, the frequency setting may only be used at initial cell creation, and may be ignored when joining an existing cell.

You may also use off or auto to let the card pick up the best channel (when supported).

Examples :

iwconfig eth0 freq 2422000000

iwconfig eth0 freq 2.422G

iwconfig eth0 channel 3

iwconfig eth0 channel auto

ap

Force the card to register to the Access Point given by the address, if it is possible. This address is the cell identity of the Access Point, as reported by wireless scanning, which may be different from its network MAC address. If the wireless link is point to point, set the address of the other end of the link. If the link is ad-hoc, set the cell identity of the ad-hoc network.

When the quality of the connection goes too low, the driver may revert back to automatic mode (the card selects the best Access Point in range).

You may also use off to re-enable automatic mode without changing the current Access Point, or you may use any or auto to force the card to reassociate with the currently best Access Point.

Example :

iwconfig eth0 ap 00:60:1D:01:23:45

iwconfig eth0 ap any

iwconfig eth0 ap off

rate/bit[rate]

For cards supporting multiple bit rates, set the bit-rate in b/s. The bit-rate is the speed at which bits are transmitted over the medium, the user speed of the link is lower due to medium sharing and various overhead.

You may append the suffix k, M or G to the value (decimal multiplier : 10^3, 10^6 and 10^9 b/s), or add enough '0'. Values below 1000 are card specific, usually an index in the bit-rate list. Use auto to select automatic bit-rate mode (fallback to lower rate on noisy channels), which is the default for most cards, and fixed to revert back to fixed setting. If you specify a bit-rate value and append auto, the driver will use all bit-rates lower and equal than this value.

Examples :

iwconfig eth0 rate 11M

iwconfig eth0 rate auto

iwconfig eth0 rate 5.5M auto

txpower

For cards supporting multiple transmit powers, sets the transmit power in dBm. If W is the power in Watt, the power in dBm is P = 30 + 10.log(W). If the value is postfixed by mW, it will be automatically converted to dBm.

In addition, on and off enable and disable the radio, and auto and fixed enable and disable power control (if those features are available).

Examples :

iwconfig eth0 txpower 15

iwconfig eth0 txpower 30mW

iwconfig eth0 txpower auto

iwconfig eth0 txpower off

sens

Set the sensitivity threshold. This define how sensitive is the card to poor operating conditions (low signal, interference). Positive values are assumed to be the raw value used by the hardware or a percentage, negative values are assumed to be dBm. Depending on the hardware implementation, this parameter may control various functions.

On modern cards, this parameter usually control handover/roaming threshold, the lowest signal level for which the hardware remains associated with the current Access Point. When the signal level goes below this threshold the card starts looking for a new/better Access Point. Some cards may use the number of missed beacons to trigger this. For high density of Access Points, a higher threshold make sure the card is always associated with the best AP, for low density of APs, a lower threshold minimise the number of failed handoffs.

On more ancient card this parameter usually controls the defer threshold, the lowest signal level for which the hardware considers the channel busy. Signal levels above this threshold make the hardware inhibits its own transmission whereas signals weaker than this are ignored and the hardware is free to transmit. This is usually strongly linked to the receive threshold, the lowest signal level for which the hardware attempts packet reception. Proper setting of these thresholds prevent the card to waste time on background noise while still receiving weak transmissions. Modern designs seems to control those thresholds automatically.

Example :

iwconfig eth0 sens -80

iwconfig eth0 sens 2

retry

Most cards have MAC retransmissions, and some allow to set the behaviour of the retry mechanism.

To set the maximum number of retries, enter limit `value'. This is an absolute value (without unit), and the default (when nothing is specified). To set the maximum length of time the MAC should retry, enter lifetime `value'. By defaults, this value in in seconds, append the suffix m or u to specify values in milliseconds or microseconds.

You can also add the short, long, min and max modifiers. If the card supports automatic mode, they define the bounds of the limit or lifetime. Some other cards define different values depending on packet size, for example in 802.11 min limit is the short retry limit (non RTS/CTS packets).

Examples :

iwconfig eth0 retry 16

iwconfig eth0 retry lifetime 300m

iwconfig eth0 retry short 12

iwconfig eth0 retry min limit 8

rts[_threshold]

RTS/CTS adds a handshake before each packet transmission to make sure that the channel is clear. This adds overhead, but increases performance in case of hidden nodes or a large number of active nodes. This parameter sets the size of the smallest packet for which the node sends RTS ; a value equal to the maximum packet size disables the mechanism. You may also set this parameter to auto, fixed or off.

Examples :

iwconfig eth0 rts 250

iwconfig eth0 rts off

frag[mentation_threshold]

Fragmentation allows to split an IP packet in a burst of smaller fragments transmitted on the medium. In most cases this adds overhead, but in a very noisy environment this reduces the error penalty and allow packets to get through interference bursts. This parameter sets the maximum fragment size which is always lower than the maximum packet size.

This parameter may also control Frame Bursting available on some cards, the ability to send multiple IP packets together. This mechanism would be enabled if the fragment size is larger than the maximum packet size.

You may also set this parameter to auto, fixed or off.

Examples :

iwconfig eth0 frag 512

iwconfig eth0 frag off

key/enc[ryption]

Used to manipulate encryption or scrambling keys and security mode.

To set the current encryption key, just enter the key in hex digits as XXXX-XXXX-XXXX-XXXX or XXXXXXXX. To set a key other than the current key, prepend or append [index] to the key itself (this won't change which is the active key). You can also enter the key as an ASCII string by using the s: prefix. Passphrase is currently not supported.

To change which key is the currently active key, just enter [index] (without entering any key value).

off and on disable and reenable encryption.

The security mode may be open or restricted, and its meaning depends on the card used. With most cards, in open mode no authentication is used and the card may also accept non-encrypted sessions, whereas in restricted mode only encrypted sessions are accepted and the card will use authentication if available.

If you need to set multiple keys, or set a key and change the active key, you need to use multiple key directives. Arguments can be put in any order, the last one will take precedence.

Examples :

iwconfig eth0 key 0123-4567-89

iwconfig eth0 key [3] 0123-4567-89

iwconfig eth0 key s:password [2]

iwconfig eth0 key [2]

iwconfig eth0 key open

iwconfig eth0 key off

iwconfig eth0 key restricted [3] 0123456789

iwconfig eth0 key 01-23 key 45-67 [4] key [4]

power

Used to manipulate power management scheme parameters and mode.

To set the period between wake ups, enter period `value'. To set the timeout before going back to sleep, enter timeout `value'. To set the generic level of power saving, enter saving `value'. You can also add the min and max modifiers. By default, those values are in seconds, append the suffix m or u to specify values in milliseconds or microseconds. Sometimes, those values are without units (number of beacon periods, dwell, percentage or similar).

off and on disable and reenable power management. Finally, you may set the power management mode to all (receive all packets), unicast (receive unicast packets only, discard multicast and broadcast) and multicast (receive multicast and broadcast only, discard unicast packets).

Examples :

iwconfig eth0 power period 2

iwconfig eth0 power 500m unicast

iwconfig eth0 power timeout 300u all

iwconfig eth0 power saving 3

iwconfig eth0 power off

iwconfig eth0 power min period 2 power max period 4

modu[lation]

Force the card to use a specific set of modulations. Modern cards support various modulations, some which are standard, such as 802.11b or 802.11g, and some proprietary. This command force the card to only use the specific set of modulations listed on the command line. This can be used to fix interoperability issues.

The list of available modulations depend on the card/driver and can be displayed using iwlist modulation. Note that some card/driver may not be able to select each modulation listed independantly, some may come as a group. You may also set this parameter to auto let the card/driver do its best.

Examples :

iwconfig eth0 modu 11g

iwconfig eth0 modu CCK OFDMa

iwconfig eth0 modu auto

commit

Some cards may not apply changes done through Wireless Extensions immediately (they may wait to aggregate the changes or apply it only when the card is brought up via ifconfig). This command (when available) forces the card to apply all pending changes.

This is normally not needed, because the card will eventually apply the changes, but can be useful for debugging.

## DISPLAY
For each device which supports wireless extensions, iwconfig will display the name of the MAC protocol used (name of device for proprietary protocols), the ESSID (Network Name), the NWID, the frequency (or channel), the sensitivity, the mode of operation, the Access Point address, the bit-rate, the RTS threshold, the fragmentation threshold, the encryption key and the power management settings (depending on availability).

The parameters displayed have the same meaning and values as the parameters you can set, please refer to the previous part for a detailed explanation of them.

Some parameters are only displayed in short/abbreviated form (such as encryption). You may use iwlist(8) to get all the details.

Some parameters have two modes (such as bitrate). If the value is prefixed by `=', it means that the parameter is fixed and forced to that value, if it is prefixed by `:', the parameter is in automatic mode and the current value is shown (and may change).

Access Point/Cell

An address equal to 00:00:00:00:00:00 means that the card failed to associate with an Access Point (most likely a configuration issue). The Access Point parameter will be shown as Cell in ad-hoc mode (for obvious reasons), but otherwise works the same.

If /proc/net/wireless exists, iwconfig will also display its content. Note that those values will depend on the driver and the hardware specifics, so you need to refer to your driver documentation for proper interpretation of those values.

Link quality

Overall quality of the link. May be based on the level of contention or interference, the bit or frame error rate, how good the received signal is, some timing synchronisation, or other hardware metric. This is an aggregate value, and depends totally on the driver and hardware.

Signal level

Received signal strength (RSSI - how strong the received signal is). May be arbitrary units or dBm, iwconfig uses driver meta information to interpret the raw value given by /proc/net/wireless and display the proper unit or maximum value (using 8 bit arithmetic). In Ad-Hoc mode, this may be undefined and you should use iwspy.

Noise level

Background noise level (when no packet is transmitted). Similar comments as for Signal level.

Rx invalid nwid

Number of packets received with a different NWID or ESSID. Used to detect configuration problems or adjacent network existence (on the same frequency).

Rx invalid crypt

Number of packets that the hardware was unable to decrypt. This can be used to detect invalid encryption settings.

Rx invalid frag

Number of packets for which the hardware was not able to properly re-assemble the link layer fragments (most likely one was missing).

Tx excessive retries

Number of packets that the hardware failed to deliver. Most MAC protocols will retry the packet a number of times before giving up.

Invalid misc

Other packets lost in relation with specific wireless operations.

Missed beacon

Number of periodic beacons from the Cell or the Access Point we have missed. Beacons are sent at regular intervals to maintain the cell coordination, failure to receive them usually indicates that the card is out of range.

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

## FILES
/proc/net/wireless

## SEE ALSO
ifconfig(8), iwspy(8), iwlist(8), iwevent(8), iwpriv(8), wireless(7).


iwevent

title: iwevent(8)

text:
# iwevent(8)

## NAME
iwevent - Display Wireless Events generated by drivers and setting changes

## SYNOPSIS
iwevent

## DESCRIPTION
iwevent displays Wireless Events received through the RTNetlink socket. Each line displays the specific Wireless Event which describes what has happened on the specified wireless interface.

This command doesn't take any arguments.

## DISPLAY
There are two classes of Wireless Events.

The first class is events related to a change of wireless settings on the interface (typically done through iwconfig or a script calling iwconfig). Only settings that could result in a disruption of connectivity are reported. The events currently reported are changing one of the following setting :

Network ID

ESSID

Frequency

Mode

Encryption

All those events will be generated on all wireless interfaces by the kernel wireless subsystem (but only if the driver has been converted to the new driver API).

The second class of events are events generated by the hardware, when something happens or a task has been finished. Those events include :

New Access Point/Cell address

The interface has joined a new Access Point or Ad-Hoc Cell, or lost its association with it. This is the same address that is reported by iwconfig.

Scan request completed

A scanning request has been completed, results of the scan are available (see iwlist).

Tx packet dropped

A packet directed at this address has been dropped because the interface believes this node doesn't answer anymore (usually maximum of MAC level retry exceeded). This is usually an early indication that the node may have left the cell or gone out of range, but it may be due to fading or excessive contention.

Custom driver event

Event specific to the driver. Please check the driver documentation.

Registered node

The interface has successfully registered a new wireless client/peer. Will be generated mostly when the interface acts as an Access Point (mode Master).

Expired node

The registration of the client/peer on this interface has expired. Will be generated mostly when the interface acts as an Access Point (mode Master).

Spy threshold crossed

The signal strength for one of the addresses in the spy list went under the low threshold or went above the high threshold.

Most wireless drivers generate only a subset of those events, not all of them, the exact list depends on the specific hardware/driver combination. Please refer to driver documentation for details on when they are generated, and use iwlist(8) to check what the driver supports.

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

## SEE ALSO
iwconfig(8), iwlist(8), iwspy(8), iwpriv(8), wireless(7).


iwgetid

title: iwgetid(8)

text:
# iwgetid(8)

## NAME
iwgetid - Report ESSID, NWID or AP/Cell Address of wireless network

## SYNOPSIS
iwgetid [interface] [--raw] [--scheme] [--ap] [--freq]

[--mode] [--protocol] [--channel]

## DESCRIPTION
iwgetid is used to find out the NWID, ESSID or AP/Cell Address of the wireless network that is currently used. The information reported is the same as the one shown by iwconfig, but iwgetid is easier to integrate in various scripts.

By default, iwgetid will print the ESSID of the device, and if the device doesn't have any ESSID it will print its NWID.

The default formatting output is pretty-print.

## OPTIONS
--raw

This option disables pretty-printing of the information. This option is orthogonal to the other options (except --scheme), so with the appropriate combination of options you can print the raw ESSID, AP Address or Mode.

This format is ideal when storing the result of iwgetid as a variable in Shell or Perl scripts or to pass the result as an argument on the command line of iwconfig.

--scheme

This option is similar to the previous one, it disables pretty-printing of the information and removes all characters that are not alphanumerics (like space, punctuation and control characters).

The resulting output is a valid Pcmcia scheme identifier (that may be used as an argument of the command cardctl scheme). This format is also ideal when using the result of iwgetid as a selector in Shell or Perl scripts, or as a file name.

--ap

Display the MAC address of the Wireless Access Point or the Cell.

--freq

Display the current frequency or channel used by the interface.

--channel

Display the current channel used by the interface. The channel is determined using the current frequency and the frequency list provided by the interface.

--mode

Display the current mode of the interface.

--protocol

Display the protocol name of the interface. This allows to identify all the cards that are compatible with each other and accept the same type of configuration.

This can also be used to check Wireless Extension support on the interface, as this is the only attribute that all drivers supporting Wireless Extension are mandated to support.

## SEE ALSO
iwconfig(8), ifconfig(8), iwspy(8), iwpriv(8).


iwlist

title: iwlist(8)

text:
# iwlist(8)

## NAME
iwlist - Get more detailed wireless information from a wireless interface

## SYNOPSIS
iwlist [interface] scanning

iwlist [interface] frequency

iwlist [interface] rate

iwlist [interface] keys

iwlist [interface] power

iwlist [interface] txpower

iwlist [interface] retry

iwlist [interface] event

iwlist [interface] auth

iwlist [interface] wpakeys

iwlist [interface] genie

iwlist [interface] modulation

iwlist --help

iwlist --version

## DESCRIPTION
Iwlist is used to display some additional information from a wireless network interface that is not displayed by iwconfig(8). The main argument is used to select a category of information, iwlist displays in detailed form all information related to this category, including information already shown by iwconfig(8).

## PARAMETERS
scan[ning]

Give the list of Access Points and Ad-Hoc cells in range, and optionally a whole bunch of information about them (ESSID, Quality, Frequency, Mode...). The type of information returned depends on what the card supports.

Triggering scanning is a privileged operation (root only) and normal users can only read left-over scan results. By default, the way scanning is done (the scope of the scan) is dependant on the card and card settings.

This command take optional arguments, however most drivers will ignore those. The option essid is used to specify a scan on a specific ESSID. The option last do not trigger a scan and read left-over scan results.

freq[uency]/channel

Give the list of available frequencies in the device and the number of defined channels. Please note that usually the driver returns the total number of channels and only the frequencies available in the present locale, so there is no one-to-one mapping between frequencies displayed and channel numbers.

rate/bit[rate]

List the bit-rates supported by the device.

keys/enc[ryption]

List the encryption key sizes supported and list all the encryption keys set in the device.

power

List the various Power Management attributes and modes of the device.

txpower

List the various Transmit Powers available on the device.

retry

List the transmit retry limits and retry lifetime on the device.

ap/accesspoint/peers

Give the list of Access Points in range, and optionally the quality of link to them. This feature is obsolete and now deprecated in favor of scanning support (above), and most drivers don't support it.

Some drivers may use this command to return a specific list of Peers or Access Points, such as the list of Peers associated/registered with the card. See your driver documentation for details.

event

List the wireless events supported by the device.

auth

List the WPA authentication parametes curently set.

wpa[keys]

List all the WPA encryption keys set in the device.

genie

List the Generic Information Elements set in the device (used for WPA support).

modu[lation]

List the modulations supported by the device and the modulations currently enabled.

--version

Display the version of the tools, as well as the recommended and current Wireless Extensions version for the tool and the various wireless interfaces.

--help

Display short help message.

## FILES
/proc/net/wireless

## SEE ALSO
iwconfig(8), iwspy(8). iwevent(8), iwpriv(8), wireless(7).