title: lldptool-evb22(8)

text:
# lldptool-evb22(8)

## NAME
evb22 - Show / manipulate EVB IEEE 802.1 Ratified Standard TLV configuration

## SYNOPSIS
lldptool -t -i ethx -g ncb -V evb

lldptool -t -i ethx -g ncb -V evb -c

lldptool -t -i ethx -g ncb -V evb -c enabletx

lldptool -T -i ethx -g ncb -V evb -c enabletx=[yes|no]

lldptool -t -i ethx -g ncb -V evb -c evbmode

lldptool -T -i ethx -g ncb -V evb -c evbmode=[bridge|station]

lldptool -t -i ethx -g ncb -V evb -c evbrrreq

lldptool -T -i ethx -g ncb -V evb -c evbrrreq=[yes|no]

lldptool -t -i ethx -g ncb -V evb -c evbrrcap

lldptool -T -i ethx -g ncb -V evb -c evbrrcap=[yes|no]

lldptool -t -i ethx -g ncb -V evb -c evbgpid

lldptool -T -i ethx -g ncb -V evb -c evbgpid=[yes|no]

lldptool -t -i ethx -g ncb -V evb -c ecpretries

lldptool -T -i ethx -g ncb -V evb -c ecpretries=[0..7]

lldptool -t -i ethx -g ncb -V evb -c ecprte

lldptool -T -i ethx -g ncb -V evb -c ecprte=[0..31]

lldptool -t -i ethx -g ncb -V evb -c vdprwd

lldptool -T -i ethx -g ncb -V evb -c vdprwd=[0..31]

lldptool -t -i ethx -g ncb -V evb -c vdprka

lldptool -T -i ethx -g ncb -V evb -c vdprka=[0..31]

## DESCRIPTION
The Edge Virtual Bridge (EVB) TLV is a TLV to announce the station and bridge's edge virtual bridging (EVB) capabilities and may request the bridge port to be set into reflective relay (hairpin) mode. If both sides agree on the modes and time out values, the edge control protocol (ECP) will be used to exchange VSI discovery protocol (VDP) data using ECP frames between the host interface and the adjacent switch port facing the host interface.

This man pages describes the IEEE 802.1 Qbg ratified standard dated from July 5th, 2012. The arguments and parameters differ from the IEEE 802.1 Qbg draft 0.2, which is also implemented. The EVB protocol version to be used depends on the organizational unique identifier (OUI) of the EVB TLV in the LLDP data stream. A OUI value of 0x001b3f stands for the IEEE 802.1 Qbg draft 0.2, a OUI value of 0x0080c2 stands for the IEEE 802.1 Qbg ratified standard. The version of the ECP and VDP protocols are determined by the ethernet type field in the ethernet header. The ethernet type value for IEEE 802.1 Qbg draft 0.2 is 0x88b7, the value for IEEE 802.1 Qbg ratified standard is 0x8890. Note that the EVB protocol is exchanged between nearest customer bridges only, employing the reserved multicast MAC address 01:80:c2:00:00:00 as destination MAC address. lldpad(8) supports both versions, the switch port configuration determines which version will be used. The switch port configuration should select only one protocol version, never both.

The command line options and arguments are explained in the lldptool(8) man pages. Only the EVB, ECP and VDP protocol specific parameters are detailed in this manual page.

## ARGUMENTS
The invocation without command line option '-c' and argument displays the complete EVB, ECP and VDP protocol settings in a pretty print out. See below for a detailed description on how to interpret the output.

-c text

Use of the command line option '-c' without any argument displays all known parameters in the format of key=value, which is suitable for post processing. Use command line option '-c' and one of the following arguments to display and set individual parameters. Text can be one of the following values:

enabletx

Enables or disables the EVB TLV to be transmitted. When set to disabled no EVB TLV will be included in the LLDP data stream. Furthermore the output of the complete EVB settings without option '-c' will be empty.

evbmode

Display the current role or sets the role the to given value. Supported values are either "station" or "bridge".

evbrrreq

Shows the current reflective relay (hairpin) request mode or sets the reflective relay (hairpin) request mode. If the value is "yes", the station requests the interface facing switch port to be set in reflective relay (hairpin) mode. This field is only valid for stations, the output of evbmode equals "station".

evbrrcap

Shows the current reflective relay (hairpin) capabilities or sets the reflective relay (hairpin) capabilities. If the value is "yes", the switch port will be set in reflective relay (hairpin) mode. This field is only valid for switches, the output of evbmode equals "bridge".

gpid

Shows the current station or switch support for grouping or turns on/off the station or switch support for grouping. If set to true, the station or switch wants to use group identifiers in VDP protocols.

ecpretries

Shows or sets the maximum number of retries for ECP frames to be retransmitted. A retransmit occurs when no ECP acknowledgement message has been received during a given time period.

ecprte

Shows or sets the local run time exponent (RTE). The RTE will be used as the base for the timing of the ECP protocol time outs and retransmits. The wait time is calculated as 10*2ecprte micro seconds.

vdprwd

Shows or sets the number of resource wait delay value. This value is calculated as 10*2vdprwd micro seconds and determines the maximum wait time for VDP protocol acknowledgements.

vdprka

Shows or sets the number of re-init keep alive value. This value is calculated as 10*2vdprka micro seconds and determines the wait time for VDP protocol to send a keep alive message.

## Theory of Operation
The EVB TLV is used to announce and exchange supported parameters between the station and an adjacent switch. If reflectiverelay is active, the switch sends back ethernet frames on the very same port it received the frame on. This is an extension to the current bridging standard and allows communication between virtual machines on the same host through the switch port.

## EXAMPLE & USAGE
Display locally configured values for eth0

lldptool -t -g ncb -i eth0 -V evb

```
EVB Configuration TLV
	bridge:(00)
	station:rrreq,rrstat(0x5)
	retries:7 rte:31
	mode:station r/l:0 rwd:31
	r/l:0 rka:8
```

This output is displayed when enabletx has been enabled. The first line shows the currently known status of the bridge. The second line shows the currently known status of the station. The status is displayed verbose appended by the hexadecimal value in parenthesis. The verbose output uses the bit naming convention used in the standard document. The third line displays the values for the ECP protocol number of retransmits (retries) and the retransmit timeout exponent. The forth line shows the current mode of operation, either bridge or station, the resource wait delay value (rwd) and an indication if the local (0) or remote (1) rwd value is used. The fifth line displays the value of the re-init keep alive counter (rka) and an indication if the local (0) or remote (1) rka value is used.

Display the currently requested forwarding mode for eth0

lldptool -t -g ncb -i eth0 -V evb -c evbrrreq

Display the locally configured value for RTE

lldptool -t -g ncb -i eth0 -V evb -c evbrte

Set the value for RTE to its maximum value

lldptool -T -g ncb -i eth0 -V evb -c rte=7

Set the value for enabletx to yes

lldptool -T -g ncb -i eth0 -V evb -c enabletx=yes

## NOTES
Currently the code in lldpad reflects IEEE 802.1 Qbg draft 0.2 of the upcoming standard. Wireshark support for IEEE 802.1 Qbg ratified standard TLVs is currently missing. Support for the IEEE 802.1 Qbg ratified standard protocols ECP and VDP is currently under development and not fully functional.

## SEE ALSO
lldptool-vdp(8), lldptool(8), lldpad(8)

