dhcpd.leases

title: dhcpd.leases(5)

text:
# dhcpd.leases(5)

## NAME
dhcpd.leases - DHCP client lease database

## DESCRIPTION
The Internet Systems Consortium DHCP Server keeps a persistent database of leases that it has assigned. This database is a free-form ASCII file containing a series of lease declarations. Every time a lease is acquired, renewed or released, its new value is recorded at the end of the lease file. So if more than one declaration appears for a given lease, the last one in the file is the current one.

When dhcpd is first installed, there is no lease database. However, dhcpd requires that a lease database be present before it will start. To make the initial lease database, just create an empty file called /var/lib/dhcp/dhcpd/state/dhcpd.leases. You can do this with:

```
	touch /var/lib/dhcp/dhcpd/state/dhcpd.leases
```

In order to prevent the lease database from growing without bound, the file is rewritten from time to time. First, a temporary lease database is created and all known leases are dumped to it. Then, the old lease database is renamed /var/lib/dhcp/dhcpd/state/dhcpd.leases~. Finally, the newly written lease database is moved into place.

In order to process both DHCPv4 and DHCPv6 messages you will need to run two separate instances of the dhcpd process. Each of these instances will need it's own lease file. You can use the -lf option on the server's command line to specify a different lease file name for one or both servers.

## FORMAT
Lease descriptions are stored in a format that is parsed by the same recursive descent parser used to read the dhcpd.conf(5) and dhclient.conf(5) files. Lease files can contain lease declarations, and also group and subgroup declarations, host declarations and failover state declarations. Group, subgroup and host declarations are used to record objects created using the OMAPI protocol.

The lease file is a log-structured file - whenever a lease changes, the contents of that lease are written to the end of the file. This means that it is entirely possible and quite reasonable for there to be two or more declarations of the same lease in the lease file at the same time. In that case, the instance of that particular lease that appears last in the file is the one that is in effect.

Group, subgroup and host declarations in the lease file are handled in the same manner, except that if any of these objects are deleted, a rubout is written to the lease file. This is just the same declaration, with { deleted; } in the scope of the declaration. When the lease file is rewritten, any such rubouts that can be eliminated are eliminated. It is possible to delete a declaration in the dhcpd.conf file; in this case, the rubout can never be eliminated from the dhcpd.leases file.

## COMMON STATEMENTS FOR LEASE DECLARATIONS
While the lease file formats for DHCPv4 and DHCPv6 are different they share many common statements and structures. This section describes the common statements while the succeeding sections describe the protocol specific statements.

Dates

A date is specified in two ways, depending on the configuration value for the db-time-format parameter. If it was set to default, then the date fields appear as follows:

weekday year/month/day hour:minute:second

The weekday is present to make it easy for a human to tell when a lease expires - it's specified as a number from zero to six, with zero being Sunday. The day of week is ignored on input. The year is specified with the century, so it should generally be four digits except for really long leases. The month is specified as a number starting with 1 for January. The day of the month is likewise specified starting with 1. The hour is a number between 0 and 23, the minute a number between 0 and 59, and the second also a number between 0 and 59.

Lease times are specified in Universal Coordinated Time (UTC), not in the local time zone. There is probably nowhere in the world where the times recorded on a lease are always the same as wall clock times. On most unix machines, you can display the current time in UTC by typing date -u.

If the db-time-format was configured to local, then the date fields appear as follows:

epoch <seconds-since-epoch>; # <day-name> <month-name> <day-number> <hours>:<minutes>:<seconds> <year>

The seconds-since-epoch is as according to the system's local clock (often referred to as "unix time"). The # symbol supplies a comment that describes what actual time this is as according to the system's configured timezone, at the time the value was written. It is provided only for human inspection.

If a lease will never expire, date is never instead of an actual date.

General Variables

As part of the processing of a lease information may be attached to the lease structure, for example the DDNS information or if you specify a variable in your configuration file. Some of these, like the DDNS information, have specific descriptions below. For others, such as any you might define, a generic line of the following will be included.

set variable = value;

The set statement sets the value of a variable on the lease. For general information on variables, see the dhcp-eval(5) manual page.

DDNS Variables

```
The ddns-text and ddns-dhcid variables
```

```
These variables are used to record the value of the client's identification
record when the server has updated DNS for a particular lease.  The text
record is used with the interim DDNS update style while the dhcid record
is used for the standard DDNS update style.
```

```
The ddns-fwd-name variable
```

```
This variable records the value of the name used in
updating the client's A record if a DDNS update has been successfully
done by the server.   The server may also have used this name to
update the client's PTR record.
```

```
The ddns-client-fqdn variable
```

```
If the server is configured both to use the interim or standard DDNS update
style, and to allow clients to update their own FQDNs, then if the
client did in fact update its own FQDN, the
ddns-client-fqdn variable records the name that the client has
indicated it is using.   This is the name that the server will have
used to update the client's PTR record in this case.
```

```
The ddns-rev-name variable
```

```
If the server successfully updates the client's PTR record, this
variable will record the name that the DHCP server used for the PTR
record.   The name to which the PTR record points will be either the
ddns-fwd-name or the ddns-client-fqdn.
```

```
Executable Statements
```

```
on events { statements... }
The on statement records a list of statements to execute if a
certain event occurs.   The possible events that can occur for an
active lease are release and expiry.   More than one event
can be specified - if so, the events are separated by '|' characters.
```

```
The authoring-byte-order statement
```

```
authoring-byte-order [ big-endian | little-endian ] ;
```

```
This statement is automatically added to the top of new lease files by
the server. It indicates the internal byte order of the server.  This
permits lease files generated on a server with one form of byte order
to be read by a server with a different form.  Lease files which do not
contain this entry are simply treated as having the same byte order as
the server reading them.  If you are migrating lease files generated
by a server that predates this statement and is of a different byte
order than the your destination server, you can manually add this
statement.  It must proceed any lease entries.  Valid values for this
parameter are little-endian and big-endian.
```

## THE DHCPv4 LEASE DECLARATION
lease ip-address { statements... }

Each lease declaration includes the single IP address that has been leased to the client. The statements within the braces define the duration of the lease and to whom it is assigned.

```
starts date;
ends date;
tstp date;
tsfp date;
atsfp date;
cltt date;
```

The start and end time of a lease are recorded using the starts and ends statements. The tstp statement is present if the failover protocol is being used, and indicates what time the peer has been told the lease expires. The tsfp statement is also present if the failover protocol is being used, and indicates the lease expiry time that the peer has acknowledged. The atsfp statement is the actual time sent from the failover partner. The cltt statement is the client's last transaction time.

See the description of dates in the section on common structures.

hardware hardware-type mac-address;

The hardware statement records the MAC address of the network interface on which the lease will be used. It is specified as a series of hexadecimal octets, separated by colons.

uid client-identifier;

The uid statement records the client identifier used by the client to acquire the lease. Clients are not required to send client identifiers, and this statement only appears if the client did in fact send one. Client identifiers are normally an ARP type (1 for ethernet) followed by the MAC address, just like in the hardware statement, but this is not required.

The client identifier is recorded as a colon-separated hexadecimal list or as a quoted string. If it is recorded as a quoted string and it contains one or more non-printable characters, those characters are represented as octal escapes - a backslash character followed by three octal digits. The format used is determined by the lease-id-format parameter, which defaults to octal.

client-hostname hostname ;

Most DHCP clients will send their hostname in the host-name option. If a client sends its hostname in this way, the hostname is recorded on the lease with a client-hostname statement. This is not required by the protocol, however, so many specialized DHCP clients do not send a host-name option.

```
binding state state;
next binding state state;
```

The binding state statement declares the lease's binding state. When the DHCP server is not configured to use the failover protocol, a lease's binding state may be active, free or abandoned. The failover protocol adds some additional transitional states, as well as the backup state, which indicates that the lease is available for allocation by the failover secondary. Please see the dhcpd.conf(5) manual page for more information about abandoned leases.

The next binding state statement indicates what state the lease will move to when the current state expires. The time when the current state expires is specified in the ends statement.

rewind binding state state;

This statement is part of an optimization for use with failover. This helps a server rewind a lease to the state most recently transmitted to its peer.

```
option agent.circuit-id string;
option agent.remote-id string;
```

These statements are used to record the circuit ID and remote ID options sent by the relay agent, if the relay agent uses the relay agent information option. This allows these options to be used consistently in conditional evaluations even when the client is contacting the server directly rather than through its relay agent.

The vendor-class-identifier variable

The server retains the client-supplied Vendor Class Identifier option for informational purposes, and to render them in DHCPLEASEQUERY responses.

```
bootp;
reserved;
```

If present, they indicate that the BOOTP and RESERVED failover flags (respectively) should be set. BOOTP and RESERVED dynamic leases are treated differently than normal dynamic leases, as they may only be used by the client to which they are currently allocated.

Other Additional options or executable statements may be included, see the description of them in the section on common structures.

## THE DHCPv6 LEASE (IA) DECLARATION

```
ia_ta  IAID_DUID { statements... }
ia_na  IAID_DUID { statements... }
ia_pd  IAID_DUID { statements... }
```

Each lease declaration starts with a tag indicating the type of the lease. ia_ta is for temporary addresses, ia_na is for non-temporary addresses and ia_pd is for prefix delegation. Following this tag is the combined IAID and DUID from the client for this lease.

The IAID_DUID value is recorded as a colon-separated hexadecimal list or as a quoted string. If it is recorded as a quoted string and it contains one or more non-printable characters, those characters are represented as octal escapes - a backslash character followed by three octal digits. The format used is governed by the lease-id-format parameter, which defaults to octal.

cltt date;

The cltt statement is the client's last transaction time.

See the description of dates in the section on common structures.

```
iaaddr ipv6-address { statements... }
iaprefix ipv6-address/prefix-length { statements... }
```

```
Within a given lease there can be multiple iaaddr and iaprefix statements.
Each will have either an IPv6 address or an IPv6 prefix (an address and
a prefix length indicating a CIDR style block of addresses).  The following
statements may occur Within each iaaddr or iaprefix.
```

