Subject: PPPd's selection of interfaces
To: None <email@example.com, firstname.lastname@example.org>
From: Lucio de Re <email@example.com>
Date: 09/21/1998 20:15:28
'Scuse the multiple posting, I'm not sure which list is more
It took me a while to figure what had seemingly gone wrong with NAT and
filtering on a client site, although it had been staring me in the
face: on startup two "pppd" instances had somehow reversed positions
and the nett result was that a site intended to be within the network
found strict filtering rules applied to it, while the rest of the
Internet was granted the type of access I permitted such sites as are
intended to be "within" the network.
Sad and hard to spot, off the cuff. Even harder to fix remotely, as I
had to sever my connection to alter the situation (I then had the
second instance of pppd started only after the first connection had
been fully established).
There are a few possibilities here: the more logical one seems to me
for pppd to grab the next available interface as early as possible in
its operation so that one has a deterministic interface assignment.
Perhaps even better might be to specify the interface in the options,
something too obvious to have been overlooked: am I not reading the MAN
Alternatively, it may be acceptable for pppd to drop into background
(on demand, if necessary) only once connection is established.
This last approach is too fraught with problems (such as delaying
system start up excessively) to be recommendable, but may be
permissible under certain conditions.
If some work needs to be done to the pppd code, I'll happily do it, but
I'd like to find out from users which approach makes the most practical