IEEE 802.1Qbg (http://www.ieee802.org/1/pages/802.1bg.html)

## AUTHOR
Thomas Richter


lldptool-med

package: lldpad

title: lldptool-med(8)

text:
# lldptool-med(8)

## NAME
LLDP-MED - Show / manipulate MED TLV configurations

## SYNOPSIS
lldptool -t -i ethx -V [ TLV_TYPE ] enableTx

lldptool -T -i ethx -V [ TLV_TYPE ] enableTx = { yes | no }

lldptool -T -i ethx -V LLDP-MED devtype = { class1 | class2 | class3 | none }

lldptool -t -i ethx -V LLDP-MED devtype

TLV_TYPE : = {LLDP-MED | medCap | medPolicy | medLoc | medPower | medHwRev | medFwRev | medSwRev | medSerNum | medManuf | medModel | medAssetID }

## DESCRIPTION
The LLDP-MED extensions support the Link Layer Discovery Protocol for Media Endpoint Devices defined in the ANSI/TIA-1057-2006 document. Each TLV can be configured as a class1 , class2 or class3 device. Class I devices are the most basic class of Endpoint Device, Class II devices support media stream capabilities and Class III devices directly support end users of the IP communication system. See ANS-TIA-1057 for clarification of class types.

## ARGUMENTS
enableTx

Enables the TLV to be transmitted

devtype

Set or query the class type of the device.

## TLV_TYPE
List of supported TLV specifiers applicable to Media Endpoint Devices.

LLDP-MED

apply arguments to all supported MED TLVs.

medCAP

LLDP-MED Capabilities TLV

medPolicy

LLDP-MED Network Policy TLV

medLoc

LLDP-MED Location TLV

medPower

LLDP-MED Extended Power-via-MDI TLV

medHwRev

LLDP-MED Hardware Revision TLV

medFwRev

LLDP-MED Firmware Revision TLV

medSwRev

LLDP-MED Software Revision TLV

medSerNum

LLDP-MED Serial Number TLV

medManuf

LLDP-MED Manufacturer Name TL

medModel

LLDP-MED Model Name TLV

medAssetID

LLDP-MED Asset ID TLV

## EXAMPLE & USAGE
Enable class1 MED device on eth2

lldptool -T -i eth2 -V LLDP-MED enableTx=yes devtype=class1

Query class type of MED on eth2

lldptool -t -i eth2 -V LLDP-MED -c devtype

Query transmit state of medPolicy on device eth2

lldptool -t -i eth2 -V medPolicy -c enableTx

## SOURCE
o

Link Layer Discovery Protocol for Media Endpoint Devices (http://www.tiaonline.org/standards/technology/voip/documents/ANSI-TIA-1057_final_for_publication.pdf)

## SEE ALSO
lldptool(8), lldpad(8)

## AUTHOR
John Fastabend

branch: sisyphus


lldptool-pfc

title: lldptool-pfc(8)

summary: Show / manipulate PFC TLV configuration

text:
# lldptool-pfc(8)

## NAME
PFC - Show / manipulate PFC TLV configuration

## SYNOPSIS
lldptool -t -i ethx -V PFC [ -c [ enableTx | willing | enabled | delay ] ]

lldptool -T -i ethx -V PFC <CONFIG_ARG=value ...>

CONFIG_ARG:=

enableTx=<yes|no>

willing=<yes|no|0|1>

enabled=<none|[0..7],[0..7],...>

delay=<integer value>

## DESCRIPTION
The PFC TLV is used to display and set current PFC TLV attributes.

## ARGUMENTS
enableTx

Enable the PFC TLV to be transmitted in the LLDP PDU for the specified interface.

willing

Display or set the willing attribute. If set to yes and a peer TLV is received then the peer PFC attributes will be used. If set to no then locally configured attributes are used.

enabled

Display or set the priorities with PFC enabled. The set attribute takes a comma separated list of priorities to enable, or the string none to disable all priorities.

delay

Display or set the delay attribute used to configure PFC thresholds in hardware buffers. If PFC is enabled and frames continue to be dropped due to full hardware buffers then increasing this value may help.

## Theory of Operations
The PFC TLV uses the Symmetric attribute passing state machine defined in IEEE 802.1Qaz. This means the attributes used will depend on the willing bit. If the willing bit is set to 1 and a peer TLV is received then the peers attributes will be used. If the willing bit is set to 0 the local attributes will be used. When both the peer and local configuration are willing a tie breaking scheme is used. For more detailed coverage see the specification.

## EXAMPLE & USAGE
Enable PFC for priorities 1, 2, and 4 on eth2

lldptool -T -i eth2 -V PFC enabled=1,2,4

Disable PFC for all priorities on eth2

lldptool -T -i eth2 -V PFC enabled=none

Display configuration of PFC enabled priorities for eth2

lldptool -t -i eth2 -V PFC -c enabled

Display last transmitted PFC TLV on eth2

lldptool -t -i eth2 -V PFC

## SOURCE
o

IEEE 802.1Qaz (http://www.ieee802.org/1/pages/dcbridges.html)

## SEE ALSO
lldptool(8), lldpad(8)

## AUTHOR
John Fastabend


lldptool-vdp

title: lldptool-vdp(8)

summary: Show / manipulate VDP TLV configuration

text:
# lldptool-vdp(8)

## NAME
vdp - Show / manipulate VDP TLV configuration

## SYNOPSIS
lldptool -t -i ethx -V vdp -c enableTx

lldptool -T -i ethx -V vdp -c enableTx=[yes|no]

lldptool -t -i ethx -V vdp -c mode

lldptool -T -i ethx -V vdp -c mode=<mode>,<mgrid>,<typeid>,<typeidversion>,<instanceid>,<mac>,<vlan>

lldptool -t -i ethx -V vdp -c role

lldptool -T -i ethx -V vdp -c role=[station|bridge]

## DESCRIPTION
The VSI discovery protocol (VDP) is NOT a TLV in the LLDP sense but rather a protocol to manage the association and deassociation of virtual station interfaces (VSIs) between the station and an adjacent switch. VDP uses ECP as transport for VDP TLVs. An ECP frame may contain multiple VDP TLVs. Each VDP TLVs contains a mode, typeid, version, instanceid, mac and vlan for a VSI.

## ARGUMENTS
enableTx

Enables or disables VDP

mode

shows or sets modes for VSIs with the following parameters:

<mode>

mode (0=preassociate, 1=preassociate with RR, 2=associate, 3=deassociate)

<mgrid>

manager (database) id

<typeid>

VSI type id

<version>

VSI type id version

<instanceid>

VSI instance id

<format>

VDP filter info format

<mac>

VSI mac address

<vlan>

VSI vlan id

role

shows or sets the role of the local machine to act as either station (default) or bridge.

## Theory of Operation
The VDP protocol is used to pre-associate, associate or deassociate VSIs to and adjacent switch. Information about the VSIs is formatted into VDP TLVs which are then handed to ECP for lower-level transport. Each ECP frame may contain multiple VDP TLVs.

Two ways to receive VSI information exist in llpdad: via netlink or with lldptool. netlink is used by libvirt to communicate VSIs to lldpad. lldptool can be used to associate/deassociate VSIs from the command line. This is especially helpful for testing purposes.

## EXAMPLE & USAGE
Display if vdp is enabled on eth8

lldptool -t -i eth8 -V vdp -c enableTx

Enable vdp on eth8

lldptool -T -i eth8 -V vdp -c enableTx=yes

Display the currently configured VSIs for eth8

lldptool -t -i eth8 -V vdp -c mode

Associate a VSI on eth8

lldptool -T -i eth8 -V vdp -c mode=2,12,1193046,1,fa9b7fff-b0a0-4893-8e0e-beef4ff18f8f,2,52:54:00:C7:3E:CE,3

Display the locally configured role for VDP on eth8

lldptool -t -i eth8 -V vdp -c role

Set the local role for VDP on eth8

lldptool -T -i eth8 -V vdp -c role=bridge

## SOURCE
o

IEEE 802.1Qbg (http://www.ieee802.org/1/pages/802.1bg.html)

## NOTES
Currently the code in lldpad reflects draft 0 of the upcoming standard. ECP/VDP TLVs on the wire can be decoded with wireshark > v1.8.

## SEE ALSO
lldptool-evb(8), lldptool(8), lldpad(8)

## AUTHOR
Jens Osterkamp


vdptool

title: vdptool(8)

text:
# vdptool(8)

## NAME
vdptool - manage the VSI associations and status of lldpad

## SYNOPSIS
vdptool <command> [options] [argument]

## DESCRIPTION
vdptool is used to query and configure the VSI associations in lldpad. Only the ratified stardard version of the VDP protocol (also refered to as vdp22) is supported. It connects to the client interface of lldpad to perform these operations. vdptool will operate in interactive mode if it is executed without a command. In interactive mode, vdptool will also function as an event listener to print out events as they are received asynchronously from lldpad(still to be done). It will use libreadline for interactive input when available (still to be done).

## OPTIONS
-i [ifname]

specifies the network interface to which the command applies. Most vdptool commands require specifying a network interface.

-V [tlvid]

specifies the VDP tlv identifier to be set or queried.

The tlvid is an integer value used to identify specific VDP TLVs. The tlvid value is the type value for types not equal to 127 (the organizationally specific type). For organizationally specific TLVs, the tlvid is the value represented by the 3 byte OUI and 1 byte subtype - where the subtype is the lowest order byte of the tlvid.

The tlvid can be entered as a numerical value (e.g. 10 or 0xa), or for supported TLVs, as a keyword (such as assoc, deassoc, preassoc, preassoc-rr, etc). Review the vdptool help output to see the list of supported TLV keywords. Use option -c to specify the parameters and its values to be set or queried.

-n

"neighbor" option for commands which can use it (e.g. get-tlv). Use this flag to retrieve the last VDP22 data returned from the bridge. (not yet supported).

-c <argument list>

Specifies additional parameters for TLV queries and associations commands. The argument list varies, depending on the command option (-T) or (-t). To establish a VSI association use the command option (-T) and specify additional information as arguments in the form of key=value. See the VSI Parameter subsection and Example section below. To query a VSI specific association use the command option (-t) and specify the value of the VSI Instance Identifier (keywork uuid followed be the VSI UUID value) of the VSI association as configuration parameter.

-r

show raw client interface messages

-R

show only raw Client interface messages

-W

Wait for the bridge response message

### VSI Parameter
Each VDP22 TLVs contains a command mode, manager identifier, type identifier, type identifier version, VSI instance identifier, migration hints and filter information. The fields are explained next:

mode (Command Mode):

The command mode determines the type of the VSI association to be established. It is an ascii string can be one of:

assoc:

Create an VSI association.

preassoc:

Create an VSI preassociation. The association is only announced to the switch.

preassoc-rr:

Create an VSI preassociation. The association is only announced to the switch and the switch should reserve the resources.

deassoc:

Delete an VSI association.

Other strings are not recognized and return an error. mgrid2 (Manager identifier):

The manager identifier is a string of up to 16 alphanumeric characters. It can also be an UUID according to RFC 4122 with optional dashes in between.

typeid (Type Identifier):

The type identifier is a number in the range of 0 to 2^24 - 1.

typeidver (Type Identifier Version):

The type identifer version is a number in the range of 0 to 255.

uuid (VSI Instance Identifier):

The VSI instance identifier is an UUID according to RFC 4122 with optional dashes in between.

hints (Migration Hints):

The migration hints is a string aiding in migration of virtual machines:

none:

No hints available.

from:

The virtual machine is migrating away.

to:

The virtual machine is migrating to.

fid (Filter Information Data):

The filter information data can be supplied in four different formats identified by numbers in parathesis. Multiple filter information fields can be supplied, but all have to be of the same format.

vlan (1)

A vlan number only, also known as filter information format 1. The vlan identifier is a number in the range of 1 to 2^16 - 1. The high order 4 bits are used as quality of service bits. The vlan identifier can be zero, a vlan identifier is then selected by the switch. Refer to IEEE 802.1 Qbg ratified standard for details.

vlan-mac (2)

A vlan number and MAC address delimited by a slash ('-'), also known as filter information format 2. The MAC address is specified in the format xx:xx:xx:xx:xx:xx. The colons are mandatory. For vlan details see (1).

vlan-mac-group (4)

A vlan number, MAC address and group identifier, each delimited by a slash ('-'), also known as filter information format 4. The group identifier is a 32 bit number. For vlan and MAC address details see (1) and (2).

vlan--group (3)

A vlan number and group identifier, delimited by two slashes ('--'), also known as filter information format 3. For vlan and group details see (1) and (4).

oui (Organizationally Unique Identifier):

This defines the optional Organizationally defined information field. This contains the specific sets of values for this entry. There can be multiple organizational specific fields, in which case there will be multiple keywords oui= followed by the values. The value is of the following format:

```
oui=OUI,[Organization specific values ]

```

The OUI specifies the name of the Organization that is responsible for defining this content. A comma is mandatory after the OUI field. The fields following this

is specified by the organization and hence will be decoded based on the value of this OUI field. Currently, the following values for OUI are supported.

cisco

Specifies Cisco defined OUI.

## COMMANDS
license

show license information

-h, help

show usage information

-v, version

show version information

-t, get-vsi

get VSI information for the specified interface

-T, set-vsi

set VSI information for the specified interface

-p, ping

display the process identifier of the running lldpad process

-q, quit

exit from interactive mode

## NOTES
This tool is in its early design and development phase. It it buggy, incomplete and most of the ideas have not even been thought of.... It reflects the current state of development when I had been given another work assignment. I append it so some else can continue to work on this.

## EXAMPLES
Display process identifier of lldpad

vdptool -p

Create a VSI association on interface eth2

```
vdptool -i eth2 -T -V assoc -c mode=assoc -c mgrid2=blabla \
	-c typeid=5 -c uuid=1122 -c typeidver=4 -c hints=none \
	-c filter=2-52:00:00:11:22:33-200
```

Create a VSI association on interface eth2 and wait for the

response from the bridge

```
vdptool -i eth2 -T -W -V assoc -c mode=assoc -c mgrid2=blabla \
	-c typeid=5 -c uuid=1122 -c typeidver=4 -c hints=none \
	-c filter=0-52:00:00:11:22:33-200
```

Create a VSI association on interface eth2 wth OUI parameters

and wait for the response from the bridge

```
vdptool -i eth2 -T -W -V assoc -c mode=assoc -c mgrid2=blabla \
	-c typeid=5 -c uuid=1122 -c typeidver=4 -c hints=none \
	-c filter=0-52:00:00:11:22:33-200 -c oui=CompanyA,data
```

Create a VSI association on interface eth2 wth multiple OUI parameters

and wait for the response from the bridge

```
vdptool -i eth2 -T -W -V assoc -c mode=assoc -c mgrid2=blabla \
	-c typeid=5 -c uuid=1122 -c typeidver=4 -c hints=none \
	-c filter=0-52:00:00:11:22:33-200 -c oui=CompanyA,data \
	-c oui=CompanyB,data
```

Query all VSI association on interface eth2

vdptool -i eth2 -t -V assoc

Query VSI association on interface eth2 that matches specific

VSI parameters. Any of the VSI parameters below can be omitted.

vdptool -i eth2 -t -V assoc -t -V assoc -c mode=assoc \

-c mgrid2=blabla -c typeid=5 -c uuid=1122 \

-c typeidver=4 -c hints=none

## SEE ALSO
lldptool-dcbx(8), lldptool-ets(8), lldptool-pfc(8), lldptool-app(8), lldptool-med(8), lldptool-vdp(8), lldptool-evb(8), lldptool-evb22(8), dcbtool(8), lldpad(8)

## COPYRIGHT
vdptool - VSI configuration utility

Copyright(c)

(c) 2014 IBM Corporation. Portions of vdptool are based on:

open-lldp-0.96

lldptool - LLDP agent configuration utility

Copyright(c)

2007-2012 Intel Corporation. Portions of lldptool are based on:

hostapd-0.5.7

Copyright

(c) 2004-2008, Jouni Malinen <j@w1.fi>

## LICENSE
This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, version 2, as published by the Free Software Foundation.

This program is distributed in the hope it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.

The full GNU General Public License is included in this distribution in the file called "COPYING".

## SUPPORT
Contact Information: open-lldp Mailing List <lldp-devel@open-lldp.org>


lldpcli

package: lldpd

title: lldpcli(8)

summary: control LLDP daemon

text:
# lldpcli(8)

## NAME
lldpcli, lldpctl — control LLDP daemon

## SYNOPSIS
lldpcli

[-dv] [-u socket] [-f format] [-c file] [command ...]

lldpctl

[-dv] [-u socket] [-f format] [interfaces ...]

## DESCRIPTION
The lldpcli program controls lldpd(8) daemon.

When no command is specified, lldpcli will start an interactive shell which can be used to input arbitrary commands as if they were specified on the command line. This interactive shell should provide completion and history support.

The options are as follows:

-d

Enable more debugging information. This flag can be repeated.

-u socket

Specify the Unix-domain socket used for communication with lldpd(8).

-v

Show lldpcli version. When repeated, show more build information.

-f format

Choose the output format. Currently plain, xml, json, json0 and keyvalue formats are available. The default is plain. json0 is more verbose than json but the structure of the JSON object is not affected by the number of interfaces or the number of neighbors. It is therefore easier to parse.

-c file

Read the given configuration file. This option may be repeated several times. If a directory is provided, each file therein suffixed with .conf. will be read. Order is alphabetical.

When invoked as lldpctl, lldpcli will display detailed information about each neighbor on the specified interfaces or on all interfaces if none are specified. This command is mostly kept for backward compatibility with older versions.

The following commands are supported by lldpcli. When there is no ambiguity, the keywords can be abbreviated. For example, show neighbors ports eth0 summary and sh neigh p eth0 sum are the same command.

exit Quit lldpcli.

help [...]

Display general help or help about a command. Also, you can get help using the completion or by pressing the ? key. Completion and inline help may be unavailable, however, if lldpcli was compiled without readline support but help command is always available.

show neighbors [ports ethX [,...]] [details | summary] [hidden]

Display information about each neighbor known by lldpd(8) daemon. With summary, only the name and the port description of each remote host will be displayed. On the other hand, with details, all available information will be displayed, giving a verbose view. When using hidden, also display remote ports hidden by the smart filter. When specifying one or several ports, the information displayed is limited to the given list of ports.

show interfaces [ports ethX [,...]] [details | summary] [hidden]

Display information about each local interface known by lldpd(8) daemon. With summary, only the name and the port description of each local interface will be displayed. On the other hand, with details, all available information will be displayed, giving a verbose view. When using hidden, also display local ports hidden by the smart filter. When specifying one or several ports, the information displayed is limited to the given list of ports.

show chassis [details | summary]

Display information about local chassis. With summary, most details are skipped. On the other hand, with details, all available information will be displayed, giving a verbose view.

watch [ports ethX [,...]] [details | summary] [hidden] [limit X]

Watch for any neighbor changes and report them as soon as they happen. When specifying ports, the changes are only reported when happening on the given ports. hidden, summary and details have the same meaning as previously described. If limit is specified, lldpcli will exit after receiving the specified number of events.

show configuration

Display global configuration of lldpd(8) daemon.

show statistics [ports ethX [,...]] [summary]

Report LLDP-related statistics, like the number of LLDPDU transmitted, received, discarded or unrecognized. When specifying ports, only the statistics from the given port are reported. With summary the statistics of each port are summed.

update

Make lldpd(8) update its information and send new LLDP PDU on all interfaces.

configure system hostname name

Override system hostname with the provided value. By default, the system name is the FQDN found from the resolved value of uname -n. As a special value, use "." (dot) to use the short hostname instead of a FQDN.

unconfigure system hostname

Do not override system hostname and restore the use of the node name.

configure system description description

Override chassis description with the provided value instead of using kernel name, node name, kernel version, build date and architecture.

unconfigure system description

Do not override chassis description and use a value computed from node name, kernel name, kernel version, build date and architecture instead.

configure system chassisid description

Override chassis ID with the provided value instead of using MAC address from one interface or host name.

unconfigure system chassisid

Do not override chassis ID, but instead use a value computed from one of the interface MAC addresses (or host name if none is found).

configure system platform description

Override platform description with the provided value instead of using kernel name. This value is currently only used for CDP.

unconfigure system platform

Do not override platform description and use the kernel name. This option undoes the previous one.

configure system capabilities enabled capabilities

Override system capabilities with the provided value instead of using kernel information. Several capabilities can be specified, separated by commas. Only available capabilities can be enabled. Valid capabilities are: bridge

docsis

other

repeater

router

station

telephone

wlan

Here is an example of use: configure system capabilities enabled bridge,router

unconfigure system capabilities enabled

Do not override capabilities, but instead use the kernel information. This option undoes the previous one.

configure system interface pattern pattern

Specify as comma separated values (CSV) which interfaces to listen upon and send LLDPDU from. Without this option, lldpd will use all available physical interfaces. This option can use wildcards. Several interfaces can be specified separated by commas. It is also possible to remove an interface by prefixing it with an exclamation mark. It is possible to allow an interface by prefixing it with two exclamation marks. An allowed interface beats a forbidden interface which beats a simple matched interface. For example, with eth*,!eth1,!eth2 lldpd will only use interfaces starting with eth with the exception of eth1 and eth2. While with *,!eth*,!!eth1 lldpcli will use all interfaces, except interfaces starting with eth with the exception of eth1. When an exact match is found, it will circumvent some tests. For example, if eth0.12 is specified, it will be accepted even if this is a VLAN interface.

unconfigure system interface pattern

Remove any previously configured interface pattern and use all physical interfaces. This option undoes the previous one.

configure system interface permanent pattern

Specify interfaces whose configuration is permanently kept by lldpd. By default, lldpd disregards any data about interfaces when they are removed from the system (statistics, custom configuration). This option allows one to specify a pattern similar to the interface pattern. If an interface disappears but matches the pattern, its data is kept in memory and reused if the interface reappears at some point. For example, on Linux, one could use the pattern eth*,eno*,enp*, which should match fixed interfaces on most systems.

unconfigure system interface permanent

Remove any previously configured permanent interface pattern. Any interface removed from the system will be forgotten. This option undoes the previous one.

configure system interface description

Some OSes allow the user to set a description for an interface. Setting this option will enable lldpd to override this description with the name of the peer neighbor if one is found or with the number of neighbors found.

unconfigure system interface description

Do not update interface description with the name of the peer neighbor. This option undoes the previous one.

configure system interface promiscuous

Enable promiscuous mode on managed interfaces. When the interface is not managed any more (or when quitting lldpd), the interface is left in promiscuous mode as it is difficult to know if someone else also put the interface in promiscuous mode.

This option is known to be useful when the remote switch is a Cisco 2960 and the local network card features VLAN hardware acceleration. In this case, you might not receive LLDP frames from the remote switch. The most plausible explanation for this is that the frame is tagged with some VLAN (usually VLAN 1) and your network card filters VLANs. This is not the only available solution to work around this problem. If you are concerned about performance issues, you can also tag VLAN 1 on each interface instead.

Currently, this option has no effect on anything other than Linux. On other OSes, either disable VLAN acceleration, tag VLAN 1 or enable promiscuous mode manually on the interface.

unconfigure system interface promiscuous

Do not set promiscuous mode on managed interfaces. This option does not disable promiscuous mode on interfaces already using this mode.

configure system ip management pattern pattern

Specify the management addresses of this system as comma separated values (CSV). As for interfaces (described above), this option can use wildcards and inversions. Without this option, the first IPv4 and the first IPv6 are used. If an exact IP address is provided, it is used as a management address without any check. If only negative patterns are provided, only one IPv4 and one IPv6 address are chosen. Otherwise, many of them can be selected. To remove IPv6 addresses, use !*:*. If an interface name is matched, the first IPv4 address and the first IPv6 address associated with this interface will be chosen.

unconfigure system ip management pattern

Unset any specific pattern for matching management addresses. This option undoes the previous one.

configure system bond-slave-src-mac-type value

Set the type of src mac in lldp frames sent on bond slaves Valid types are:

real

Slave real mac

zero

All zero mac

fixed

An arbitrary fixed value (00:60:08:69:97:ef)

local

Real mac with locally administered bit set. If the real mac already has the locally administered bit set, fall back to the fixed value.

Default value for bond-slave-src-mac-type is local. Some switches may complain when using one of the two other possible values (either because 00:00:00:00:00:00 is not a valid MAC or because the MAC address is flapping from one port to another). Using local might lead to a duplicate MAC address on the network (but this is quite unlikely).

configure system max-neighbors neighbors

Change the maximum number of neighbors accepted (for each protocol) on an interface. This is a global value. The default is 32. This setting only applies to future neighbors.

configure lldp agent-type nearest-bridge | nearest-non-tpmr-bridge | nearest-customer-bridge

The destination MAC address used to send LLDPDU allows an agent to control the propagation of LLDPDUs. By default, the 01:80:c2:00:00:0e MAC address is used and limits the propagation of the LLDPDU to the nearest bridge (nearest-bridge). To instruct lldpd to use the 01:80:c2:00:00:03 MAC address instead, use nearest-nontpmr-bridge instead. To use the 01:80:c2:00:00:00 MAC address instead, use nearest-customer-bridge instead.

configure lldp capabilities-advertisements

Enable advertisements of the chassis capabilities TLV. Currently the default.

unconfigure lldp capabilities-advertisements

Disable advertisements of the chassis capabilities TLV.

configure lldp management-addresses-advertisements

Enable advertisements of the management address TLV. Currently the default.

unconfigure lldp management-addresses-advertisements

Disable advertisements of the management address TLV.

configure lldp portidsubtype ifname | macaddress

configure [ports ethX [,...]] lldp portidsubtype local value

Force port ID subtype. By default, lldpd will use the MAC address as port identifier and the interface name as port description, unless the interface has an alias. In this case, the interface name will be used as port identifier and the description will be the interface alias. With this command, you can force the port identifier to be the interface name (with ifname), the MAC address (with macaddress) or a local value (with value). In the latest case, the local value should be provided.

configure [ports ethX [,...]] lldp portdescription description

Force port description to the provided string.

configure lldp tx-interval interval

Change transmit delay to the specified value in seconds. The transmit delay is the delay between two transmissions of LLDP PDU. The valid range is 1 through 3600 in seconds. The default value is 30 seconds. Note: lldpd also starts another system based refresh timer on each port to detect changes such as a hostname. This is the value of the tx-interval multiplied by 20. You can specify an interval value in milliseconds by appending a "ms" suffix to the figure (e.g. "configure lldp tx-interval 1500ms" is 1.5s, not 1500s). In this case the TTL for received and sent LLDP frames is rounded up to the next second. Note: the effective interval can be limited by the operating system capabilities and CPU speed.

configure lldp tx-hold hold

Change transmit hold value to the specified value. This value is used to compute the TTL of transmitted packets which is the product of this value and of the transmit delay. The valid range is 1 through 100. The default value is 4 and therefore the default TTL is 120 seconds.

configure [ports ethX [,...]] lldp status rx-and-tx | rx-only | tx-only | disabled

Configure the administrative status of the given port. By default, all ports are configured to be in rx-and-tx mode. This means they can receive and transmit LLDP frames (as well as other protocols if needed). In rx-only mode, they won't emit any frames and in tx-only mode, they won't receive any frames. In disabled mode, no frame will be sent and any incoming frame will be discarded. This setting does not override the operational mode of the main daemon. If it is configured in receive-only mode (with the -r flag), setting any transmit mode won't have any effect.

configure [ports ethX [,...]] lldp vlan-tx vlan_id [prio priority [dei dei]]

Configure the given port to send LLDP frames over a specified VLAN. With VLAN Identifier (VID) as vlan_id, Priority Code Point (PCP) as priority, and Drop Eligible Indicator (DEI) as dei. lldpd accepts LLDP frames on all VLANs.

configure [ports ethX [,...]] lldp custom-tlv [add | replace] oui oui subtype subtype [oui-info content]

Emit a custom TLV for OUI oui, with subtype subtype and optionally with the bytes specified in content. Both oui and content shall be a comma-separated list of bytes in hex format. oui must be exactly 3 bytes long. If add is specified then the TLV will be added. This is the default action. If replace is specified then all TLVs with the same oui and subtype will be replaced.

unconfigure [ports ethX [,...]] lldp custom-tlv [oui oui] [subtype subtype]

When no oui is specified, remove all previously configured custom TLV. When OUI oui and subtype subtype is specified, remove specific instances of custom TLV.

configure [ports ethX [,...]] lldp vlan-advertisements pattern pattern

Configure VLAN advertisements for the given port as a comma separated values (CSV). As for interfaces (described above), this option can use wildcards and inversions. Without this option, lldpd will advertise all VLANS.

unconfigure [ports ethX [,...]] lldp vlan-advertisements pattern

Remove any previously configured VLAN advertisements pattern for the given port.

configure lldp fast-start enable | tx-interval interval

Configure LLDP fast start mechanism. When a new LLDP neighbor is detected, fast start allows lldpd to shorten the interval between two LLDPDU. enable should enable LLDP fast start while tx-interval specifies the interval between two LLDPDU in seconds. The valid interval range is 1 through 3600 in seconds. The default interval is 1 second. Once 4 LLDPDU have been sent, the fast start mechanism is disabled until a new neighbor is detected.

unconfigure lldp fast-start

Disable LLDP fast start mechanism.

configure [ports ethX [,...]] med location coordinate latitude latitude longitude longitude altitude altitude unit datum datum

Advertise a coordinate based location on the given ports (or on all ports if no port is specified). The format of latitude is a decimal floating point number followed either by N or S. The format of longitude is a decimal floating point number followed either by E or W. altitude is a decimal floating point number followed either by m when expressed in meters or f when expressed in floors. A space is expected between the floating point number and the unit. datum is one of those values:

- WGS84

- NAD83

- NAD83/MLLW

A valid use of this command is:

configure ports eth0 med location coordinate latitude 48.85667N longitude 2.2014E altitude 117.47 m datum WGS84

configure [ports ethX [,...]] med location address country country [type value [...]]

Advertise a civic address on the given ports (or on all ports if no port is specified). country is the two-letter code representing the country. The remaining arguments should be paired to form the address. The first member of each pair indicates the type of the second member which is a free-form text. Here is the list of valid types:

- language

- country-subdivision

- county

- city

- city-division

- block

- street

- direction

- trailing-street-suffix

- street-suffix

- number

- number-suffix

- landmark

- additional

- name

- zip

- building

- unit

- floor

- room

- place-type

- script

A valid use of this command is:

configure ports eth1 med location address country US street "Commercial Road" city "Roseville"

configure [ports ethX [,...]] med location elin number

Advertise the availability of an ELIN number. This is used for setting up emergency calls. If the provided number is too small, it will be padded with 0. Here is an example of use: configure ports eth2 med location elin 911

configure [ports ethX [,...]] med policy application application [unknown] [tagged] [vlan vlan] [priority priority] [dscp dscp]

Advertise a specific network policy for the given ports (or for all ports if no port was provided). Only the application type is mandatory. application should be one of the following values:

- voice

- voice-signaling

- guest-voice

- guest-voice-signaling

- softphone-voice

- video-conferencing

- streaming-video

- video-signaling

The unknown flag tells that the network policy for the specified application type is required by the device but is currently unknown. This is used by Endpoint Devices, not by Network Connectivity Devices. If not specified, the network policy for the given application type is defined.

A VLAN specified with vlan tells which 802.1q VLAN ID has to be advertised for the network policy. A valid value is between 1 and 4094. tagged tells that the VLAN should be tagged for the specified application type.

priority allows one to specify IEEE 802.1d / IEEE 802.1p Layer 2 Priority, also known as Class of Service (CoS), to be used for the specified application type. This field is usually ignored if no VLAN is specified. The names match 802.1D-2004 standard (table G-2). Some more recent standards may use different labels. Only the numeric values should be relied upon. The accepted labels are:

1

background

0

best-effort

2

excellent-effort

3

critical-applications

4

video

5

voice

6

internetwork-control

7

network-control

dscp represents the DSCP value to be advertised for the given network policy. DiffServ/Differentiated Services Code Point (DSCP) value as defined in IETF RFC 2474 for the specified application type. Value: 0 (default per RFC 2475) through 63. Note: The class selector DSCP values are backwards compatible for devices that only support the old IP precedence Type of Service (ToS) format. (See the RFCs for what these values mean)

A valid use of this command is:

configure med policy application voice vlan 500 priority voice dscp 46

configure inventory hardware-revision value

Override hardware-revision with the provided value. By default, the hardware-revision is fetched from /sys/class/dmi

unconfigure inventory hardware-revision

Do not override hardware-revision and restore the use of the /sys/class/dmi value.

configure inventory software-revision value

Override software-revision with the provided value. By default, the software-revision is fetched from uname

unconfigure inventory software-revision

Do not override software-revision and restore the use of the uname value.

configure inventory firmware-revision value

Override firmware-revision with the provided value. By default, the firmware-revision is fetched from /sys/class/dmi

unconfigure inventory firmware-revision

Do not override firmware-revision and restore the use of the /sys/class/dmi value.

configure inventory serial-number value

Override serial-number with the provided value. By default, the serial-number is fetched from /sys/class/dmi

unconfigure inventory serial-number

Do not override serial-number and restore the use of the /sys/class/dmi value.

configure inventory manufacturer value

Override manufacturer with the provided value. By default, the manufacturer is fetched from /sys/class/dmi

unconfigure inventory manufacturer

Do not override manufacturer and restore the use of the /sys/class/dmi value.

configure inventory model value

Override model with the provided value. By default, the model is fetched from /sys/class/dmi

unconfigure inventory model

Do not override model and restore the use of the /sys/class/dmi value.

configure inventory asset value

Override asset with the provided value. By default, the asset is fetched from /sys/class/dmi

unconfigure inventory asset

Do not override asset and restore the use of the /sys/class/dmi value.

configure [ports ethX [,...]] med power pse | pd source source priority priority value value

Advertise the LLDP-MED POE-MDI TLV for the given ports or for all interfaces if no port is provided. One can act as a PD (power consumer) or a PSE (power provider). No check is done on the validity of the parameters while LLDP-MED requires some restrictions:

- PD shall never request more power than physical 802.3af class.

- PD shall never draw more than the maximum power advertised by PSE.

- PSE shall not reduce power allocated to PD when this power is in use.

- PSE may request reduced power using conservation mode

- Being PSE or PD is a global parameter, not a per-port parameter. lldpcli does not enforce this: a port can be set as PD or PSE. LLDP-MED also requires a PSE to have only one power source (primary or backup). Again, lldpcli does not enforce this. Each port can have its own power source. The same applies for PD and power priority. LLDP-MED MIB does not allow this kind of representation.

Valid types are:

pse

Power Sourcing Entity (power provider)

pd

Power Device (power consumer)

Valid sources are:

unknown

Unknown

primary

For PSE, the power source is the primary power source.

backup

For PSE, the power source is the backup power source, or a power conservation mode is requested (the PSE may be running on UPS for example).

pse

For PD, the power source is the PSE.

local

For PD, the power source is a local source.

both

For PD, the power source is both the PSE and a local source.

Valid priorities are:

unknown

Unknown priority

critical

Critical

high

High

low

Low

value should be the total power in milliwatts required by the PD device or available by the PSE device.

Here is an example of use:

configure med power pd source pse priority high value 5000

configure [ports ethX [,...]] dot3 power pse | pd [supported] [enabled] [paircontrol] powerpairs powerpairs [class class] [type type source source priority priority requested requested allocated allocated]

Advertise Dot3 POE-MDI TLV for the given port or for all ports if none was provided. One can act as a PD (power consumer) or a PSE (power provider). This configuration is distinct from the configuration of the transmission of the LLDP-MED POE-MDI TLV but the user should ensure the coherency of those two configurations if they are used together. supported means that MDI power is supported on the given port while enabled means that MDI power is enabled. paircontrol is used to indicate whether pair selection can be controlled. Valid values for powerpairs are:

signal

The signal pairs only are in use.

spare

The spare pairs only are in use.

When specified, class is class-, suffixed with a number from 0 to 4. E.g. class-0, class-1, class-2, class-3, class-4.

For 802.3at, the classes are as follows:

0

Default (Unspecified), PD 0.44-12.95 W, PSE 15.4 W

1

Very Low Power Device, PD 0.44-3.84 W, PSE 4.0 W

2

Low Power Device, PD 3.84-6.49 W, PSE 7.0 W

3

Mid Power Device, PD 6.49-12.95 W, PSE 15.4 W

4

High Power Device (PoE+), PD 12.95-25.5 W, PSE 30.0 W

The remaining parameters are in conformance with 802.3at and are optional. type should be either 1 or 2, indicating whether the device conforms to 802.3at type 1 or 802.3at type 2. Values of source and priority are the same as for LLDP-MED POE-MDI TLV. requested and allocated are expressed in milliwats.

Here are two valid uses of this command:

configure ports eth3 dot3 power pse supported enabled paircontrol powerpairs spare class class-3

configure dot3 power pd supported enabled powerpairs spare class class-3 type 1 source pse priority low requested 10000 allocated 15000

pause

Pause lldpd operations. lldpd will not send or receive any more frames. This can be undone with resume command. This only works interactively as lldpd asks lldpcli to unpause after reading the configuration file.

resume

Resume lldpd operations. lldpd will start to send and receive frames. This command is issued internally after processing the configuration but can be used at any time if a manual pause command is issued.

## FILES
/run/lldpd/lldpd.socket

Unix-domain socket used for communication with lldpd(8).

## SEE ALSO
lldpd(8)

## AUTHORS
The lldpcli program was written by Vincent Bernat ⟨bernat@luffy.cx⟩.


lldpd

title: lldpd(8)

summary: LLDP daemon

text:
# lldpd(8)

## NAME
lldpd — LLDP daemon

## SYNOPSIS
lldpd

[-dxcseiklrv] [-D debug] [-p pidfile] [-S description] [-P platform] [-X socket] [-m management] [-u file] [-I interfaces] [-C interfaces] [-M class] [-H hide] [-L lldpcli] [-O configfile]

## DESCRIPTION
lldpd is a daemon able to receive and send LLDP frames. The Link Layer Discovery Protocol is a vendor-neutral Layer 2 protocol that allows a network device to advertise its identity and capabilities on the local network.

lldpd also implements an SNMP subagent using AgentX protocol to interface to a regular SNMP agent like Net-SNMP. To enable this subagent, you need something like that in your snmpd.conf(5):

```
master agentx
```

This daemon implements both reception and sending. It will collect various information to send LLDP frames to all Ethernet interfaces, including management address, speed and VLAN names.

The options are as follows:

-d

Do not daemonize. If this option is specified, lldpd will run in the foreground. When specified one more time, lldpd will not log to syslog but only to stderr. Then, this option can be specified many times to increase verbosity. When specified four times, debug logs will be enabled. They can be filtered with -D flag.

-D debug

This option allows the user to filter out debugging information by specifying allowed tokens. This option can be repeated several times to allow several tokens. This option must be combined with the -d flag to have some effect. Only debugging logs can be filtered. Here is a list of allowed tokens with their description: main

Main daemon.

interfaces

Discovery of local interfaces.

lldp

LLDP PDU encoding/decoding.

edp

EDP PDU encoding/decoding.

cdp

CDP/FDP PDU encoding/decoding.

sonmp

SONMP PDU encoding/decoding.

event

Events management.

libevent

Events management but for logs generated by libevent.

privsep

Privilege separation.

localchassis

Retrieval of information related to the local chassis.

rpc

Client communication.

control

Management of the Unix control socket.

snmp

SNMP subagent.

libsnmp

SNMP subagent but for logs generated by NetSNMP.

decode

Generic PDU decoding.

marshal

Low-level serialization mechanisms.

alloc

Low-level allocation mechanisms.

send

Sending PDU to some interface.

receive

Receiving PDU from some interface.

loop

Main loop.

smartfilter

Smart filtering of different protocols on the same port.

netlink

Netlink subsystem.

-p pidfile

Use the provided PID file to record lldpd PID instead of /run/lldpd.pid.

-k

Disable advertising of kernel release, version and machine. Kernel name (ie: Linux) will still be shared, and Inventory software version will be set to 'Unknown'.

-S description

Override system description with the provided description. The default description is the kernel name, the node name, the kernel version, the build date and the architecture (except if you use the -k flag described above).

-P platform

Override the CDP platform name with the provided value. The default description is the kernel name (Linux).

-x

Enable SNMP subagent. With this option, lldpd will enable an SNMP subagent using AgentX protocol. This allows you to get information about the local system and remote systems through SNMP.

-X socket

Enable SNMP subagent using the specified socket. lldpd will enable an SNMP subagent using AgentX protocol for the given socket. This option implies the previous one. The default socket is usually /var/agentx/master. You can specify a socket like tcp:127.0.0.1:705 for example. Since the process that will open this socket is enclosed in a chroot, you need to specify an IP address (not a hostname) when using a TCP or UDP socket.

-c

Enable the support of CDP protocol to deal with Cisco routers that do not speak LLDP. If repeated, CDPv1 packets will be sent even when there is no CDP peer detected. If repeated once again, CDPv2 packets will be sent even when there is no CDP peer detected. If repeated once again (i.e. -cccc), CDPv1 will be disabled and CDPv2 will be enabled. If repeated once again (i.e. -ccccc), CDPv1 will be disabled and CDPv2 will be forced.

-f

Enable the support of FDP protocol to deal with Foundry routers that do not speak LLDP. If repeated, FDP packets will be sent even when there is no FDP peer detected.

-s

Enable the support of SONMP protocol to deal with Nortel routers and switches that do not speak LLDP. If repeated, SONMP packets will be sent even when there is no SONMP peer detected.

-e

Enable the support of EDP protocol to deal with Extreme routers and switches that do not speak LLDP. If repeated, EDP packets will be sent even when there is no EDP peer detected.

-l

Force to send LLDP packets even when there is no LLDP peer detected but there is a peer speaking another protocol detected. By default, LLDP packets are sent when there is a peer speaking LLDP detected or when there is no peer at all. If repeated, LLDP is disabled.

-r

Receive-only mode. With this switch, lldpd will not send any frame. It will only listen to neighbors.

-m management

Specify the management addresses of this system. As for interfaces (described below), this option can use wildcards and inversions. Without this option, the first IPv4 and the first IPv6 are used. If an exact IP address is provided, it is used as a management address without any check. If only negative patterns are provided, only one IPv4 and one IPv6 addresses are chosen. Otherwise, many of them can be selected. If you want to remove IPv6 addresses, you can use !*:*. If an interface name is matched, the first IPv4 address and the first IPv6 address associated to this interface will be chosen.

-u file

Specify the Unix-domain socket used for communication with lldpctl(8).

-I interfaces

Specify which interface to listen upon and send LLDPDU from. Without this option, lldpd will use all available physical interfaces. This option can use wildcards. Several interfaces can be specified separated by commas. It is also possible to remove an interface by prefixing it with an exclamation mark. It is possible to allow an interface by prefixing it with two exclamation marks. An allowed interface beats a forbidden interface which beats a simple matched interface. For example, with eth*,!eth1,!eth2 lldpd will only use interfaces starting with eth with the exception of eth1 and eth2. While with *,!eth*,!!eth1 lldpd will use all interfaces, except interfaces starting with eth with the exception of eth1. When an exact match is found, it will circumvent some tests. For example, if eth0.12 is specified, it will be accepted even if this is a VLAN interface.

-C interfaces

Specify which interfaces to use for computing chassis ID. Without this option, all interfaces are considered. lldpd will take the first MAC address from all the considered interfaces to compute the chassis ID. The logic of this option is the same as for -I flag: you can exclude interfaces with an exclamation mark and use globbing to specify several interfaces. If all interfaces are removed (with !*), the system name is used as a chassis ID instead.

-M class

Enable emission of LLDP-MED frames. Depending on the selected class, the standard defines which set of TLV should be transmitted. See section 10.2.1. Some devices may be strict in this aspect. The class should be one of the following values: 1

Generic Endpoint (Class I)

2

Media Endpoint (Class II). In this case, the standard requires to define at least one network policy via lldpcli.

3

Communication Device Endpoints (Class III). In this case, the standard requires to define at least one network policy via lldpcli.

4

Network Connectivity Device

-i

Disable LLDP-MED inventory TLV transmission. lldpd will still receive (and publish using SNMP if enabled) those LLDP-MED TLV but will not send them. Use this option if you don't want to transmit sensitive information like serial numbers.

-H hide

Filter neighbors. See section FILTERING NEIGHBORS for details.

-L lldpcli

Provide an alternative path to lldpcli for configuration. If empty, does not use lldpcli for configuration.

-O configfile

Override default configuration locations processed by lldpcli at start. If a directory is provided, each file therein suffixed with .conf. will be read. Order is alphabetical.

-v

Show lldpd version. When repeated, show more build information.

## FILTERING NEIGHBORS
In a heterogeneous network, you may see several different hosts on the same port, even if there is only one physically plugged to this port. For example, if you have a Nortel switch running LLDP which is plugged to a Cisco switch running CDP and your host is plugged to the Cisco switch, you will see the Nortel switch as well because LLDP frames are forwarded by the Cisco switch. This may not be what you want. The -H hide parameter allows you to tell lldpd to discard some frames that it receives and to avoid sending some other frames.

Incoming filtering and outgoing filtering are unrelated. Incoming filtering will hide some remote ports to give you a chance to know exactly what equipment is on the other side of the link. Outgoing filtering will avoid using some protocols to avoid flooding your network with a protocol that is not handled by the nearest equipment. Keep in mind that even without filtering, lldpd will speak protocols for which at least one frame has been received and LLDP otherwise (there are other options to change this behaviour, for example -cc, -ss, -ee, -ll and -ff ).

When enabling incoming filtering, lldpd will try to select one protocol, and filter out neighbors using other protocols. To select this protocol, the rule is to take the less used protocol. If on one port, you get 12 CDP neighbors and 1 LLDP neighbor, this means that the remote switch speaks LLDP and does not filter CDP. Therefore, we select LLDP. When enabling outgoing filtering, lldpd will also try to select one protocol and only speak this protocol. The filtering is done per port. Each port may select a different protocol.

There are two additional criteria when enabling filtering: allowing one or several protocols to be selected (in case of a tie) and allowing one or several neighbors to be selected. Even when allowing several protocols, the rule of selecting the protocols with the fewest neighbors still applies. If lldpd selects LLDP and CDP, this means they have the same number of neighbors. The selection of the neighbor is random. Incoming filtering will select a set of neighbors to be displayed while outgoing filtering will use the selected set of neighbors to decide which protocols to use: if a selected neighbor speaks LLDP and another one CDP, lldpd will speak both CDP and LLDP on this port.

There are some corner cases. A typical example is a switch speaking two protocols (CDP and LLDP for example). You want to get the information from the best protocol but you want to speak both protocols because some tools use the CDP table and some other the LLDP table.

The table below summarizes all accepted values for the -H hide parameter. The default value is 15 which corresponds to the corner case described above. The filter column means that filtering is enabled. The 1proto column tells that only one protocol will be kept. The 1neigh column tells that only one neighbor will be kept.

incoming

outgoing

filter

1proto

1neigh

filter

1proto

1neigh

0

1

x

x

x

x

2

x

x

3

x

x

4

x

x

5

x

6

x

7

x

x

x

x

x

8

x

x

x

9

x

x

x

x

10

x

x

11

x

x

12

x

x

x

x

13

x

x

x

14

x

x

x

x

15

x

x

x

16

x

x

x

x

x

17

x

x

x

x

18

x

x

x

19

x

x

x

## FILES
/run/lldpd/lldpd.socket

Unix-domain socket used for communication with lldpctl(8).

/etc/lldpd.conf

Configuration file for lldpd. Commands in this files are executed by lldpcli(8) at start.

/etc/lldpd.d

Directory containing configuration files whose commands are executed by lldpcli(8) at start.

## SEE ALSO
lldpctl(8), lldpcli(8), snmpd(8)

## HISTORY
The lldpd program is inspired from a preliminary work of Reyk Floeter.

## AUTHORS
The lldpd program was written by Pierre-Yves Ritschard ⟨pyr@openbsd.org⟩, and Vincent Bernat ⟨bernat@luffy.cx⟩.


lltdscan

package: lltdscan

title: lltdscan(8)

text:
# lltdscan(8)

## NAME
lltdscan - scan for LLTD-enabled hosts on a network interface.

## SYNOPSIS
lltdscan [-i iface] [-t timeout] [-u] [-v] [-v] [aa:bb:cc:dd:ee:ff]

## DESCRIPTION
The lltdscan utility sends broadcast LLTD request on specified (or default) interface. And then listens for timeout milliseconds for responses.

Add one or two -v options to increase verbosity.

Add -u option to show machine names in UTF-8.

Also you can specify exactly one MAC address as last argument - and lltdscan will exit as soon as it receives first reply from specified host.

## LLTD PROTOCOL
LLTD stands for "Link Layer Topology Discovery".

Protocol specs are available from Microsoft at http://www.microsoft.com/whdc/connect/Rally/LLTD-spec.mspx

## SEE ALSO
ping(8), arp(8), arping(8)

## AVAILABILITY
Check for latest versions at http://github.com/zed-0xff/lltdscan

And feel free to visit my personal technical blog at http://zed.0xff.me/ for more fun & useful tools and patches :)

## AUTHOR
Andrey Zaikin <zed.0xff@gmail.com>.


sensors-detect

title: sensors-detect(8)

summary: detect hardware monitoring chips

text:
# sensors-detect(8)

## NAME
sensors-detect - detect hardware monitoring chips

## SYNOPSIS
sensors-detect [ --auto ]

## DESCRIPTION
sensors-detect is an interactive program that will walk you through the process of scanning your system for various hardware monitoring chips, or sensors, supported by libsensors(3), or more generally by the lm_sensors tool suite.

sensors-detect will look for the following devices, in order:

- Sensors embedded in CPUs, south bridges and memory controllers.

- Sensors embedded in Super I/O chips.

- Hardware monitoring chips accessed through ISA I/O ports.

- Hardware monitoring chips reachable over the SMBus or more generally any I2C bus on your system.

As the last two detection steps can cause trouble on some systems, they are normally not attempted if the second detection step led to the discovery of a Super I/O chip with complete hardware monitoring features. However, the user is always free to ask for all detection steps if so is his/her wish. This can be useful if a given system has more than one hardware monitoring chip. Some vendors are known to do this, most notably Asus and Tyan.

## OPTIONS
--auto

Run in automatic, non-interactive mode. Assume default answers to all questions. Note that this isn't necessarily safe as the internal logic may lead to potentially dangerous probes being attempted. See the WARNING section below.

--stat

Display I2C address statistics.

## WARNING
sensors-detect needs to access the hardware for most of the chip detections. By definition, it doesn't know which chips are there before it manages to identify them. This means that it can access chips in a way these chips do not like, causing problems ranging from SMBus lockup to permanent hardware damage (a rare case, thankfully.)

The authors made their best to make the detection as safe as possible, and it turns out to work just fine in most cases, however it is impossible to guarantee that sensors-detect will not lock or kill a specific system. So, as a rule of thumb, you should not run sensors-detect on production servers, and you should not run sensors-detect if can't afford replacing a random part of your system. Also, it is recommended to not force a detection step which would have been skipped by default, unless you know what you are doing.

## SEE ALSO
sensors(1), libsensors(3)

## AUTHOR
Frodo Looijaard and Jean Delvare


fancontrol

title: fancontrol(8)

text:
# fancontrol(8)

## NAME
fancontrol - automated software based fan speed regulation

## SYNOPSIS
fancontrol [configfile]

## DESCRIPTION
fancontrol is a shell script for use with lm_sensors. It reads its configuration from a file, then calculates fan speeds from temperatures and sets the corresponding PWM outputs to the computed values.

## WARNING
Please be careful when using the fan control features of your mainboard, in addition to the risk of burning your CPU, at higher temperatures there will be a higher wearout of your other hardware components, too. So if you plan to use these components in 50 years, maybe you shouldn't use fancontrol at all. Also please keep in mind most fans aren't designed to be powered by a PWMed voltage.

In practice it doesn't seem to be a major issue, the fans will get slightly warmer, just be sure to have a temperature alarm and/or shutdown call, in case some fan fails, because you probably won't hear it anymore ;)

## CONFIGURATION
For easy configuration, there's a script named pwmconfig(8) which lets you interactively write your configuration file for fancontrol. Alternatively you can write this file yourself using the information from this manpage.

Since most of you are going to use pwmconfig(8) script, the config file syntax will be discussed last. First I'm going to describe the various variables available for changing fancontrol's behaviour:

INTERVAL

This variable defines at which interval in seconds the main loop of fancontrol will be executed

DEVPATH

Maps hwmon class devices to physical devices. This lets fancontrol check that the configuration file is still up-to-date.

DEVNAME

Records hwmon class device names. This lets fancontrol check that the configuration file is still up-to-date.

FCTEMPS

Maps PWM outputs to temperature sensors so fancontrol knows which temperature sensors should be used for calculation of new values for the corresponding PWM outputs. A prefix of ! can be used to execute a command as a temperature sensor.

FCFANS

Records the association between a PWM output and a fan input. Then fancontrol can check the fan speed and restart it if it stops unexpectedly.

MINTEMP

The temperature below which the fan gets switched to minimum speed.

MAXTEMP

The temperature over which the fan gets switched to maximum speed.

MINSTART

Sets the minimum speed at which the fan begins spinning. You should use a safe value to be sure it works, even when the fan gets old.

MINSTOP

The minimum speed at which the fan still spins. Use a safe value here, too.

MINPWM

The PWM value to use when the temperature is below MINTEMP. Typically, this will be either 0 if it is OK for the fan to plain stop, or the same value as MINSTOP if you don't want the fan to ever stop. If this value isn't defined, it defaults to 0 (stopped fan).

MAXPWM

The PWM value to use when the temperature is over MAXTEMP. If this value isn't defined, it defaults to 255 (full speed).

AVERAGE

How many last temperature readings are used to average the temperature. It can be used to smoothen short temperature peaks. If this value isn't defined, it defaults to 1 (no averaging).

The configuration file format is a bit strange:

```
VARIABLE=chip/pwmdev=value chip/pwmdev2=value2
VARIABLE2=...
```

Each variable has its own line. The variable name is followed by an equal sign and the device=value pairs. These consist of the path to the pwm output for which the value is valid, equal sign followed by the value and are separated by a blank. Path can be absolute or relative (from /sys/bus/i2c/devices or /sys/class/hwmon depending on the kernel version). Example:

MINTEMP=hwmon0/device/pwm1=40 hwmon0/device/pwm2=54

You have to play with the temperature values a bit to get happy. For initial setup I recommend using the pwmconfig script. Small changes can be made by editing the config file directly following the rules above.

Upon starting, fancontrol will make sure that all referenced devices do exist and match what they were at configuration time, and that all referenced sysfs files do exist. If not, it will quit immediately, upon the assumption that the configuration file may be out-of-sync with the loaded kernel drivers.

## THE ALGORITHM
fancontrol first reads its configuration, writes it to arrays and loops its main function. This function gets the temperatures and fanspeeds from kernel driver files and calculates new speeds depending on temperature changes, but only if the temp is between MINTEMP and MAXTEMP. After that, the new values are written to the PWM outputs. Currently the speed increases linearly with rising temperature. This way you won't hear your fans most of the time at best.

## SEE ALSO
pwmconfig(8), sensors(1).

## AUTHOR
Marius Reiner <marius.reiner@hdev.de>


isadump

title: isadump(8)

summary: examine ISA registers

text:
# isadump(8)

## NAME
isadump - examine ISA registers

## SYNOPSIS
isadump [-y] [-W|-L] [-k V1,V2...] addrreg datareg [bank [bankreg]] #for I2C-like access

isadump -f [-y] [-W|-L] address [range [bank [bankreg]]] #for flat address space

## DESCRIPTION
isadump is a small helper program to examine registers visible through the ISA bus. It is intended to probe any chip that lives on the ISA bus working with an address register and a data register (I2C-like access) or a flat range (of up to 256 bytes).

## OPTIONS
-f

Enable flat address space mode.

-y

Disable interactive mode. By default, isadump will wait for a confirmation from the user before messing with the ISA bus. When this flag is used, it will perform the operation directly. This is mainly meant to be used in scripts.

-k V1,V2...

Specify a comma-separated list of bytes to send as the key sequence to enter the chip configuration mode. Most Super-I/O chips need this. Known key sequences are: 0x87,0x01,0x55,0x55 for ITE, 0x55 for SMSC, 0x87,0x87 for Winbond and VIA, none needed for National Semiconductor.

-W

Perform 16-bit reads.

-L

Perform 32-bit reads.

## OPTIONS (I2C-like access mode)
At least two options must be provided to isadump. addrreg contains the ISA address of the address register for the chip to probe; datareg contains the address of the data register. Both addresses are integers between 0x0000 and 0x3FFF. Usually, if the chip's base address is 0x0nn0, the address register is at 0x0nn5 and the data register is at 0x0nn6. The most common base address for hardware monitoring chips is 0x0290.

For Super-I/O chips, address register is typically at 0x2E with data register at 0x2F.

The bank and bankreg parameters are useful on the Winbond chips as well as on Super-I/O chips. bank is an integer between 0 and 31, and bankreg is an integer between 0x00 and 0xFF (default value: 0x4E for Winbond chips, 0x07 for Super-I/O chips). The W83781D datasheet has more information on bank selection.

## OPTIONS (flat address space mode)
In flat mode, only one parameter is mandatory. address contains the ISA address of the chip to probe; it is an integer between 0x0000 and 0xFFFF. If provided, range is how many bytes should be read (must be a multiple of 16). If the range isn't provided, it defaults to 256 bytes and the address is forcibly aligned on a 256-byte boundary.

The bank and bankreg parameters are useful on the National Semiconductor PC87365 and PC87366 Super-I/O chips. bank is an integer between 0 and 31, and bankreg is an integer between 0x00 and 0xFF (default value: 0x09; must fit in the specified range). See the PC87365 datasheet for more information on bank selection.

## NOTES
If no bank is specified, no bank change operation is performed.

If a bank is specified, the original value is restored before isadump exits.

Dumping Super-I/O chips is typically a two-step process. First, you will have to access the main Super-I/O address using a command like: isadump 0x2e 0x2f 0x09. This will select logical device 9 (correct value depend on the chip). At 0x60 you will find the logical device address word, for example "ec c0". Then you can use a command like: isadump -f 0xecc0 16. This will dump the logical device registers. The correct range depends on the chip.

## WARNING
Poking around in ISA data space is extremely dangerous. Running isadump with random parameters can cause system crashes, data loss, and worse! Be extremely careful when using this program.

## SEE ALSO
i2cdump(8), isaset(8)

## AUTHOR
Frodo Looijaard, Mark D. Studebaker, and the lm_sensors group (https://hwmon.wiki.kernel.org/lm_sensors)

This manual page was originally written by David Z Maze <dmaze@debian.org> for the Debian GNU/Linux system. It was then reviewed and augmented by the lm_sensors team and is now part of the lm_sensors source distribution.


isaset

title: isaset(8)

summary: set ISA registers

text:
# isaset(8)

## NAME
isaset - set ISA registers

## SYNOPSIS
isaset [-y] [-W|-L] addrreg datareg address value [mask] #for I2C-like access

isaset -f [-y] [-W|-L] address value [mask] #for flat address space

## DESCRIPTION
isaset is a small helper program to set registers visible through the ISA bus.

## OPTIONS
-f

Enable flat address space mode.

-y

Disable interactive mode. By default, isaset will wait for a confirmation from the user before messing with the ISA bus. When this flag is used, it will perform the operation directly. This is mainly meant to be used in scripts.

-W

Perform a 16-bit write.

-L

Perform a 32-bit write.

## OPTIONS (I2C-like access mode)
Four options must be provided to isaset. addrreg contains the ISA address of the address register for the chip to probe; datareg contains the address of the data register. Both addresses are integers between 0x0000 and 0x3FFF. Usually, if the chip's base address is 0x0nn0, the address register is at 0x0nn5 and the data register is at 0x0nn6. The most common base address for hardware monitoring chips is 0x0290. For Super-I/O chips, address register is typically at 0x2E with data register at 0x2F. The address and value parameters are two integers between 0x00 and 0xFF. isaset will write value value to address address. An optional mask can be provided as a fifth parameter, preserving unmasked bits at the written location.

## OPTIONS (flat address space mode)
In flat mode, two parameters must be provided. address contains the ISA address of the register to write to; it is an integer between 0x0000 and 0xFFFF. Basically, it is the sum of the chip's base address and the chip register's address. isaset will write value value at this address. An optional mask can be provided as a third parameter, preserving unmasked bits at the written location.

## WARNING
Poking around in ISA data space is extremely dangerous. Running isaset with random parameters can cause system crashes, data loss, and worse! Be extremely careful when using this program.

## SEE ALSO
i2cset(8), isadump(8)

## AUTHOR
Mark D. Studebaker, and the lm_sensors group (https://hwmon.wiki.kernel.org/lm_sensors)

This manual page was shamelessly ripped from the i2cset and isadump manual pages by Jean Delvare.


pwmconfig

title: pwmconfig(8)

text:
# pwmconfig(8)

## NAME
pwmconfig - tests the PWM outputs of sensors and configures fancontrol

## SYNOPSIS
pwmconfig

## WARNING
pwmconfig will attempt to stop your fans, one at a time, for approximately 5 seconds each. This may cause your processor temperature to rise. Verify that all fans are running at normal speed after this program has exited. pwmconfig does its best to check that the fans are spinning when they are supposed to, but due to the diversity of available motherboards and fans, it shouldn't be blindly trusted. Always verify by yourself.

It is strongly recommended to run pwmconfig at a time when there is no significant system load, to minimize the risk of overheating.

## DESCRIPTION
pwmconfig searches your sensors for pulse width modulation (PWM) controls, and tests each one to see if it controls a fan on your motherboard. Note that many motherboards do not have PWM circuitry installed, even if your sensor chip supports PWM.

When a connection is established between a PWM control and a fan, pwmconfig can generate a detailed correlation, to show how a given fan is responding to various PWM duty cycles.

Lastly, pwmconfig will enter in fancontrol configuration mode (unless you decide to skip that part.) In this mode, you are invited to enter several parameters which will determine how the fancontrol daemon regulates the speed of one or more fans in your system based on temperature measurements. In particular, you will have the opportunity to establish mappings between fans and temperature inputs, define the temperature range over which the speed of the fan should be adjusted dynamically, the minimum speed at which the fan should spin, etc. See fancontrol(8) for additional information.

## BUGS
The term "PWM" is used because most fan control systems in computers are based on pulse width modulation. Some motherboards however use DC variation instead. So, the term "PWM" should be seen as a generic term for "fan speed control", regardless of the actual method used.

## SEE ALSO
fancontrol(8), sensors(1).

## AUTHORS
Marius Reiner <marius.reiner@hdev.de>, Jean Delvare <jdelvare@suse.de>


sensord

title: sensord(8)

summary: Sensor information logging daemon.

text:
# sensord(8)

## NAME
sensord - Sensor information logging daemon.

## SYNOPSIS
sensord [ options ] [ chips ]

## DESCRIPTION
Sensord is a daemon that can be used to periodically log sensor readings from hardware health-monitoring chips to syslog(3) or a round-robin database (RRD) and to alert when a sensor alarm is signalled; for example, if a fan fails, a temperature limit is exceeded, etc.

## OPTIONS
-i, --interval time

Specify the interval between scanning for sensor alarms; the default is to scan every minute. The time should be specified as a raw integer (seconds) or with a suffix `s' for seconds, `m' for minutes or `h' for hours; for example, the default interval is `60' or `1m'.

Specify an interval of zero to suppress scanning explicitly for alarms.

-l, --log-interval time

Specify the interval between logging all sensor readings; the default is to log all readings every half hour. The time is specified as before; e.g., `30m'.

Specify an interval of zero to suppress logging of regular sensor readings.

-1, --oneline

Log sensor value, chip, and adapter on one line for easier parsing.

-t, --rrd-interval time

Specify the interval between logging all sensor readings to a round-robin database; the default is to log all readings every five minutes if a round-robin database is configured. The time is specified as before; e.g., `5m'.

-T, --rrd-no-average

Specify that the round-robin database should not be averaged.

-r, --rrd-file file

Specify a round-robin database into which to log all sensor readings; e.g., `/var/log/sensord.rrd'. This database will be created if it does not exist. By default, no round-robin database is used. See the section ROUND ROBIN DATABASES below for more details.

-c, --config-file file

Specify a libsensors(3) configuration file. If no file is specified, the libsensors default configuration file is used.

-p, --pid-file file

Specify what PID file to write; the default is to write the file `/run/sensord.pid'. You should always specify an absolute path here. The file is removed when the daemon exits.

-f, --syslog-facility facility

Specify the syslog(3) facility to use when logging sensor readings and alarms; the default is to use daemon. Other possible facilities include local0 through local7, and user.

-g, --rrd-cgi directory

Prints out a sample rrdcgi(1) CGI script that can be used to display graphs of recent sensor information in a Web page, and exits. You must specify the world-writable, Web-accessible directory where the graphs should be stored; the CGI script assumes that this will be accessed under the `/sensord/' directory on the Webserver. See the section ROUND ROBIN DATABASES below for more details.

-a, --load-average

Include the load average in the RRD database. You should also specify this flag when you create the CGI script.

-d, --debug

Prints a small amount of additional debugging information.

-h, --help

Prints a help message and exits.

-v, --version

Displays the program version and exits.

## CHIPS
To restrict the devices that are scanned by this daemon, you may optionally specify a list of chip names. By default, all available chips are scanned.

A typical chip name would be `w83782d-*' (you may want to escape the `*' for your shell) which would scan any W83782D chips on any bus. See sensors.conf(5) for more details. Another option is to simply not load the sensor modules for chips in which you have no interest.

## SIGNALS
Upon receipt of a SIGTERM (see signal(7) for details) this daemon should gracefully shut down.

Upon receipt of a SIGHUP, this daemon will rescan the kernel interface for chips and features, and reload the libsensors configuration file.

## LOGGING
All messages from this daemon are logged to syslog(3) under the program name `sensord' and facility daemon, or whatever is specified on the command line.

Regular sensor readings are logged at the level info. Alarms are logged at the level alert. Inconsequential status messages are logged at the minimum level, debug, when debugging is enabled.

You can use an appropriate `/etc/syslog.conf' file to direct these messages in a useful manner. See syslog.conf(5) for full details. Assuming you set the logging facility to local4, the following is a sample configuration:

```
# Sample syslog.conf entries
*.info;...;local4.none;local4.warn  /var/log/messages
local4.info                        -/var/log/sensors
local4.alert                        /dev/console
local4.alert                        *
```

The first line ensures that regular sensor readings do not clutter `/var/log/messages'; we first say `local4.none' to eliminate informational messages; then `local4.warn' to enable warnings and above. The second line says to log all regular sensor readings to `/var/log/sensors'; the leading hyphen `-' means that this file is not flushed after every message. The final two lines ensure that alarms are printed to the system console as well as to all connected users (in addition to `/var/log/messages' and `/var/log/sensors').

## LOG ROTATION
On a typical system with a good sensor chip, expect about 2KB per sensor reading in the log file. This works out at about 3MB per month. You should be rotating your syslog files anyway, but just to be sure you'll want to use something like logrotate(8) or equivalent. You might, for example, want an entry in `/etc/logrotate.d/syslog' containing:

```
# Sample logrotate.d entry
/var/log/sensors {

    postrotate

        /usr/sbin/killall -HUP syslogd

    endscript
}
```

Note, of course, that you want to restart syslogd(8) and not sensord(8)

## ALARMS
Alarms generally indicate a critical condition; for example, a fan failure or an unacceptable temperature or voltage. However, some sensor chips do not support alarms, while others are incorrectly configured and may signal alarms incorrectly.

Note that some drivers may lack support for alarm reporting even though the chips they support do have alarms. As of Linux 2.6.23, many drivers still don't report alarms in a format suitable for libsensors 3.

## BEEPS
If you see `(beep)' beside any sensor reading, that just means that your system is configured to issue an audio warning from the motherboard if an alarm is signalled on that sensor.

## ROUND ROBIN DATABASES
Sensord(8) provides support for storing sensor readings in a round-robin database. This may be a useful alternative to the use of syslog(3).

Round-robin databases are constant-size databases that can be used to store, for example, a week's worth of sensor readings. Subsequent readings stored in the database will overwrite readings that are over a week old. This capability is extremely useful because it allows useful information to be stored in an easily-accessible manner for a useful length of time, without the burden of ever-growing log files.

The rrdtool(1) utility and its associated library provide the basic framework for the round-robin database beneath sensord(8). In addition, the rrdcgi(1) and rrdgraph(1) utilities provide support for generating graphs of these data for display in a Web page.

If you wish to use the default configuration of round-robin database, which holds one week of sensor readings at five-minute intervals, then simply start sensord(8) and specify where you want the database stored. It will automatically be created and configured using these default parameters.

If you wish readings to be stored for a longer period, or want multiple readings to be averaged into each database entry, then you must manually create and configure the database before starting sensord(8). Consult the rrdcreate(1) manual for details. Note that the database must match exactly the names and order of sensors read by sensord(8). It is recommended that you create the default database and then use rrdinfo(1) to obtain this information, and/or rrdtune(1) to change it.

After creating the round-robin database, you must then configure your Web server to display the sensor information. This assumes that you have a Web server preconfigured and functioning on your machine. Sensord(8) provides a command-line option --rrd-cgi to generate a basic CGI script to display these graphs; you can then customize this script as desired. Consult the rrdcgi(1) manual for details. This CGI script requires a world-writable, Web-accessible directory into which to write the graphs that it generates.

An example of how to set up Web-accessible graphs of recent sensor readings follows:

```
sensord --log-interval 0 \

  --load-average \

  --rrd-file /var/log/sensord.rrd
```

Here, we start sensord(8) and configure it to store readings in a round-robin database; note that we disable logging of sensor readings to syslog(3), and enable logging of the load average.

```
mkdir /var/www/sensord
chown www-data:staff /var/www/sensord
chmod a=rwxs /var/www/sensord
```

Here, we create a world-writable, Web-accessible directory in which graphs will be stored; we set the ownership and permissions on this directory appropriately. You will have to determine the location and ownership that is appropriate for your machine.

```
sensord --load-average \

  --rrd-file /var/log/sensord.rrd \

  --rrd-cgi /var/www/sensord \

  > /usr/lib/cgi-bin/sensord.cgi
chmod a+rx /usr/lib/cgi-bin/sensord.cgi
```

Here, we create a CGI script that will display sensor readings from the database. You must specify the location of the round-robin database, the location of the directory where the images should be stored, and whether you want the load average displayed. The --rrd-cgi command-line parameter causes sensord(8) to display a suitable CGI script on stdout and then to exit. You will need to write this script to the CGI bin directory of your Web server, and edit the script if the image directory you chose is not the `/sensord/' directory of your Web server.

Finally, you should be able to view your sensor readings from the URL `http://localhost/cgi-bin/sensord.cgi'.

## MODULES
It is expected that all required sensor modules are loaded prior to this daemon being started. This can either be achieved with a system specific module loading scheme (e.g., listing the required modules in the file `/etc/modules' under Debian) or with explicit modprobe(1) commands in an init script before loading the daemon.

For example, a `sensord' initialization script might contain (among others) the following commands:

```
# Sample init.d scriptlet
echo -n "Loading AMD756 module: "
modprobe i2c-amd756 || { echo Fail. ; exit 1 ; }
echo OK.
echo -n "Loading W83781D module: "
modprobe w83781d || { echo Fail. ; exit 1 ; }
echo OK.
echo -n "Starting sensord: "
daemon sensord
```

Ignore the platform-specific shell functions; the general idea should be fairly clear.

## ERRORS
Errors encountered by this daemon are logged to syslogd(8) after which the daemon will exit.

## BUGS
Round-robin database support doesn't cope with multiple sensor chips having duplicate sensor labels.

## FILES
/etc/sensors3.conf

/etc/sensors.conf

The system-wide libsensors(3) configuration file. See sensors.conf(5) for further details.

/etc/syslog.conf The system-wide syslog(3) / syslogd(8) configuration file. See syslog.conf(5) for further details.

## SEE ALSO
sensors.conf(5)

## AUTHORS
Sensord was written by Merlin Hughes <merlin@merlin.org>. Basics of round-robin databases were misappropriated from Mark D. Studebaker.


sensors-conf-convert

title: sensors-conf-convert(8)

summary: sensors configuration conversion

text:
# sensors-conf-convert(8)

## NAME
sensors-conf-convert - sensors configuration conversion

## SYNOPSIS
sensors-conf-convert < /etc/sensors.conf > /etc/sensors3.conf

## DESCRIPTION
The purpose of the sensors-conf-convert tool is to convert sensors.conf from the lm_sensors version 2 format to the lm_sensors version 3 format.

The old configuration file is read from the standard input and the new one is written to the standard output.

## SEE ALSO
sensors(1), libsensors(3)

## AUTHOR
Jean Delvare


lmbench

package: lmbench

title: lmbench(8)

summary: system benchmarks

text:
# lmbench(8)

## NAME
lmbench - system benchmarks

## DESCRIPTION
lmbench is a series of micro benchmarks intended to measure basic operating system and hardware system metrics. The benchmarks fall into three general classes: bandwidth, latency, and ``other''.

Most of the lmbench benchmarks use a standard timing harness described in timing(3) and have a few standard options: parallelism, warmup, and repetitions. Parallelism specifies the number of benchmark processes to run in parallel. This is primarily useful when measuring the performance of SMP or distributed computers and can be used to evaluate the system's performance scalability. Warmup is the number of minimum number of microseconds the benchmark should execute the benchmarked capability before it begins measuring performance. Again this is primarily useful for SMP or distributed systems and it is intended to give the process scheduler time to "settle" and migrate processes to other processors. By measuring performance over various warmup periods, users may evaulate the scheduler's responsiveness. Repetitions is the number of measurements that the benchmark should take. This allows lmbench to provide greater or lesser statistical strength to the results it reports. The default number of repetitions is 11.

## BANDWIDTH MEASUREMENTS
Data movement is fundemental to the performance on most computer systems. The bandwidth measurements are intended to show how the system can move data. The results of the bandwidth metrics can be compared but care must be taken to understand what it is that is being compared. The bandwidth benchmarks can be reduced to two main components: operating system overhead and memory speeds. The bandwidth benchmarks report their results as megabytes moved per second but please note that the data moved is not necessarily the same as the memory bandwidth used to move the data. Consult the individual man pages for more information.

Each of the bandwidth benchmarks is listed below with a brief overview of the intent of the benchmark.

bw_file_rd

reading and summing of a file via the read(2) interface.

bw_mem_cp

memory copy.

bw_mem_rd

memory reading and summing.

bw_mem_wr

memory writing.

bw_mmap_rd

reading and summing of a file via the memory mapping mmap(2) interface.

bw_pipe

reading of data via a pipe.

bw_tcp

reading of data via a TCP/IP socket.

bw_unix

reading data from a UNIX socket.

## LATENCY MEASUREMENTS
Control messages are also fundemental to the performance on most computer systems. The latency measurements are intended to show how fast a system can be told to do some operation. The results of the latency metrics can be compared to each other for the most part. In particular, the pipe, rpc, tcp, and udp transactions are all identical benchmarks carried out over different system abstractions.

Latency numbers here should mostly be in microseconds per operation.

lat_connect

the time it takes to establish a TCP/IP connection.

lat_ctx

context switching; the number and size of processes is varied.

lat_fcntl

fcntl file locking.

lat_fifo

``hot potato'' transaction through a UNIX FIFO.

lat_fs

creating and deleting small files.

lat_pagefault

the time it takes to fault in a page from a file.

lat_mem_rd

memory read latency (accurate to the ~2-5 nanosecond range, reported in nanoseconds).

lat_mmap

time to set up a memory mapping.

lat_ops

basic processor operations, such as integer XOR, ADD, SUB, MUL, DIV, and MOD, and float ADD, MUL, DIV, and double ADD, MUL, DIV.

lat_pipe

``hot potato'' transaction through a Unix pipe.

lat_proc

process creation times (various sorts).

lat_rpc

``hot potato'' transaction through Sun RPC over UDP or TCP.

lat_select

select latency

lat_sig

signal installation and catch latencies. Also protection fault signal latency.

lat_syscall

non trivial entry into the system.

lat_tcp

``hot potato'' transaction through TCP.

lat_udp

``hot potato'' transaction through UDP.

lat_unix

``hot potato'' transaction through UNIX sockets.

lat_unix_connect

the time it takes to establish a UNIX socket connection.

## OTHER MEASUREMENTS
mhz

processor cycle time

tlb

TLB size and TLB miss latency

line

cache line size (in bytes)

cache

cache statistics, such as line size, cache sizes, memory parallelism.

stream

John McCalpin's stream benchmark

par_mem

memory subsystem parallelism. How many requests can the memory subsystem service in parallel, which may depend on the location of the data in the memory hierarchy.

par_ops

basic processor operation parallelism.

## SEE ALSO
bargraph(1), graph(1), lmbench(3), results(3), timing(3), bw_file_rd(8), bw_mem_cp(8), bw_mem_wr(8), bw_mmap_rd(8), bw_pipe(8), bw_tcp(8), bw_unix(8), lat_connect(8), lat_ctx(8), lat_fcntl(8), lat_fifo(8), lat_fs(8), lat_http(8), lat_mem_rd(8), lat_mmap(8), lat_ops(8), lat_pagefault(8), lat_pipe(8), lat_proc(8), lat_rpc(8), lat_select(8), lat_sig(8), lat_syscall(8), lat_tcp(8), lat_udp(8), lmdd(8), par_ops(8), par_mem(8), mhz(8), tlb(8), line(8), cache(8), stream(8)

## ACKNOWLEDGEMENT
Funding for the development of these tools was provided by Sun Microsystems Computer Corporation.

A large number of people have contributed to the testing and development of lmbench.

## COPYING
The benchmarking code is distributed under the GPL with additional restrictions, see the COPYING file.

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lmbench_bw_file_rd(8)

summary: time the reading and summing of a file

text:
# lmbench_bw_file_rd(8)

## NAME
bw_file_rd - time the reading and summing of a file

## SYNOPSIS
bw_file_rd [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size file

## DESCRIPTION
bw_file_rd times the read of the specified file in 64KB blocks. Each block is summed up as a seried of 4 byte integers in an unrolled loop. Results are reported in megabytes read per second.

The data is not accessed in the user program; the benchmark relies on the operating systems read interface to have actually moved the data. Systems that implement page flipping may fool this benchmark.

The benchmark is intended to be used on a file that is in memory, i.e., the benchmark is a reread benchmark. Other file benchmarking can be done with lmdd(8).

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %.2f\n", megabytes, megabytes_per_second, i.e.,

8.00 25.33

## MEMORY UTILIZATION
This benchmark can move up to three times the requested memory. Most Unix systems implement the read system call as a bcopy from kernel space to user space. Bcopy will use 2-3 times as much memory bandwidth: there is one read from the source and a write to the destionation. The write usually results in a cache line read and then a write back of the cache line at some later point. Memory utilization might be reduced by 1/3 if the processor architecture implemented ``load cache line'' and ``store cache line'' instructions (as well as ``getcachelinesize'').

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.