On Sat, Dec 24, 2016 at 11:17:18PM +0100, Christoph Biedl wrote:
> Unfortunately this has an unpleaseant side effect: Since the new
> pptpd instance has no knowlegde of the old one's children, it will
> happily allocate connection slots (by IP address) that are already
> in use. So the second client will not see any traffic.
Yes, but only when IP address allocation is controlled by pptpd.
Other IP address allocation methods are radius, chap-secrets (pppd),
and remote (ipcp-accept-remote). For this pptpd takes --delegate
option.
> The only way to solve this AFAICS was the old instance persists all
> the childrens' information so the new one will not allocate them
> while they are running. There might be some race conditions to
> consider as well. James (upstream) is reading this, if you can solve
> this by Jan 20th I'll be happy to include it for stretch. Afterwards
> it might be too late.
I've no plans to fix this by that date, but I'm interested in patches
to do so.
My preference is a /var/run/pptpd/ip directory containing a file for
each active connection, name equal to IP address, content is PID.
pptpmanager.c slot_* functions would maintain these files as a mirror
of struct slot *slots.
Here's a quick pseudo-code plan;
void slot_set_pid(int i, pid_t pid)
{
struct slot *slot = &slots[i];
// if pid is zero, {
// delete file,
// } else {
// create and write pid to file
// }
slot->pid = pid;
}
int slot_find_by_pid(pid_t pid)
{
int i;
for(i=0; i<slot_count; i++) {
struct slot *slot = &slots[i];
if (slot->pid == pid)
// if file exists, {
// read pid from file,
// if pid exists (kill with sig zero), {
// continue (skip slot),
// } else {
// unlink file,
// }
return i;
}
return -1;
}
--
James Cameron
http://quozl.netrek.org/