```
binding state state;
```

```
The binding state statement declares the lease's binding state.
In DHCPv6 you will normally see this as active or expired.
```

```
preferred-life lifetime;
```

```
The IPv6 preferred lifetime associated with this address, in seconds.
```

```
max-life lifetime;
```

```
The valid lifetime associated with this address, in seconds.
```

```
ends date;
```

```
The end time of the lease.  See the description of dates in the section on
common structures.
```

```
Additional options or executable statements may be included.  See the description
of them in the section on common structures.
```

## THE FAILOVER PEER STATE DECLARATION
The state of any failover peering arrangements is also recorded in the lease file, using the failover peer statement:

```
failover peer name state {
my state state at date;
peer state state at date;
}
```

The states of the peer named name is being recorded. Both the state of the running server (my state) and the other failover partner (peer state) are recorded. The following states are possible: unknown-state, partner-down, normal, communications-interrupted, resolution-interrupted, potential-conflict, recover, recover-done, shutdown, paused, and startup.

## FILES
/var/lib/dhcp/dhcpd/state/dhcpd.leases /var/lib/dhcp/dhcpd/state/dhcpd.leases~

## SEE ALSO
dhcpd(8), dhcp-options(5), dhcp-eval(5), dhcpd.conf(5), RFC2132, RFC2131.

## AUTHOR
dhcpd(8) is maintained by ISC. Information about Internet Systems Consortium can be found at: https://www.isc.org/


title: dhcp_probe.cf(5)

summary: configuration file for dhcp_probe

text:
# dhcp_probe.cf(5)

## NAME
dhcp_probe.cf - configuration file for dhcp_probe

## SYNPOSIS
/etc/dhcp_probe.cf

## DESCRIPTION
The file /etc/dhcp_probe.cf contains configuration information used by the dhcp_probe(8) daemon. dhcp_probe reads the file when it begins (and whenever it receives a SIGHUP signal).

The location of this file defaults to /etc/dhcp_probe.cf, but may be overridden by a command-line option to dhcp_probe(8).

The file consists of a series of statements, one per line. Each statement begins with a keyword followed by one or more arguments (depending on the keyword); keywords and arguments are separated by spaces or tabs. Statements may be specified in any order.

Some keywords take an ethernet-address argument. Ethernet address values must be written in a form that ether_aton(3) recognizes; e.g. 1:2:3:4:5:6 or 00:A5:b2:0:BB:c.

Some keywords take an ip-address as a value. IP address values must be written in a form that inet_aton(3) recognizes; e.g. 192.168.1.2.

Blank lines are ignored. Lines for which the first non-blank character is a '#' are treated as comments. Trailing comments on statements are not supported.

Because all presently-defined keywords are optional, the file may be empty, however, it must exist.

## KEYWORDS
The keywords are as follows:

### chaddr
The chaddr statement is optional, and is used to specify the value of the chaddr field in the request packets sent by the program. This value is also used to compute the DHCP Client Identifier option in some of the request packets sent by the program (by prepending x'01').

Specify:

chaddr ethernet-address

If not specified, this value defaults to the Ethernet address corresponding to the interface you specified on the commandline.

You might want to use the chaddr statement if the interface is also a DHCP client, so that sending requests with the interface's own chaddr/DHCP Client Identifier will not interfere with that functionality.

If you specify a value, be sure to specify a unicast Ethernet address that does not belong to any valid client on your network.

Correctly-functioning BootP and DHCP servers that respond will send any responses to the chaddr address, or in some cases, to the Ethernet broadcast address. Therefore, if you specify a value here (and it differs from your interface's Ethernet address), the program will have to place the interface into promiscuous mode to be sure it hears unicast responses.

Note that the chaddr value does not affect the Ethernet source address of the Ethernet frames sent by the program.

If you specify this value, you may also wish to specify the same value in the ether_src statement. See the description of that statement for further discussion.

### ether_src
The ether_src statement is optional, and is used to specify the value of the ether_src field in the Ethernet frames sent by the program.

Specify:

ether_src ethernet-address

If not specified, this value defaults to the Ethernet address corresponding to the interface you specified on the commandline.

If you specify a value, be sure to specify a unicast Ethernet address that does not belong to any valid client on your network.

Note that this value does not affect the chaddr field or the DHCP Client Identifier option field in request packets sent by the program.

If you specified a chaddr value, you may also wish to specify an equal ether_src value. While not strictly necessary, doing so will cause any Layer 2 switches on the network to learn that this hardware address is on your leg of the network, so they will not need to flood response packets directed to that hardware address, but instead can direct the response packets only to your leg of the network.

Additionally, specifying the same ether_src value could help you discover any buggy BootP or DHCP servers that mistakenly direct their responses to the sender's ether_src (instead of to the sender's bootp_chaddr).

### server_id
The server_id statement is optional, and is used to specify the value of the DHCP Server Identifer option in some of the request packets sent by the program.

Specify:

server_id ip-address

If not specified, this value defaults to 10.254.254.254.

The DHCP Server Identifer option appears in the packets the program sends when it mimics a DHCP client in the SELECTING state.

It's best that the DHCP Server Identifier option the program uses not match the IP address of any valid DHCP server on your network, to avoid confusing them. Other than that, any IP address is a reasonable value; you may wish to specify one that could never be a valid address on your network.

### client_ip_address
The client_ip_address statement is optional, and is used to specify the IP address that the program should request, or claim to have a lease on.

Specify:

client_ip_address ip-address

If not specified, this value defaults to 172.31.254.254.

When the program generates a DHCPREQUEST packet that mimics a DHCP client that is in the INIT-REBOOT or SELECTING state, the packet contains a Requested IP Address option containing this value. When the program generates a DHCPREQUEST packet that mimics a DHCP client that is in the REBINDING state, the packet contains a ciaddr field containing this value.

It's best that the value the program uses not match the IP address of any valid DHCP client on your network, to avoid confusing valid DHCP servers.

It's extremely useful if the value the program uses not be valid (topologically speaking) for the physical network on which the program sends the packets. Sending a topologically inappropriate value may stimulate some DHCP servers to respond with a DHCPNAK, which helps the program flush out DHCP servers.

### response_wait_time
The response_wait_time statement is optional, and is used to specify how long the program should wait for responses after sending a single request packet.

Specify

response_wait_time num_milliseconds

If not specified, this value defaults to 5000 milliseconds (5 seconds).

The value is specified in milliseconds, and must fit into an 'int' on your host. (Values larger than an 'int' may be silently misinterpreted.) Typical values are on the order of a few thousand milliseconds; i.e. several seconds.

### cycle_time
The cycle_time statement is optional, and is used to specify how long the program should sleep between each probe cycle.

Specify

cycle_time num_seconds

If not specified, this value defaults to 300 seconds.

The value is specified in seconds, and must into into an 'unsigned int' on your host. (Values larger than an 'unsigned int' may be silently misinterpreted.) Typical valus range from several hundred to several thousand seconds (i.e. several minutes to several hours).

During each probe cycle, the program sends one of the request packet flavors, captures any responses that arrive during the response_wait_time, then repeats this for each of the other request packet flavors. After doing this for each flavor of request packet, the probe cycle is complete, and the program sleeps for the cycle_time.

### legal_server
The legal_server statement is optional, and is used to specify the IP source address of responses that come from a legal BootP or DHCP server on your network. The statement may be specified multiple times.

Specify

legal_server ip-address

If not specified, the program assumes there are no legal BootP and DHCP servers on your network; all responses will be treated as coming from an unknown DHCP server.

When the program receives a response packet, it compares the packet's IP source address to all the addresses you have specified in legal_server statements. If the IP source address matches one of these values, the response is deemed to have come from a known DHCP server, and is ignored. If the IP source address does not match any of these values (or you do not specify any legal_server), then the program logs a message that reports the packet's IP source address and Ethernet source address. Additionally, if the program was started with the -o commandline option, the packet is also written to a packet capture file.

If both legal_server and legal_server_ethersrc statements appear, then a response must have both a valid IP source and a valid ethernet source to be considered to have come from a known DHCP server.

When relaying a response from a server to a client, some BootP Relay Agents may change the response's IP source address, replacing the server's IP address with that of the BootP Relay Agent. If BootP Relay Agents on your network do this, you will need to specify their IP addresses here instead.

### legal_server_ethersrc
The legal_server_ethersrc statement is optional, and is used to specify the Ethernet source address of responses that come from a legal BootP or DHCP server on your network. The statement may be specified multiple times.

Specify

legal_server_ethersrc ethernet-address

If not specified, the program does not check the Ethernet source address of responses.

If you have specified at least one legal_server_ethersrc value, when the program receives a response packet, the program compares the packet's Ethernet source address to all the addresses you have specified in legal_server_ethersrc statements. If the Ethernet source does not match one of these values, the response is deemed to have come from an unknown DHCP server; the program logs a message that reports the packet's IP source address and Ethernet source address. Additionally, if the program was started with the -o commandline option, the packet is also written to a packet capture file.

If both legal_server and legal_server_ethersrc statements appear, then a response must have both a valid IP source and a valid ethernet source to be considered to have come from a known DHCP server.

