(Userland) PPPoE problems

[Brett Glass]

I'm having odd problems with FreeBSD's userland PPPoE. A 4.8-RELEASE 
client is attempting to contact a server running an older version of 
FreeBSD (circa 4.6, with patches) that also handles several other PPPoE 
clients. The first four connect (using virtually identical ppp.conf 
files), but the fifth client does not. Instead, I see constant log 
messages from pppoed which say:

May  6 11:51:34 <daemon.info> server pppoed[1105]: Creating a new socket node
May  6 11:51:34 <daemon.info> server pppoed[1105]: Sending CONNECT from 
.:exec-1105 -> fxp0:orphans.exec-1105
May  6 11:51:34 <daemon.info> server pppoed[1105]: Sending 
NGM_SOCK_CMD_NOLINGER to socket
May  6 11:51:34 <daemon.info> server pppoed[1105]: Offering to 
.:exec-1105 as access concentrator lariat
May  6 11:51:34 <daemon.info> server pppoed[1105]: adding to .:exec-1105 
as offered service lariat
May  6 11:51:34 <daemon.info> server pppoed[1105]: Sending original 
request to .:exec-1105 (60 bytes)
May  6 11:51:34 <daemon.info> server pppoed[1105]: Waiting for a SUCCESS 
reply .:exec-1105

And then, a long time later...

May  6 11:51:50 <daemon.info> server pppoed[1105]: .:exec-1105: Client 
timed out

The original pppoed process on the host, invoked via the line

/usr/libexec/pppoed -d -P /var/run/pppoed.pid -a server -p server fxp0

spawns multiple children which go through this simultaneously. None 
actually allow a connection.

The /etc/ppp.conf file is very standard for a PPPoE host:

server:
   allow mode direct                             # Only for use on server-side
   set mru 1492                                  # Max allowed by the 
PPPoE spec
   set mtu 1492                                  # Max allowed by the 
PPPoE spec
   set speed sync                                # PPPoE is always synchronous
   enable proxy                                  # Proxy ARP
   enable chap                                   # Force client authentication
   disable pap                                   # Don't send password in 
the clear
   # Control the compression protocol used by disabling anything we DON'T want
   disable mppe                                  # Disable mppe to ensure 
compression
   deny mppe                                     # Also deny it if they 
ask for it
   disable deflate                               # Disable deflate compression
   deny deflate                                  # Also deny it if they 
ask for it
   set timeout 0                                 # No idle timeout for PPP!
   accept dns                                    # Allow DNS negotiation
   set cd 5                                      # PPPoE uses "carrier" detect
   enable lqr                                    # Re-establish broken 
connections
   set lqrperiod 15                              # Check the link often
   set log +ccp                                  # Log compression negotiations


I'm wondering (this is speculative) whether I'm running up against some 
non-obvious limit, perhaps on the number of netgraph nodes or sockets, 
the number of sessions that can run through one Ethernet interface. There 
are 10 tun devices, so the system does not seem to be running out of those.

What's the best way to diagnose and/or fix this problem?

--Brett