|
NAMEpppoed —
handle incoming PPP over Ethernet connections
SYNOPSIS
DESCRIPTIONThepppoed utility listens to the given
interface for PPP over Ethernet (PPPoE) service request
packets, and actions them by negotiating a session then invoking a
ppp(8)
program. The negotiation is implemented by the “pppoe” netgraph
node. See
ng_pppoe(4)
for details.
The The supplied name will be given as the access concentrator name when establishing the connection. If no name is given, the current base hostname is used. After receiving a request (PADI) from the PPPoE netgraph node,
exec
/usr/sbin/ppp -direct
labelas a shell sub-process. If label has not been specified, it defaults to provider. It is possible to specify another command using the exec argument. This is mandatory if provider and label are not given. The child process will have standard input and standard output attached to the same netgraph(4) data socket (see ng_socket(4)) when started. The environment variables Upon invocation, If the If pidfile is given,
DIAGNOSTICSAfter creating the necessary netgraph(4) nodes as described above,pppoed uses
syslogd(8)
to report all incoming connections. If the -d option
is given, pppoed will report on the child processes
creation of a new netgraph socket, its service offer and the invocation of the
ppp(8)
program. If the -n option is given, netgraph
diagnostic messages are also redirected to
syslogd(8).
It is sometimes useful to add the following to /etc/syslog.conf: !pppoed *.* /var/log/pppoed.log and the following to /etc/newsyslog.conf: /var/log/pppoed.log 640 3 100 *
Z SEE ALSONgSetDebug(3), netgraph(4), ng_ether(4), ng_pppoe(4), ng_socket(4), syslog.conf(5), ppp(8), syslogd(8)HISTORYThepppoed utility was written by Brian
Somers
<brian@Awfulhak.org>
and first appeared in FreeBSD 3.4.
BUGSIf another netgraph node is using the given interface,pppoed will fail to start. This is because
netgraph(4)
does not currently allow node chaining. This may change in the future.
Visit the GSP FreeBSD Man Page Interface. |