PPPOECTL(8) BSD System Manager's Manual PPPOECTL(8)
pppoectl, ipppctl -- display or set parameters for an pppoe or isdn ppp (ippp) interface
pppoectl [-v] ifname [parameter[=value]] [...]
ipppctl [-v] ifname [parameter[=value]] [...]
pppoectl -e ethernet-ifname [-s service-name] [-a access-concentrator-name] [-d] [-n 1 | 2] ifname
pppoectl -f config-file ifname [...]
There are two basic modes of operation: configuring security-related parameters and attaching a PPPoE interface to its ethernet interface,
optionally passing in additional parameters for the PPPoE encapsulation.
The latter usage is indicated by the presence of the -e option, which takes the name of the ethernet interface as its argument.
-e specifies the ethernet interface used to communicate with the access concentrator (typically via a DSL modem).
-a specifies the name of the access concentrator.
-s specifies the name of the service connected to.
-d dump the current connection state information (this parameter is typically used alone, for informational purposes, not during inter-
-n 1 | 2
print the IP address of the primary or secondary DNS name server for this PPP connection. This is only available if DNS query is
enabled, see query-dns.
-f parse config-file for parameter[=value] pairs, one per line, as if they had been specified on the command line. This allows the
password to be not passed as a command line argument. Unless escaped by , comments starting with # to the end of the current line
Typically, not both the access concentrator name and the service name are specified.
The ippp(4) or the pppoe(4) drivers require a number of additional arguments or optional parameters besides the settings that can be adjusted
with ifconfig(8). These are things like authentication protocol parameters, but also other tunable configuration variables. The pppoectl
utility can be used to display the current settings, or adjust these parameters as required.
For whatever intent pppoectl is being called, at least the parameter ifname needs to be specified, naming the interface for which the set-
tings are to be performed or displayed. Use ifconfig(8) or netstat(1) to see which interfaces are available.
If no other parameter is given, pppoectl will just list the current settings for ifname and exit. The reported settings include the current
PPP phase the interface is in, which can be one of the names dead, establish, authenticate, network, or terminate. If an authentication pro-
tocol is configured for the interface, the name of the protocol to be used, as well as the system name to be used or expected will be dis-
played, plus any possible options to the authentication protocol if applicable. Note that the authentication secrets (sometimes also called
keys) are not being returned by the underlying system call, and are thus not displayed.
If any additional parameter is supplied, superuser privileges are required, and the command works in 'set' mode. This is normally done qui-
etly, unless the option -v is also enabled, which will cause a final printout of the settings as described above once all other actions have
been taken. Use of this mode will be rejected if the interface is currently in any other phase than dead. Note that you can force an inter-
face into dead phase by calling ifconfig(8) with the parameter 'down'.
The currently supported parameters include:
authproto=protoname Set both his and my authentication protocol to protoname. The protocol name can be one of 'chap', 'pap', or
'none'. In the latter case, the use of an authentication protocol will be turned off for the named interface.
This has the side-effect of clearing the other authentication-related parameters for this interface as well (i.
e., system name and authentication secret will be forgotten).
myauthproto=protoname Same as above, but only for my end of the link. I.e., this is the protocol when remote is authenticator, and I am
the peer required to authenticate.
hisauthproto=protoname Same as above, but only for his end of the link.
myauthname=name Set my system name for the authentication protocol.
hisauthname=name Set his system name for the authentication protocol. For CHAP, this will only be used as a hint, causing a warn-
ing message if remote did supply a different name. For PAP, it's the name remote must use to authenticate himself
(in connection with his secret).
myauthsecret=secret Set my secret (key, password) for use in the authentication phase. For CHAP, this will be used to compute the
response hash value, based on remote's challenge. For PAP, it will be transmitted as plaintext together with the
system name. Don't forget to quote the secrets from the shell if they contain shell metacharacters (or white-
myauthkey=secret Same as above.
hisauthsecret=secret Same as above, to be used if we are authenticator and the remote peer needs to authenticate.
hisauthkey=secret Same as above.
callin Require remote to authenticate himself only when he's calling in, but not when we are caller. This is required
for some peers that do not implement the authentication protocols symmetrically (like Ascend routers, for exam-
always The opposite of callin. Require remote to always authenticate, regardless of which side is placing the call.
This is the default, and will not be explicitly displayed in 'list' mode.
norechallenge Only meaningful with CHAP. Do not re-challenge peer once the initial CHAP handshake was successful. Used to work
around broken peer implementations that can't grok being re-challenged once the connection is up.
rechallenge With CHAP, send re-challenges at random intervals while the connection is in network phase. (The intervals are
currently in the range of 300 through approximately 800 seconds.) This is the default, and will not be explicitly
displayed in 'list' mode.
idle-timeout=idle-seconds For services that are charged by connection time the interface can optionally disconnect after a configured idle
time. If set to 0, this feature is disabled. Note: for ISDN devices, it is preferable to use the isdnd(8) based
timeout mechanism, as isdnd can predict the next charging unit for ISDN connections and optimize the timeout with
lcp-timeout=timeout-value Allows to change the value of the LCP timeout. The default value of the LCP timeout is currently set to 1 second.
The timeout-value must be specified in milliseconds.
max-noreceive=sec Sets the number of seconds after last reception of data from the peer before the line state is probed by sending
LCP echo requests. The sec interval is not used verbatim, the first echo request might be delayed upto 10 seconds
after the configured interval.
max-alive-missed=count Sets the number of unanswered LCP echo requests that we will tolerate before considering a connection to be dead.
LCP echo requests are sent in 10 seconds interval after the configured max-noreceive interval has passed with no
data received from the peer.
max-auth-failure=count Since some ISPs disable accounts after too many unsuccessful authentication attempts, there is a maximum number of
authentication failures before we will stop retrying without manual intervention. Manual intervention is either
changing the authentication data (name, password) or setting the maximum retry count. If count is set to 0 this
feature is disabled.
clear-auth-failure If an authentication failure has been caused by remote problems and you want to retry connecting using unchanged
local settings, this command can be used to reset the failure count to zero.
query-dns=flags During PPP protocol negotiation we can query the peer for addresses of two name servers. If flags is 1 only the
first server address will be requested, if flags is 2 the second will be requested. Setting flags to 3 queries
The result of the negotiation can be retrieved with the -n option.
# ipppctl ippp0
hisauthproto=chap hisauthname="ifb-gw" norechallenge
lcp timeout: 3.000 s
Display the settings for ippp0. The interface is currently in dead phase, i.e. the LCP layer is down, and no traffic is possible. Both ends
of the connection use the CHAP protocol, my end tells remote the system name 'uriah', and remote is expected to authenticate by the name
'ifb-gw'. Once the initial CHAP handshake was successful, no further CHAP challenges will be transmitted. There are supposedly some known
CHAP secrets for both ends of the link which are not being shown.
# ipppctl ippp0
myauthname=uriah myauthsecret='some secret'
A possible call to pppoectl that could have been used to bring the interface into the state shown by the previous example.
The following example is the complete sequence of commands to bring a PPPoE connection up:
# Need ethernet interface UP (or it won't send any packets)
ifconfig ne0 up
# Let pppoe0 use ne0 as its ethernet interface
pppoectl -e ne0 pppoe0
# Configure authentication
# Configure the pppoe0 interface itself. These addresses are magic,
# meaning we don't care about either address and let the remote
# ppp choose them.
ifconfig pppoe0 0.0.0.0 0.0.0.1 netmask 0xffffffff up
netstat(1), ippp(4), pppoe(4), ifconfig(8), ifwatchd(8)
B. Lloyd and W. Simpson, PPP Authentication Protocols, RFC 1334.
W. Simpson, Editor, The Point-to-Point Protocol (PPP), RFC 1661.
W. Simpson, PPP Challenge Handshake Authentication Protocol (CHAP), RFC 1994.
L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, and R. Wheeler, A Method for Transmitting PPP Over Ethernet (PPPoE), RFC 2516.
The pppoectl utility is based on the spppcontrol utility which appeared in FreeBSD 3.0.
The program was written by Jorg Wunsch, Dresden, and modified for PPPoE support by Martin Husemann.
October 11, 2011 BSD