Each router on the path from the DHCP server to the DHCP client will overwrite the Ethernet source address field. So if you specify any legal_server_ethersrc statements, also list the Ethernet source value(s) for the last hop router(s). A BootP Relay Agent on the path from the DHCP server to the DHCP client will overwrite the Ethernet field. So also list the Ethernet source value(s) for the BootP Relay Agent. (The BootP Relay Agent is often co-resident in the last-hop IP router, so you may have already taken care of this when you listed the last-hop router(s).

The legal_server_ethersrc statement is considered experimental in version 1.3.0, as it has received only limited testing.

### lease_network_of_concern
The lease_network_of_concern statement is optional, and may be specified multiple times. The statement is used to specify one or more network ranges that are of concern relative to the IP addresses distributed by a rogue BootP/DHCP server.

Specify

lease_network_of_concern network-ip-address network-mask

Specifying one or more lease_network_of_concern statements activates the "Lease Networks of Concern" feature.

When the program receives a response packet that it determines to be from a rogue BootP/DHCP server, if the "Lease Networks of Concern" feature is active, the program will examine the packet further. If the packet's yiaddr field is non-zero, the value in that field is tested to see if it falls within any of the "Leases Networks of Concern." If it does, then the message the program logs is extended to also report this fact, and to include the value of the yiaddr field. Furthermore, if an alert_program_name2 was specified, when that program is called, it is called with an additional -y yiaddr option. (This is not supported if an alert_program_name was specified, as the older alert_program_name uses a syntax that cannot be extended.)

The "Lease Networks of Concern" feature does not change the way the program probes for or detects rogue BootP/DHCP servers. Upon detection of a rogue BootP/DHCP server, the feature only may cause additional information to be added to the message logged (and passed to alert_program_name2).

This feature may be used, for example, by specifying your networks' legitimate address ranges as "Lease Networks of Concern". While most rogue BootP/DHCP servers distribute private IP addresses, or send DHCPNAKs to legitimate clients, other more damaging rogue BootP/DHCP servers may distribute IP addresses that fall within your legitimate network ranges. This will help differentiate those more damaging incidents from the more common ones.

### alert_program_name
The alert_program_name statement is optional, and may be used to specify the name of an external program that should be run every time a response packet is received from an unexpected server.

Note that using the newer alert_program_name2 statement is preferrable.

Specify

alert_program_name /absolute/path/name

Unexpected response packets are reported as a matter of course, and optionally written to a packet capture file. You may use an alert_program_name to provide additional handling of the event, for example, to alert an appropriate party via mail or paging. The alert_program_name you specify is called with four arguments in the following order: the name of the calling program (e.g. dhcp_probe), the name of the interface on which the unexpected response packet was received, the IP source address of the packet, and the Ethernet source address of the packet.

As the alert_program_name is called with the same privileges as dhcp_probe (i.e. root), you should exercise caution to ensure that the alert program is safe for a privileged user to execute.

Because the syntax supported by the external program is not extensible, the use of alert_program_name2 is preferrable.

You may not specify both alert_program_name and alert_program_name2.

### alert_program_name2
The alert_program_name2 statement is optional, and may be used to specify the name of an external program that should be run every time a response packet is received from an unexpected server.

Specify

alert_program_name2 /absolute/path/name

Unexpected response packets are reported as a matter of course, and optionally written to a packet capture file. You may use an alert_program_name2 to provide additional handling of the event, for example, to alert an appropriate party via mail or paging. The alert_program_name2 you specify is called with the following required options:

```
-p the name of the calling program (e.g. dhcp_probe),
-I the name of the interface on which the unexpected response packet was received
-i the IP source address of the packet
-m Ethernet source address of the packet
```

The following non-required options may also be passed:

```
-y the non-zero yiaddr value from the packet, when it falls inside a "Lease Network of Concern"
```

The alert_program_name2 program you specify must ignore options or arguments it does not recognize; this is to ensure it remains forward-compatible with future enhancements to dhcp_probe. It must be prepared to accept options in any order.

As the alert_program_name2 is called with the same privileges as dhcp_probe (i.e. root), you should exercise caution to ensure that the alert program is safe for a privileged user to execute.

You may not specify both alert_program_name and alert_program_name2.

## EXAMPLE
An example /etc/dhcp_probe.cf file follows:

```
# dhcp_probe.cf: config file for dhcp_probe
#
# General syntax:
#  Comment lines start with '#' (trailing comments not permitted).
#  Blank lines are OK.
#  Tokens within a line should be separated with spaces and/or tabs.
#  Entries in the file may be in any order.
#  Any 'ethernet-address' must be written in a form that ether_aton(3) recognizes; e.g.
#      1:2:3:4:5:6   00:A5:b2:0:BB:c
#  Any 'ip-address' must be written in a form that inet_aton(3) recognizes; e.g.
#      192.168.1.2
#
# ----------------------------------------------------------------------------------
#
# CLIENT HARDWARE ADDRESS
#
# By default, for the 'chaddr' field in the BootP header, we use the Ethernet
# address corresponding to the interface you specified.
# We also use this value to compute the DHCP Client Identifier option (by prepending x'01').
# You may optionally override this value.
# (Note that this does not override the Ethernet Src address in the Ethernet frame we send.)
#
# You might want to do this if our interface is also a DHCP client, so
# sending requests with the interface's own chaddr/DHCP Client Identifier would interfere with
# that functionality.
#
# If you specify a value, be sure to specify an Ethernet address that does not belong to
# any valid client on your network.  Be sure to specify a unicast Ethernet address.
#
# Syntax:
#    chaddr enet-addr
chaddr 0:0:0:1:2:3
# ----------------------------------------------------------------------------------
#
# ETHERNET SOURCE ADDRESS
#
# By default, for the 'ether_shost' field in the Ethernet header, we use the Ethernet
# address corresponding to the interface you specified.
# You may optionally override this value.
# (Note that this does not override the 'chaddr' in the BootP header, nor the DHCP Client Identifier.)
#
# If you are specify the 'chaddr' statement, you might want to also do this, so you don't miss buggy
# DHCP servers that respond (incorrectly) to ether_src instead of to chaddr.
#
# If you specify a value, be sure to specify an Ethernet address that does not belong to
# any valid client on your network.  Be sure to specify a unicast Ethernet address.
#
# Syntax:
#    ether_src enet-addr
ether_src 0:0:0:1:2:3
# ----------------------------------------------------------------------------------
#
# DHCP SERVER IDENTIFIER
#
# When we generate a DHCPREQUEST packet corresponding to a client that is in the SELECTING
# state, the options field must contain a 'DHCP Server Identifier' option, indicating the
# IP address of the DHCP server the client is selecting.   It's best that the value we use
# not match the IP address of any valid DHCP server, to avoid confusing them.  The program
# provides a default value of 10.254.254.254, which you may override here.
#
# Syntax:
#    server_id ip-addr
server_id 10.1.2.3
# ----------------------------------------------------------------------------------
#
# CLIENT IP ADDRESS
#
# When we generate a DHCPREQUEST packet corresponding to a client that is in the INIT-REBOOT
# or SELECTING state, the options field must containg a 'Requested IP Address' option, indicating
# the IP address the client is requesting.    When we generate a DHCPREQUEST packet corresponding
# to a client that is in the REBINDING state, the 'ciaddr' field in the BootP header must contain
# the IP address that the DHCP client presently has leased and wishes to renew.
#
# In all these cases, it's best that the value we use not match the IP address of any valid DHCP client,
# to avoid confusing the valid DHCP servers.
#
# Furthermore, it is extremely useful if the value we use *not* be valid (topologically speaking) for the
# physical network on which we send the packets.  Sending a topologically inappropriate value
# may stimulate some DHCP servers to respond with a DHCPNAK, which helps us flush out DHCP servers.
# (This will probably happen only in response to the packets we sending when pretending to be in REBINDING state.)
#
# The program provides a default value of 172.31.254.254, which you may override here.
#
# Syntax:
#   client_ip_address ip-addr
# client_ip_address 172.31.254.254
# ----------------------------------------------------------------------------------
#
# RESPONSE WAIT TIME
#
# After sending one packet, we wait for responses.  The length of time we wait
# is the 'response_wait_time'.  The program provides a default value of 5000, which you
# may override here.  The value is measured in milliseconds, and must fit into
# an 'int' on your host.  (Values larger than an 'int' may be silently misinterpreted.)
# Typical values are on the order of a few thousand milliseconds; i.e. several seconds.
#
# Syntax:
#    response_wait_time num_milliseconds
# response_wait_time 5000
# ----------------------------------------------------------------------------------
#
# CYCLE WAIT TIME
#
# For each flavor packet, we send the packet and listen for responses to that packet.
# After doing this for all flavor packets, we go to sleep for the "cycle_time",
# then repeat the process.  The program provides a default value of 300, which you
# may override here.  The value is measured in seconds, and must fit into an
# 'unsigned int' on your host.  (Values larger than an 'unsigned int' may be silently
# misinterpreted.)  Typical valus range from several hundred to several thousand
# seconds (i.e. several minutes to several hours).
#
# Syntax:
#    cycle_time num_seconds
cycle_time 1200
# ----------------------------------------------------------------------------------
#
# LEGAL SERVERS' IP SOURCE ADDRESSES
#
# After sending one packet, we wait for responses.  Responses from legal BootP or DHCP
# servers are ignored; presumably you aren't interesting in discovering them.
# Specify a legal server's IP source address with the 'legal_server' statement.
# The value you specify is compared to the IPsrc field in each response's IP header.
#
# If you have multiple legal servers, specify each in a separate statement.
# If your BootP Relay Agents overwrite the server's IP address in the IPsrc field
# with their own IP addresses, you will need to list the IP addresses of the
# BootP Relay Agents.
#
# Alternatively, do not specify any legal_server statements at all, so *no* responses
# will be considered legal.
# (This is different from the way legal_server_ethersrc statements are handled.)
#
# If both legal_server and legal_server_ethersrc statements appear, then a response
# must have both a valid IP source and a valid ethernet source to be considered legal.
#
# Syntax:
#   legal_server ip-addr
legal_server 192.168.1.2
legal_server 192.168.3.4
# ----------------------------------------------------------------------------------
#
# LEGAL SERVERS' ETHERNET SOURCE ADDRESSES
#
# Specify a legal server's Ethernet source address with the 'legal_server_ethersrc' statement.
# The value you specify is compared to the ethernet_src field in each response's IP header.
#
# If you have multiple legal ethernet sources, specify each in a separate statement.
# Each router on the path from the DHCP server to the DHCP client will overwrite
# the ethernet_src field.  So also list the ethernet_src value(s) for the last hop router(s).
# The BootP Relay Agent on the path from the DHCP server to the DHCP client will overwrite
# the ethernet_src field.  So also list the ethernet_src value(s) for the BootP Relay Agent.
# (This is often co-resident in the last-hop IP router, so you may have already taken care
# of this when you listed the last-hop router(s).
#
# Alternatively, do not specify any legal_server_ethersrc statements at all.
# If none are specified, then all ethernet_src values are considered legal.
# (This is different from the way legal_server statements are handled.)
#
# If both legal_server and legal_server_ethersrc statements appear, then a response
# must have both a valid IP source and a valid ethernet source to be considered legal.
#
# Syntax:
#   legal_server_ethersrc enet-addr
# legal_server_ethersrc 0:2:4:ab:cd:ef
# legal_server_ethersrc 0:17:30:1:0A:3
# ----------------------------------------------------------------------------------
#
# ALERT PROGRAM NAME
#
# In addition to logging a response received from an unexpected server, we will optionally
# call a user-specified 'alert program' if one is specified here.  To use this feature,
# specify the absolute pathname of a program we should execute for each unexpected response.
# Either specify it using the older 'alert_program_name' statement, or (preferrably) using
# the newer 'alert_program_name2' statement.  (The newer statement is preferrable because
# it calls the alert program with a more extensible syntax.)  You may not specify
# both alert_program_name and alert_program_name2.
#
# Old style alert program:
#
# Syntax:
#   alert_program_name /absolute/path/name
#
# The program specified via 'alert_program_name' will be called as follows:
#   /absolute/path/name  name_of_calling_program  name_of_interface_on_which_the_response_was_received  IP_source_of_the_response  ether_src_of_the_response
#
#
# Newer style alert program:
#
# Syntax:
#   alert_program_name2 /absolute/path/name
#
# The program specified via 'alert_program_name2' will be called as follows:
#   /absolute/path/name  -p name_of_calling_program  -I name_of_interface_on_which_the_response_was_received  -i IP_source_of_the_response  -m ether_src_of_the_response [-y yiaddr_when_in_lease_networks_of_concern]
# The options may appear in any order.
# The program must silently ignore any options or arguments it does not recognize,
# so as to be forward-compatible with future enhancements to dhcp_probe.
alert_program_name2 /usr/local/etc/dhcp_probe_notify2
# ----------------------------------------------------------------------------------
#
# LEASE NETWORKS OF CONCERN
#
# Optionally define one or more network ranges that are to be treated as
# being of special concern when a rogue BootP/DHCP server is detected sending response
# that contains a 'yiaddr' value that falls into any of these ranges.
# Specify each such network ranges of concern in a separate statement.
# When the yiaddr value in a rogue server's response falls into any of these ranges,
# the message logged will contain additional text remarking on this fact.
# And if an alert_program_name2 is used, that alert program
# will be called with an extra option so it can also act on that fact.
#
# If you specify all your networks' legitimate IP ranges, this can help you
# take additional notice of rogue BootP/DHCP servers that distribute *your*
# network addresess, rather than simply distribute private IP address or
# send DHCPNAKs to legitimate clients.
#
# Syntax:
#    lease_network_of_concern  IP-network-address network-mask
lease_network_of_concern 128.112.0.0 255.255.0.0
lease_network_of_concern 140.180.0.0 255.255.0.0
```

## SEE ALSO
dhcp_probe(8)


dhcpcd.conf

package: dhcpcd

title: dhcpcd.conf(5)

summary: dhcpcd configuration file

text:
# dhcpcd.conf(5)

## NAME
dhcpcd.conf — dhcpcd configuration file

## DESCRIPTION
Although dhcpcd can do everything from the command line, there are cases where it's just easier to do it once in a configuration file. Most of the options found in dhcpcd(8) can be used here. The first word on the line is the option and the rest of the line is the value. Leading and trailing whitespace for the option and value are trimmed. You can escape characters in the value using the \ character. Comments can be prefixed with the # character. String values should be quoted with the " character.

Here's a list of available options:

allowinterfaces pattern

When discovering interfaces, the interface name must match pattern which is a space or comma separated list of patterns passed to fnmatch(3). If the same interface is matched in denyinterfaces then it is still denied.

denyinterfaces pattern

When discovering interfaces, the interface name must not match pattern which is a space or comma separated list of patterns passed to fnmatch(3).

anonymous

Enables Anonymity Profiles for DHCP, RFC 7844. Any DUID is ignored and ClientID is set to LL only. All non essential options are then masked at this point, but they could be unmasked by explicitly requesting the option after the anonymous option is processed. As such, the anonymous option should be the last option in the configuration unless you really want to send something which could identify you. dhcpcd will not try and reboot an old lease, it will go straight into DISCOVER/SOLICIT.

randomise_hwaddr

Forces a hardware address randomisation when the interface is brought up or when the carrier is lost. This is generally used in tandem with the anonymous option.

arping address [address]

dhcpcd will arping each address in order before attempting DHCP. If an address is found, we will select the replying hardware address as the profile, otherwise the IP address. Example:

interface bge0

arping 192.168.0.1

\# My specific 192.168.0.1 network

profile dd:ee:aa:dd:bb:ee

static ip_address=192.168.0.10/24

\# A generic 192.168.0.1 network

profile 192.168.0.1

static ip_address=192.168.0.98/24

authprotocol protocol [algorithm [rdm]]

Authenticate DHCP messages. See the Supported Authentication Protocols section. If protocol is token then algorithm is snd_secretid/rcv_secretid so you can send and receive different tokens.

authtoken secretid realm expire key

Define a shared key for use in authentication. realm can be "" to for use with the delayed protocol. expire is the date the token expires and should be formatted "yyy-mm-dd HH:MM". You can use the keyword forever or 0 which means the token never expires. For the token protocol, secretid needs to be 0 and realm needs to be "". If dhcpcd has the error dhcp_auth_encode: Invalid argument

then it means that dhcpcd could not find the correct authentication token in your configuration.

background

Fork to the background immediately. This is useful for startup scripts which don't disable link messages for carrier status.

blacklist address[/cidr]

Ignores all packets from address[/cidr].

whitelist address[/cidr]

Only accept packets from address[/cidr]. blacklist is ignored if whitelist is set.

bootp

Be a BOOTP client. Basically, this just doesn't send a DHCP Message Type option and will only interact with a BOOTP server. All other DHCP options still work.

broadcast

Instructs the DHCP server to broadcast replies back to the client. Normally this is only set for non-Ethernet interfaces, such as FireWire and InfiniBand. In most cases, dhcpcd will set this automatically.

controlgroup group

Sets the group ownership of /run/dhcpcd/sock so that users other than root can connect to dhcpcd.

debug

Echo debug messages to the stderr and syslog.

dev value

Load the value /dev management module. dhcpcd will load the first one found to work, if any.

env value

Push value to the environment for use in dhcpcd-run-hooks(8). For example, you can force the hostname hook to always set the hostname with env force_hostname=YES. Or set which driver wpa_supplicant(8) should use with env wpa_supplicant_driver=nl80211 If the hostname is set, it will be will set to the FQDN if possible as per RFC 4702, section 3.1. If the FQDN option is missing, dhcpcd will still try and set a FQDN from the hostname and domain options for consistency. To override this, set env hostname_fqdn=[YES|NO|SERVER]. A value of SERVER means just what the server says, don't manipulate it. This could lead to an inconsistent hostname on a DHCPv4 and DHCPv6 network where the DHCPv4 hostname is short and the DHCPv6 has an FQDN. DHCPv6 has no hostname option.

clientid string

Send the clientid. If the string is of the format 01:02:03 then it is encoded as hex. For interfaces whose hardware address is longer than 8 bytes, or if the clientid is an empty string then dhcpcd sends a default clientid of the hardware family and the hardware address.

duid [ll | lt | uuid | value]

Use a DHCP Unique Identifier. If persistent storage is available then a DUID-LLT (link local address + time) is generated, otherwise DUID-LL is generated (link local address). The DUID type can be hinted as an optional parameter if the file /var/lib/dhcpcd/duid does not exist. If not ll, lt or uuid then value will be converted from 00:11:22:33 format. This, plus the IAID will be used as the clientid. The DUID generated will be held in /var/lib/dhcpcd/duid and should not be copied to other hosts. This file also takes precedence over the above rules except for setting a value.

iaid iaid

Set the Interface Association Identifier to iaid. This option must be used in an interface block. This defaults to the VLANID (prefixed with 0xff) for the interface if set, otherwise the last 4 bytes of the hardware address assigned to the interface. Each instance of this should be unique within the scope of the client and dhcpcd warns if a conflict is detected. If there is a conflict, it is only a problem if the conflicted IAIDs are used on the same network.

dhcp

Enable DHCP on the interface, on by default.

dhcp6

Enable DHCPv6 on the interface, on by default.

ipv4

Enable IPv4 on the interface, on by default.

ipv6

Enable IPv6 on the interface, on by default.

request [address]

Request the address in the DHCP DISCOVER message. There is no guarantee this is the address the DHCP server will actually give. If no address is given then the first address currently assigned to the interface is used.

inform [address[/cidr[/broadcast_address]]]

Behaves like request as above, but sends a DHCP INFORM instead of DISCOVER/REQUEST. This does not get a lease as such, just notifies the DHCP server of the address in use. You should also include the optional cidr network number in case the address is not already configured on the interface. dhcpcd remains running and pretends it has an infinite lease. dhcpcd will not de-configure the interface when it exits. If dhcpcd fails to contact a DHCP server then it returns a failure instead of falling back on IPv4LL.

inform6

Performs a DHCPv6 Information Request. No address is requested or specified, but all other DHCPv6 options are allowed. This is normally performed automatically when an IPv6 Router Advertisement indicates that the client should perform this operation. This option is only needed when dhcpcd is not processing IPv6 RA messages and the need for a DHCPv6 Information Request exists.

persistent

dhcpcd normally de-configures the interface and configuration when it exits. Sometimes, this isn't desirable if, for example, you have root mounted over NFS or SSH clients connect to this host and they need to be notified of the host shutting down. You can use this option to stop this from happening.

fallback profile

Fall back to using this profile if DHCP fails. This allows you to configure a static profile instead of using ZeroConf.

fallback_time seconds

Start fallback after seconds. The default is 5 seconds.

hostname name

Sends the hostname name to the DHCP server so it can be registered in DNS. If name is an empty string then the current system hostname is sent. If name is a FQDN (i.e., contains a .) then it will be encoded as such.

hostname_short

Sends the short hostname to the DHCP server instead of the FQDN. This is useful because DHCP servers will not register the FQDN in their DNS if the domain part does not match theirs. Also, see the env option above to control how the hostname is set on the host.

ia_na [iaid [/ address]]

Request a DHCPv6 Normal Address for iaid. iaid defaults to the iaid option as described above. You can request more than one ia_na by specifying a unique iaid for each one.

ia_ta [iaid]

Request a DHCPv6 Temporary Address for iaid. You can request more than one ia_ta by specifying a unique iaid for each one.

ia_pd [iaid [/ prefix / prefix_len] [interface [/ sla_id [/ prefix_len [/ suffix]]]]]

Request a DHCPv6 Delegated Prefix for iaid. This option must be used in an interface block. Unless a sla_id of 0 is assigned with the same resultant prefix length as the delegation, a reject route is installed for the Delegated Prefix to stop unallocated addresses being resolved upstream. If no interface is given then we will assign a prefix to every other interface with a sla_id equivalent to the interface index assigned by the OS. Otherwise addresses are only assigned for each interface and sla_id. To avoid delegating to any interface, use - as the invalid interface name. Each assigned address will have a suffix, defaulting to 1. If the suffix is 0 then a SLAAC address is assigned. You cannot assign a prefix to the requesting interface unless the DHCPv6 server supports the RFC 6603 Prefix Exclude Option. dhcpcd has to be running for all the interfaces it is delegating to. A default prefix_len of 64 is assumed, unless the maximum sla_id does not fit. In this case prefix_len is increased to the highest multiple of 8 that can accommodate the sla_id. sla_id is an integer which must be unique inside the iaid and is added to the prefix which must fit inside prefix_len less the length of the delegated prefix. You can specify multiple interface / sla_id / prefix_len per ia_pd, space separated. IPv6RS should be disabled globally when requesting a Prefix Delegation. In the following example eth0 is the externally facing interface to be configured for both IPv4 and IPv6. The DHCPv4 server will provide us with an IPv4 address and a default route. The DHCPv6 server is going to provide us with an IPv6 address, a default route and a /64 subnet to be delegated to the internal interface. The eth1 interface will be automatically configured for IPv6 using the first address (::1) from the delegated prefix. A second prefix is requested and assigned to two other interfaces. rtadvd(8) can be used with an empty configuration file on eth1, eth2 and eth3, to provide automatic IPv6 address configuration for the internal network.

```
noipv6rs                 # disable routing solicitation
denyinterfaces eth2      # Don't touch eth2 at all
interface eth0
  ipv6rs                 # enable routing solicitation for eth0
  ia_na 1                # request an IPv6 address
  ia_pd 2 eth1/0         # request a PD and assign it to eth1
  ia_pd 3 eth2/1 eth3/2  # req a PD and assign it to eth2 and eth3
  ia_pd 4 -              # request a PD but don't assign it
```

ipv4only

Only configure IPv4.

ipv6only

Only configure IPv6.

fqdn [disable | none | ptr | both]

none will not ask the DHCP server to update DNS. ptr just asks the DHCP server to update the PTR record of the host in DNS, whereas both also updates the A record. disable will disable the FQDN option. The default is both. dhcpcd itself never does any DNS updates. dhcpcd encodes the FQDN hostname as specified in RFC 1035.

interface interface

Subsequent options are only parsed for this interface. Pattern matching is allowed by fnmatch(3).

ipv4ll_time seconds

Wait for seconds before starting IPv4LL. The default is 5 seconds.

ipv6ra_autoconf

Generate SLAAC addresses for each Prefix advertised by an IPv6 Router Advertisement message with the Auto flag set. On by default.

ipv6ra_noautoconf

Disables the above option.

ipv6ra_fork

By default, when dhcpcd receives an IPv6 Router Advertisement, dhcpcd will only fork to the background if the RA contains at least one unexpired RDNSS option and a valid prefix or no DHCPv6 instruction. Set this option so to make dhcpcd always fork on a RA.

ipv6rs

Enables IPv6 Router Advertisement solicitation. This is on by default, but is documented here in the case where it is disabled globally but needs to be enabled for one interface.

lastlease

If dhcpcd cannot obtain a lease, then try to use the last lease acquired for the interface.

lastleaseextend

Same as the above, but the lease will be retained even if it expires. dhcpcd will give it up if any other host tries to claim it for their own via ARP. This violates RFC 2131, section 3.7, which states the lease should be dropped once it has expired.

leasetime seconds

Request DHCP a lease time of seconds. -1 represents an infinite lease time. By default dhcpcd does not request any lease time and leaves it in the hands of the DHCP server. It is not possible to request a DHCPv6 lease time as this is not RFC compliant. See RFC 8415 21.4, 21.6, 21.21 and 21.22.

link_rcvbuf size

Override the size of the link receive buffer from the kernel default. While dhcpcd will recover from link buffer overflows, this may not be desirable on heavily loaded systems.

logfile logfile

Writes to the specified logfile. dhcpcd still writes to syslog(3). The logfile is reopened when dhcpcd receives the SIGUSR2 signal.

metric metric

Metrics are used to prefer an interface over another one, lowest wins. dhcpcd will supply a default metric of 1000 + if_nametoindex(3). This will be offset by 2000 for wireless interfaces, with additional offsets of 1000000 for IPv4LL and 2000000 for roaming interfaces.

mudurl url

Specifies the URL for a Manufacturer Usage Description (MUD). The description is used by upstream network devices to instantiate any desired access lists. See draft-ietf-opsawg-mud for more information.

noalias

Any pre-existing IPv4 addresses will be removed from the interface when adding a new IPv4 address.

noarp

Don't send any ARP requests. This also disables IPv4LL.

arp_persistdefence

Keep the IP address even if defence fails upon IP Address conflict.

noauthrequired

Don't require authentication even though we requested it. Also allows FORCERENEW and RECONFIGURE messages without authentication.

nodelay

Don't delay for an initial randomised time when starting protocols.

nodev

Don't load /dev management modules.

nodhcp

Don't start DHCP or listen to DHCP messages. This is only useful when allowing IPv4LL.

nodhcp6

Don't start DHCPv6 or listen to DHCPv6 messages. Normally DHCPv6 is started by an IPv6 Router Advertisement instruction or configuration.

nogateway

Don't install any default routes.

gateway

Install a default route if available (default).

nohook script

Don't run this hook script. Matches full name, or prefixed with 2 numbers optionally ending with .sh. So to stop dhcpcd from touching your DNS settings or starting wpa_supplicant you would do:-

nohook resolv.conf, wpa_supplicant

noipv4

Don't attempt to configure an IPv4 address.

noipv4ll

Don't attempt to obtain an IPv4LL address if we failed to get one via DHCP. See RFC 3927.

noipv6

Don't solicit or accept IPv6 Router Advertisements and DHCPv6.

noipv6rs

Don't solicit or accept IPv6 Router Advertisements.

nolink

Don't receive link messages about carrier status. You should only set this for buggy interface drivers.

nosyslog

Disable writing to syslog(3).

noup

Don't bring the interface up when in manager mode.

option option

Requests the option from the server. It can be a variable to be used in dhcpcd-run-hooks(8) or the numerical value. You can specify more options separated by commas, spaces or more option lines. Prepend dhcp6_ to option to request a DHCPv6 option. If no DHCPv6 options are configured, then DHCPv4 options are mapped to equivalent DHCPv6 options. Prepend nd_ to option to handle ND options, but this only works for the nooption, reject and require options.

To see a list of options you can use, call dhcpcd with the -V, --variables argument.

nooption option

Remove the option from the message before it's processed.

require option

Requires the option to be present in all messages, otherwise the message is ignored. To enforce that dhcpcd only responds to DHCP servers and not BOOTP servers, you can require dhcp_message_type. This isn't an exact science though because a BOOTP server can send DHCP-like options.

reject option

Reject a message that contains the option. This is useful when you cannot use require to select / de-select BOOTP messages.

destination option

If dhcpcd.conf detects an address added to a point to point interface (PPP, TUN, etc) then it will set the listed DHCP options to the destination address of the interface.

profile name

Subsequent options are only parsed for this profile name.

quiet

Suppress any dhcpcd output to the console, except for errors.

reboot seconds

Allow reboot seconds before moving to the DISCOVER phase if we have an old lease to use. Allow reboot seconds before starting fallback states from the DISCOVER phase. IPv4LL is started when the first reboot timeout is reached. The default is 5 seconds. A setting of 0 seconds causes dhcpcd.conf to skip the reboot phase and go straight into DISCOVER. This is desirable for mobile users because if you change from network A to network B and they use the same subnet and the address from network A isn't in use on network B, then the DHCP server will remain silent even if authoritative which means dhcpcd will timeout before moving back to the DISCOVER phase. This has no effect on DHCPv6 other than skipping the reboot phase.

release

dhcpcd will release the lease prior to stopping the interface.

script script

Use script instead of the default /lib/dhcpcd/dhcpcd-run-hooks.

request_time seconds

Request the lease for seconds before going back to DISCOVER. The default is 180 seconds.

ssid ssid

Subsequent options are only parsed for this wireless ssid.

slaac hwaddr | private | token token [temp | temporary]

Selects the interface identifier used for SLAAC generated IPv6 addresses. If private is used, a RFC 7217 address is generated. If token token is used then the token is combined with the prefix to make the final address. The temporary directive will create a temporary address for the prefix as well.

static value

Configures a static value. If you set ip_address then dhcpcd will not attempt to obtain a lease and will just use the value for the address with an infinite lease time. If you set an empty value this removes all prior static allocations to the same value. This is useful when using profiles and in the case of ip_address it will remove the static allocation. Note that setting 0.0.0.0 keeps the static allocation but waits for a 3rdparty to configure the address. If you set ip6_address, dhcpcd will continue auto-configuration as normal. Here is an example which configures two static address, overriding the default IPv4 broadcast address, an IPv4 router, DNS and disables IPv6 auto-configuration. You could also use the inform6 command here if you wished to obtain more information via DHCPv6. For IPv4, you should use the inform ipaddress option instead of setting a static address.

interface eth0

noipv6rs

static ip_address=192.168.0.10/24

static broadcast_address=192.168.0.63

static ip6_address=fd51:42f8:caae:d92e::ff/64

static routers=192.168.0.1

static domain_name_servers=192.168.0.1 fd51:42f8:caae:d92e::1

Here is an example for PPP which gives the destination a default route. It uses the special destination keyword to insert the destination address into the value.

interface ppp0

static ip_address=0.0.0.0

destination routers

timeout seconds

Time out after seconds, instead of the default 30. A setting of 0 seconds causes dhcpcd to wait forever to get a lease. If dhcpcd is working on a single interface then dhcpcd will exit when a timeout occurs, otherwise dhcpcd will fork into the background. If using IPv4LL then dhcpcd start the IPv4LL process after the timeout and then wait a little longer before really timing out.

userclass string

Tag the DHCPv4 message with the userclass. You can specify more than one.

msuserclass string

Tag the DHCPv4 mesasge with the Microsoft userclass. Unlike the userclass option, this one can only be added once. It should only be used for Microsoft DHCP servers and the vendorclassid should be set to "MSFT 98" or "MSFT 5.0". This option is not RFC compliant.

vendor code,value

Add an encapsulated vendor-specific information option (DHCP Option 43). code should be between 1 and 254 inclusive. To add a raw vendor string, omit code but keep the comma. Examples. Set the vendor option 01 with an IP address.

vendor 01,192.168.0.2

Set the vendor option 02 with a hex code. vendor 02,01:02:03:04:05

Set the vendor option 03 with an IP address as a string. vendor 03,\"192.168.0.2\"

Set un-encapsulated vendor option to hello world. vendor ,"hello world"

vsio en code,value

Add an encapsulated vendor-specific information option (DHCP Option 125) with IANA assigned Enterprise Number en proceeding with the code which should be between 1 and 255 inclusive, and the value after the comma. Examples: Set the vsio for enterprise number 155 option 01 with an IPv4 address.

vsio 155 01,192.168.1.1

Set the vsio for enterprise number 155 option 02 with a string. vsio 155 02,"hello world"

Set the vsio for enterprise number 255 option 01 with a hex code. vsio 255 01,01:02:03:04:05

vsio6 en code,value

Add an encapsulated vendor-specific information option (DHCPv6 Option 17) with IANA assigned Enterprise Number en proceeding with the code which should be between 1 and 65535 inclusive, and the value after the comma. Examples: Set the vsio for enterprise number 155 option 01 with an IPv6 address.

vsio6 155 01,2001:0db8:85a3:0000:0000:8a2e:0370:7334

Set the vsio for enterprise number 155 option 02 with a string. vsio6 155 02,"hello world"

Set the vsio for enterprise number 255 option 01 with a hex code. vsio6 255 01,01:02:03:04:05

vendorclassid string

Set the DHCP Vendor Class. DHCPv6 has its own option as shown below. The default is dhcpcd-<version>:<os>:<machine>:<platform>. For example dhcpcd-5.5.6:NetBSD-6.99.5:i386:i386

If not set then none is sent. Some badly configured DHCP servers reject unknown vendorclassids. To work around it, try and impersonate Windows by using the MSFT vendorclassid.

vendclass en data

Add the DHCPv6 Vendor Indetifying Vendor Class with the IANA assigned Enterprise Number en with the data. This option can be set more than once to add more data, but the behaviour, as per RFC 3925 is undefined if the Enterprise Number differs.

waitip [4 | 6]

Wait for an address to be assigned before forking to the background. 4 means wait for an IPv4 address to be assigned. 6 means wait for an IPv6 address to be assigned. If no argument is given, dhcpcd.conf will wait for any address protocol to be assigned. It is possible to wait for more than one address protocol and dhcpcd.conf will only fork to the background when all waiting conditions are satisfied.

xidhwaddr

Use the last four bytes of the hardware address as the DHCP xid instead of a randomly generated number.

### Defining new options
DHCP, ND and DHCPv6 allow for the use of custom options, and RFC 3925 vendor options for DHCP can also be supplied. Each option needs to be started with the define, definend, define6 or vendopt directive. This can optionally be followed by both embed or encap options. Both can be specified more than once and embed must come before encap.

define code type variable

Defines the DHCP option code of type with a name of variable exported to dhcpcd-run-hooks(8).

definend code type variable

Defines the ND option code of type with a name of variable exported to dhcpcd-run-hooks(8), with a prefix of nd_.

define6 code type variable

Defines the DHCPv6 option code of type with a name of variable exported to dhcpcd-run-hooks(8), with a prefix of dhcp6_.

vendopt code type variable

Defines the Vendor-Identifying Vendor Options. The code is the IANA Enterprise Number which will uniquely describe the encapsulated options. type is normally encap. variable names the Vendor option to be exported.

embed type variable

Defines an embedded variable within the defined option. The length is determined by the type. If the variable is not the same as defined in the parent option, it is prefixed with the parent variable first with an underscore. If the variable has the name of reserved then it is not processed.

encap code type variable

Defines an encapsulated variable within the defined option. The length is determined by the type. If the variable is not the same as defined in the parent option, it is prefixed with the parent variable first with an underscore.

### Type prefix
These keywords come before the type itself, to describe it more fully. You can use more than one, but they must appear in the order listed below.

request

Requests the option by default without having to be specified in user configuration.

norequest

This option cannot be requested, regardless of user configuration.

optional

This option is optional. Only makes sense for embedded options like the client FQDN option, where the FQDN string itself is optional.

index

The option can appear more than once and will be indexed.

array

The option data is split into a space separated array, each element being the same type.

truncated

The option might truncated from its normal length. The end of the normal size is zero padded on expansion. Currently this is only supported for ip6address where it's a prefix.

### Types to define
The type directly affects the length of data consumed inside the option. Any remaining data is normally discarded. Lengths can be specified for string and binhex types, but this is generally with other data embedded afterwards in the same option.

ipaddress

An IPv4 address, 4 bytes.

ip6address

An IPv6 address, 16 bytes.

string [: length]

A NVT ASCII string of printable characters.

byte

A byte.

bitflags: flags

A byte represented as a string of flags, most significant bit first. For example, using ABCDEFGH then A would equal 10000000, B 01000000, C 00100000, etc. If the bit is not set, the flag is not printed. A flag of 0 is not printed even if the bit position is set. This is to allow reservation of the first bits while assigning the last bits. A flag of 1 prints the bit set or unset.

int16

A signed 16bit integer, 2 bytes.

uint16

An unsigned 16bit integer, 2 bytes.

int32

A signed 32bit integer, 4 bytes.

uint32

An unsigned 32bit integer, 4 bytes.

flag

A fixed value (1) to indicate that the option is present, 0 bytes.

domain

An RFC 3397 encoded string.

dname

An RFC 1035 validated string.

uri

If an array then the first two bytes are the URI length inside the option data. Otherwise, the whole option data is the URI. As a space is not allowed in the URI encoding, the URIs are space separated.

binhex [: length]

Binary data expressed as hexadecimal.

embed

Contains embedded options (implies encap as well).

encap

Contains encapsulated options (implies embed as well).

option

References an option from the global definition.

### Example definition
\# DHCP option 81, Fully Qualified Domain Name, RFC 4702

define 81 embed fqdn

embed byte flags

embed byte rcode1

embed byte rcode2

embed domain fqdn

\# DHCP option 125, Vendor Specific Information Option, RFC 3925

define 125 encap vsio

embed uint32 enterprise_number

\# Options defined for the enterprise number

encap 1 ipaddress ipaddress

### Supported Authentication Protocols
token

Sends a plain text token the server expects and matches a token sent by the server. The tokens do not have to be the same. If unspecified, the token with a secretid of 0 will be used in sending messages and validating received messages.

delayedrealm

Delayed Authentication. dhcpcd will send an authentication option with no key or MAC. The server will see this option, and select a key for dhcpcd.conf, writing the realm and secretid in it. dhcpcd will then look for an unexpired token with a matching realm and secretid. This token is used to authenticate all other messages.

delayed

Same as above, but without a realm.

### Supported Authentication Algorithms
If none specified, hmac-md5 is the default.

hmac-md5

### Supported Replay Detection Mechanisms
If none specified, monotonic is the default. If this is changed from what was previously used, or the means of calculating or storing it is broken, then the DHCP server will probably have to have its notion of the client's Replay Detection Value reset.

monocounter

Read the number in the file /var/lib/dhcpcd/dhcpcd-rdm.monotonic and add one to it.

monotime

Create an NTP timestamp from the system time.

monotonic

Same as monotime.

## SEE ALSO
fnmatch(3), if_nametoindex(3), dhcpcd(8), dhcpcd-run-hooks(8)

## AUTHORS
Roy Marples <roy@marples.name>

## BUGS
Please report them to https://roy.marples.name/projects/dhcpcd


diod.conf

package: diod

title: diod.conf(5)

text:
# diod.conf(5)

## NAME
diod.conf - distributed I/O daemon configuration file

## DESCRIPTION
The diod.conf file is actually a LUA script. Internal config defaults are overridden by settings in the file, and some of those values can in turn be overridden on the command line.

Config settings take the form of LUA global variables which are read out after the config file is executed. Therefore, the values of said variables can either be statically assigned or computed. The variables are described below.

## CONFIG VARIABLES
listen = { "IP:PORT" [,"IP:PORT",...] }

List the interfaces and ports that diod should listen on. The default is "0.0.0.0:564".

exports = { "/path" [, "/path", ...] }

List the file systems that clients will be allowed to mount. All paths should be fully qualified. The exports table can include two types of element: a string element (as above), or an alternate table element form { path="/path", opts="ro" }. In the alternate form, the (optional) opts attribute is a comma-separated list of export options, as described below in EXPORT OPTIONS. The two table element forms can be mixed in the exports table. Note that although diod will not traverse file system boundaries for a given mount due to inode uniqueness constraints, subdirectories of a file system can be separately exported.

exportall = 1

Export all file systems listed in /proc/mounts. If new file systems are mounted after diod has started, they will become immediately mountable. If there is a duplicate entry for a file system in the exports list, any options listed in the exports entry will apply.

exportopts = "opt,opt,..."

Establish a default set of export options. These are overridden, not appended to, by opts attributes in an "exports" entry.

nwthreads = INTEGER

Sets the (fixed) number of worker threads created to handle 9P requests for a unique aname. The default is 16 per aname.

auth_required = 0

Allow clients to connect without authentication, i.e. without a valid MUNGE credential.

userdb = 0

This option disables password/group lookups. It allows any uid to attach and assumes gid=uid, and supplementary groups contain only the primary gid.

allsquash = 1

Remap all users to "nobody". The attaching user need not be present in the password file.

squashuser = "nobody"

Change the squash user from the default of nobody. The squash user must be present in the password file.

logdest = "DEST"

Set the destination for logging. DEST is in the form of syslog:facility:level or filename. The default is syslog:daemon:err.

statfs_passthru = 1

This option configures statfs to return the host file system's type rather than V9FS_MAGIC. The default is 0 (return V9FS_MAGIC).

## EXPORT OPTIONS
The following export options are defined:

ro

Export the file system read-only.

suppress

Exclude this file system from exports. Useful following exportall = 1.

sharefd

Allow limited server-side file descriptor sharing for files opened O_RDONLY by the same user.

privport

Reject attach request unless client is bound to a port in the privileged port range (512-1023). The diodcat utility has a --privport option which, when run as root, binds to a privileged socket before connecting. This provides limited additional security, especially in open networks, as it is vulnerable to IP spoofing attacks.

noauth

Allow attach to succeed without authentication.

## EXAMPLE

```
--
-- example diod.conf
--
listen = { "0.0.0.0:10002" }
exports = {
	"/home",
	"/usr/global",
	{ path="ctl", opts="ro,noauth" },
	{ path="/usr/local", opts="ro" },
}
nwthreads = 8
```

## FILES
/etc/diod.conf

## SEE ALSO
lua (1), diod (8), openlog (3)

http://www.lua.org/


directfbrc

package: directfb

title: directfbrc(5)

summary: DirectFB configuration file

text:
# directfbrc(5)

## NAME
directfbrc - DirectFB configuration file

## DESCRIPTION
The directfbrc file is a configuration file read by all DirectFB applications on startup. There are two of these: a system-wide one stored in /etc/directfbrc and a per-user $HOME/.directfbrc which may override system settings.

Further customization is available per executable (basename of argv[0]): /etc/directfbrc.$0 and a per-user $HOME/.directfbrc.$0

After config files, the environment variable DFBARGS is parsed.

The same parameters that can be used in the directfbrc file can be passed via this variable or on the command-line by prefixing them with --dfb: separated each with a comma.

## SYNTAX
The directfbrc file contains one parameter per line. Comments are introduced by a hash sign (#), and continue until the end of the line. Blank lines are ignored.

Most parameters are switches that turn certain features on or off. These switches have a no- variant that disables the feature. This man-page describes the positive variant and will also note which setting is the compiled-in default.

## PARAMETERS
The following parameters may be specified in the directfbrc file:

system=<system>

Specifies the graphics system to use. The default is to use the Linux frame buffer (fbdev) but you can also run DirectFB applications on SDL (sdl). Other systems might be added in the future.

fbdev=<device>

Opens the given frame buffer device instead of /dev/fb0.

busid=<id>

Specify the bus location of the card. The option is only used if DirectFB doesn't have sysfs support and if unspecified 1:0:0 will be assumed. Use this option if the driver fails to detect (or incorrectly detects) your card.

mode=<width>x<height>

Sets the default screen resolution. If unspecified DirectFB will use the first mode from /etc/fb.modes Some frame buffer devices (namely vesafb) don't support mode switches and can only be used in the resolution that is set on boot time.

scaled=<width>x<height>

Scale the window to this size for 'force-windowed' apps.

depth=<pixeldepth>

Sets the default pixel depth in bits per pixel. If unspecified DirectFB will use the depth specified in the first mode from /etc/fb.modes DirectFB supports color depths of 8, 15, 16, 24 and 32. Which values are available depends on the frame buffer device you are using. Some frame buffer devices (namely vesafb) don't support mode switches at all and can only be used in the pixel depth that is set at boot time.

pixelformat=<pixelformat>

Sets the default pixel format. This is similar to the depth parameter described above but allows more fine-grained control. Possible values for pixelformat are LUT8, RGB332, RGB16, RGB24 and RGB32. Some drivers may also support the more exotic pixel formats A8, ALUT44, ARGB, ARGB1555, I420, UYVY, YUY2 and YV12.

session=<num>

Selects the multi application world which is joined or created. Starting with zero, negative values force creation of a new world using the lowest unused session number. This will override the environment variable "DIRECTFB_SESSION".

force-slave

Always enter as a slave, waiting for the master, if not there.

remote=<host>[:<session>]

Select the remote session to connect to.

tmpfs=<directory>

Uses the given directory (tmpfs mount point) for creation of the shared memory file in multi application mode. This option is only useful if the automatic detection fails or if non-tmpfs storage is desired.

shmfile-group=<groupname>

Group that owns shared memory files.

memcpy=<method>

With this option the probing of memcpy() routines can be skipped, saving a lot of startup time. Pass "help" for a list of possible values.

primary-layer=<id>

Selects which layer is the "primary layer", default is the first. Check 'dfbinfo' for a list of layers supported by your hardware.

primary-only

Tell application only about the primary layer.

quiet

Suppresses console output from DirectFB. Only error messages will be displayed.

[no-]banner

Enables the output of the DirectFB banner at startup. This is on by default.

[no-]debug

Enables debug output. This is on by default but you won't see any debug output unless you compiled DirectFB with debugging support.

[no-]debugmem

Enable memory allocation tracking.

[no-]debugshm

Enable shared memory allocation tracking.

[no-]trace

Enable stack trace support. This is on by default but you won't see any trcae output unless you compiled DirectFB with trace support.

log-file=<name>

Write all messages to the specified file.

log-udp=<host>:<port>

Send all messages via UDP to the specified host and port.

fatal-level=<level>

Abort on NONE, ASSERT (default) or ASSUME (incl. assert)

force-windowed

Forces the primary surface to be a window. This allows to run applications that were written to do full-screen access in a window.

force-desktop

Forces the primary surface to be the background surface of the desktop.

[no-]hardware

Turns hardware acceleration on. By default hardware acceleration is auto-detected. If you disable hardware acceleration, the driver for your graphics card will still be loaded and used to access additional display layers (if there are any), but all graphics operations will be performed by the software renderer.

[no-]software

This option allows to disable software fallbacks.

[no-]dma

Turns DMA acceleration on, if supported by the driver. By default DMA acceleration is off.

[no-]sync

Flushes all disk buffers before initializing DirectFB. This can be useful if you working with experimental device drivers and expect crashes. The default is not to sync.

[no-]mmx

The no-mmx options allows to disable the use of MMX routines even if support for MMX was detected. By default MMX is used if is available and support for MMX was compiled in.

[no-]agp[=mode]

Turns AGP memory support on. The option enables DirectFB using the AGP memory to extend the amount of video memory available. You can specify the AGP mode to use (e.g. 1, 2, 4, 8 or 0 to disable agp). By default AGP memory support is off.

[no-]thrifty-surface-buffers

Free sysmem instance on xfer to video memory.

font-format=<format>

Specify the font format to use. Possible values are A1, A8, ARGB, ARGB1555, ARGB2554, ARGB4444, AiRGB. The default font format is A8 because it is the only format that ensures high quality, fast rendering and low memory consumption at the same time. Use this option only if your fonts looks strange or if font rendering is too slow.

[no-]sighandler

By default DirectFB installs a signal handler for a number of signals that cause an application to exit. This signal handler tries to deinitialize the DirectFB engine before quitting the application. Use this option to enable/disable this feature.

dont-catch=<num>[[,<num>]...]

As described with the sighandler option, DirectFB installs a signal handler for a number of signals. By using this option you may specify a list of signals that shouldn't be handled this way.

[no-]deinit-check

By default DirectFB checks if the application has released all allocated resources on exit. If it didn't, it will clean up after the application. This option allows to switch this feature on or off.

block-all-signals

This option activates blocking of all signals, useful for DirectFB daemons (a DirectFB master application that does nothing except being the master).

[no-]vt-switch

By default DirectFB allocates a new virtual terminal and switches to it.

vt-num=<num>

Use given VT instead of current/new one.

[no-]vt-switching

Allow to switch virtual terminals using <Ctrl>+<Alt>+<F?>. This is an experimental feature that is usually disabled; use at your own risk.

[no-]graphics-vt

Puts the virtual terminal into graphics mode. This has the advantage that kernel messages won't show up on your screen while the DirectFB application is running.

[no-]vt

Use VT handling code at all?

mouse-source=<device>

Specify the serial mouse device.

[no-]mouse-gpm-source

Enables using GPM as mouse input repeater.

[no-]motion-compression

Usually DirectFB compresses mouse motion events. This means that subsequent mouse motions are delivered to the application as a single mouse motion event. This leads to a more responsive but less exact mouse handling.

mouse-protocol=<protocol>

Specifies the mouse protocol to use. The following protocols are supported: MS Two button mouse using the Microsoft mouse protocol.

MS3 Three button mouse using an extended Microsoft mouse protocol.

MouseMan Three button mouse using a different extension to the Microsoft mouse protocol introduced by Logitech.

MouseSystems The most commonly used protocol for three button mice.

PS/2 Two/three button mice of the PS/2 series.

IMPS/2 Two/three button USB mice with scrolling wheel using the Microsoft Intellimouse protocol.

The different protocols for serial mice are described in more detail in mouse(4).

[no-]lefty

Swaps left and right mouse buttons. Useful for left-handers.

[no-]capslock-meta

Map the CapsLock key to Meta. Useful for users of the builtin WM without a Meta key on the keyboard (e.g. Window key).

linux-input-ir-only

Ignore all non-IR Linux Input devices.

[no-]cursor

By default DirectFB shows a mouse cursor when an application makes use of windows. This option allows to switch the cursor off permanently. Applications cannot enable it explicitly.

wm=<wm>

Specify the window manager to use.

bg-none

Completely disables background handling. Doesn't make much sense since the mouse and moving windows will leave ugly traces on the background.

bg-color=AARRGGBB

Controls the color of the background. The color is specified in hexadecimal notation. The alpha value defaults to full opacity and may be omitted. For example to choose a bright magenta background, you'd use bg-color=FF00FF.

bg-image=<filename>

Fills the background with the given image from file. The image is stretched to fit to the screen dimensions.

bg-tile=<filename>

Like bg-image but tiles the image to fit to the screen dimensions instead of stretching it.

[no-]translucent-windows

By default DirectFB windows may be translucent. If you disable this feature, windows are forced to be either fully opaque or fully transparent. This is useful if your graphics card doesn't support alpha-transparent blits.

[no-]decorations

Enables window decorations if supported by the window manager.

videoram-limit=<amount>

Limits the amount of Video RAM used by DirectFB. The amount of Video RAM is specified in Kilobytes.

agpmem-limit=<amount>

Limits the amount if AGP memory used by DirectFB. The amount of AGP memory is specified in Kilobytes.

screenshot-dir=<directory>

If specified DirectFB will dump the screen contents in PPM format into this directory when the <Print> key gets pressed.

disable-module=<modulename>

Suppress loading of this module. The module name is the filename without the libdirectfb_ prefix and without extension (for example keyboard to disable loading of the keyboard input module).

[no-]matrox-sgram

Some older Matrox G400 cards have SGRAM and a number of graphics operations are considerably faster on these cards if this feature is enabled. Don't try to enable it if your card doesn't have SGRAM! Otherwise you'd have to reboot.

[no-]matrox-crtc2

If you have a dual head G400/G450/G550 you can use this option to enable additional layers using the second head.

matrox-tv-standard=[pal|ntsc]

Controls the signal produced by the TV output of Matrox cards.

matrox-cable-type=(composite|scart-rgb|scart-composite)

Matrox cable type (default=composite).

h3600-device=<device>

Use this device for the H3600 TS driver.

mut-device=<device>

Use this device for the MuTouch driver.

penmount-device=<device>

Use this device for the PenMount driver.

unichrome-revision=<revision>

Override the hardware revision number used by the Unichrome driver.

i8xx_overlay_pipe_b

Redirect videolayer to pixelpipe B.

window-surface-policy=<policy>

Allows to control where window surfaces are stored. Supported values for <policy> are: auto DirectFB decides depending on hardware capabilities. This is the default.

videohigh Swapping system/video with high priority.

videolow Swapping system/video with low priority.

systemonly Window surfaces are stored in system memory.

videoonly Window surfaces are stored in video memory.

desktop-buffer-mode=<mode>

Allows to control the desktop buffer mode. Whenever a window is moved, opened, closed, resized or its contents change DirectFB recomposites the window stack at the affected region. This is done by blitting the windows together that are visible within that region. Opaque windows are blitted directly while translucent windows are blitted using alpha blending or color keying. If there's a back buffer the recomposition is not visible since only the final result is copied into the front buffer. Without a back buffer each step of the recomposition is visible. This causes noticeable flicker unless all windows are opaque. Supported values for <mode> are:

auto DirectFB decides depending on hardware capabilities. This is the default. DirectFB chooses a back buffer in video memory if the hardware supports simple blitting (copying from back to front buffer). If there's no acceleration at all the back buffer is allocated in system memory since that gives much better performance for alpha blended recomposition in software and avoids reading from the video memory when the result is copied to the front buffer.

backsystem The back buffer is allocated in system memory. This is the recommend choice if your hardware supports simple blitting but no alpha blending and you are going to have many alpha blended windows.

backvideo Front and back buffer are allocated in video memory. It's not required to set this mode explicitly because the 'auto' mode chooses it if blits are accelerated. Without accelerated blits this mode is not recommended.

frontonly There is no back buffer. This is the best choice if you are using opaque windows only and don't use any color keying.

vsync-after

Wait for the vertical retrace after flipping. The default is to wait before doing the flip.

vsync-none

Disables polling for vertical retrace.

## EXAMPLES
Here are some examples that demonstrates how the parameters described above are passed to DirectFB application on the command-line.

df_neo --dfb:no-hardware

Starts df_neo without hardware acceleration.

df_neo --dfb:help

Lists the DirectFB options that can be passed to df_neo.

## OTHER INFO
The canonical place to find informations about DirectFB is at http://www.directfb.org/. Here you can find the FAQ, tutorials, mailing list archives, the CVS tree and can download the latest version of the DirectFB library as well as a number of applications.

## FILES
/etc/directfbrc

system-wide DirectFB configuration file

$HOME/.directfbrc

per-user DirectFB configuration file

/etc/fb.modes

frame buffer modes file

## SEE ALSO
fb.modes(5), fbset(8), mouse(4), ppm(5)


dleyna-renderer-service.conf

package: dleyna-renderer

title: dleyna-renderer-service.conf(5)

text:
# dleyna-renderer-service.conf(5)

## NAME
dleyna-renderer-service.conf - Configuration file for dleyna-renderer-service

## SYNOPSIS

- /etc/dleyna-renderer-service.conf

- $XDG_CONFIG_HOME/dleyna-renderer-service.conf

## DESCRIPTION
The dleyna-renderer-service program provides the com.intel.dleyna-renderer name on the session message bus. It is a service for discovering and manipulating DLNA Digial Media Renderers (or DMRs). Users or administrators should never need to start this daemon as it will be automatically started by dbus-daemon whenever a process sends a D-Bus message to the com.intel.dleyna-renderer name on the session bus.

This file can be used to configure the behavior of the dleyna-renderer-service program

## FILE FORMAT
The configuration file format is the so-called key file (sort of ini-style) format. It consists of sections (or groups) of key-value Lines beginning with a '#' and blank lines are considered comments. Sections are started by a header line containing the section enclosed in '[' and ']', and ended implicitly by the start of the next section or the end of the file. Each key-value pair must be contained in a section.

## GENERAL SECTION
connector-name=dbus

The name of the inter-process communication method to be used. The only supported value is dbus

never-quit=false|true

Whether the process should stay alive forever or quit when the last client disconnects. The default value is false.

port

Source port for Simple Service Discovery Protocol (or SSDP) messages. The default value is 0 which means that a random available port will be used.

push-host-port

Port for push host file server. The default value is 0 which means that a random available port will be used.

## LOG SECTION
log-type=0|1|2

The logging method to be used. Three technologies are supported. 0 for syslog, 1 for GLib, and 2 for file. The default value is 0.

log-level=0|1|2|...|8

Comma-separated list of logging levels. The levels are 1 for critical, 2 for error, 3 for warning, 4 for message, 5 for info and 6 for debug. 0 excludes all levels, 7 is a combination of critical, error and info, and 8 includes all levels. The default value is 7.

## NETF SECTION
netf-enabled=true|false

Whether network filtering should be enabled or not. The default values is false.

netf-list

Comma-separated list of interface names, service set identifiers (or SSIDs), and Internet Protocol (or IP) addresses. If network filtering is requested but the list is empty, then filtering remains disabled. The list is empty by default.

## BUGS
Please send bug reports to either the distribution bug tracker or the upstream bug tracker at https://gitlab.gnome.org/World/dLeyna/issues

## SEE ALSO
dleyna-renderer-service(1)


dleyna-server-service.conf

package: dleyna-server

title: dleyna-server-service.conf(5)

text:
# dleyna-server-service.conf(5)

## NAME
dleyna-server-service.conf - Configuration file for dleyna-server-service

:Manual section:5

## SYNOPSIS

- /etc/dleyna-server-service.conf

- $XDG_CONFIG_HOME/dleyna-server-service.conf

## DESCRIPTION
The dleyna-server-service program provides the com.intel.dleyna-server name on the session message bus. It is a service for discovering and manipulating DLNA Digital Media Renderers (or DMRs). Users or administrators should never need to start this daemon as it will be automatically started by dbus-daemon whenever a process sends a D-Bus message to the com.intel.dleyna-server name on the session bus.

This file can be used to configure the behavior of the dleyna-server-service program

## FILE FORMAT
The configuration file format is the so-called key file (sort of ini-style) format. It consists of sections (or groups) of key-value Lines beginning with a '#' and blank lines are considered comments. Sections are started by a header line containing the section enclosed in '[' and ']', and ended implicitly by the start of the next section or the end of the file. Each key-value pair must be contained in a section.

## GENERAL SECTION
connector-name=dbus

The name of the inter-process communication method to be used. The only supported value is dbus

never-quit=false|true

Whether the process should stay alive forever or quit when the last client disconnects. The default value is false.

port

Source port for Simple Service Discovery Protocol (or SSDP) messages. The default value is 0 which means that a random available port will be used.

## LOG SECTION
log-type=0|1|2

The logging method to be used. Three technologies are supported. 0 for syslog, 1 for GLib, and 2 for file. The default value is 0.

log-level=0|1|2|...|8

Comma-separated list of logging levels. The levels are 1 for critical, 2 for error, 3 for warning, 4 for message, 5 for info and 6 for debug. 0 excludes all levels, 7 is a combination of critical, error and info, and 8 includes all levels. The default value is 7.

## NETF SECTION
netf-enabled=true|false

Whether network filtering should be enabled or not. The default values is false.

netf-list

Comma-separated list of interface names, service set identifiers (or SSIDs), and Internet Protocol (or IP) addresses. If network filtering is requested but the list is empty, then filtering remains disabled. The list is empty by default.

## BUGS
Please send bug reports to either the distribution bug tracker or the upstream bug tracker at https://gitlab.gnome.org/World/dLeyna/issues

## SEE ALSO
dleyna-server-service(1)