control_finish: Out of IP addresses on tunnel 13157!

[jkroonza]

Describe the bug

We have an lns section similar to:

[lns name]
lac = $a.128-$a.255
ip range = $b.0-$b.127
local ip = $loopback
require chap = yes
require pap = yes
require authentication = yes
pppoptfile = /etc/ppp/options.name
pass peer = no

After a while (typically several hours) we start seeing this in the logs:

control_finish: Out of IP addresses on tunnel

This is in spite of at the time typically around 40-45 connected users, as can be seen there are 128 addresses available, and should thus support 128 concurrent connections.

One workaround would be to delegate IP Address allocation, which is what we're probably what we're going to do.

To Reproduce

Set up similar. In our case the LAC that bridges PPPoE connections to the L2TP server. I suspect any client mechanism will work.

start up and drop the clients from the client/LAC side.

Expected behavior

"Out of IP addresses on tunnel" messages should only appear if there are actually 128 connected clients.

l2tp detail:

• x2ltpd version: [e.g. 1.3.16] (can upgrade to 1.3.18 even though we see no relevant changes in the code)

xl2tpd.conf

[lns name]
lac = $a.128-$a.255
ip range = $b.0-$b.127
local ip = $loopback
require chap = yes
require pap = yes
require authentication = yes
pppoptfile = /etc/ppp/options.name
pass peer = no

[jkroonza]

I suspect that for some reason in some disconnect cases unreserve_addr is not being called.

We don't normally from our side terminate connections except for pppd's lcp-echo-failure (in combination with lcp-echo-interval and lcp-echo-adaptorive). In rare cases we will manually kill a pppd instance.

I don't think that xl2tpd would terminate a connection from it's side given the configuration, and we don't use xl2tpd-control currently.

From what I can tell, a fair number of connections are terminated with this in the logs:

Dec  9 06:27:59 cerberus xl2tpd[27173]: control_finish: Connection closed to $a.233, serial 152469729 (Terminated by PPPoE: Received PPPoE PADT)
Dec  9 06:27:59 cerberus xl2tpd[27173]: Terminating pppd: sending TERM signal to pid 12668

As far I can tell from the code, this means destroy_call will get called, and by implication unreserve_addr() to release the allocated addresses.

I'm however not convinced that in the case where pppd terminates first, resulting in SIGCHLD being the first notification to xl2tpd that cleanup happens properly. Not 100% how to verify this either.

One other piece of supporting observation is that at a quick glance we believed IPs were being used in a cycle, meaning first connection would get .0 above, second would get .1 etc ... even if the previous connection has already terminated. Looking at get_addr() it doesn't look like this should be the case.