While looking into the
Roaring Penguin dueling symlink issue, I ran into a little mystery:
People testing Roaring Penguin in Puppy 4.0.0 tried just pressing ENTER at the "Enter the DNS information here" prompt during setup. This was to prevent the creation of the infamous symlink at /etc/resolv.conf, and it succeeded at doing that.
But Barry was concerned that
BarryK wrote:There may be a problem if you type just the ENTER key instead of "server". It may setup PPPoE not to obtain the nameservers from the ISP.
People reported, however, that the nameserver information was coming through just fine. This was good for them, since that is what they wanted, and is what most people would want.
Leon wrote:BarryK wrote:Could you check that, start with nothing in /etc/resolv.conf, press just the ENTER key instead of typing "server", and see if it gets the nameservers from the isp.
Works fine for me.
Checked with fresh install. At DNS prompt just pressed ENTER.
This is the contents of my /etc/resolv.conf file created after starting internet connection for the first time:
nameserver 193.189.160.13
nameserver 193.189.160.23
This are the nameservers from my ISP.
oli wrote:To press just ENTER works fine for me. /etc/resolv.conf than gets automatically the nameservers from my ISP.
But Barry was quite correct to think that there might be a problem since when "server" is not entered the
usepeerdns option should not be passed from pppoe-connect to pppd, and no nameserver information should be written to /etc/ppp/resolv.conf.
When running pppoe-setup, the user is supposed to be able to specifically enter nameservers, or just press ENTER to leave the /etc/resolv.conf as it is. Only entering "server" should result in /etc/resolv.conf being overwritten with the nameservers obtained from the ISP server. So the fact that nameservers from the ISP server were coming through despite the fact that the user didn't specify "server" was a bit of a puzzle.
I checked and found that pppd was being called correctly, without the
usepeerdns option. So what was wrong? After a bit of head-scratching I found that there is an /etc/ppp/options file, created for some other app, that always gets read by pppd. That file had the
usepeerdns option in it.
What to do?
Simply removing that file would break one or more other PPP apps.
I was hoping to be able to make use of the fact that pppd accepts various other options files for things like specific serial ports or specific peers. Unfortunately those other files simply added to the options in /etc/ppp/options. They could add options; they could override options; but they could not take options away. For instance, it is possible to override
defaultroute with
nodefaultroute, but it is not possible to override
usepeerdns with
nousepeerdns because there is no
nousepeerdns option.
(There is yet another type of options file which is used with the
file name option. The pppd man page says that option will "Read options from file. . .", rather than "Read
additional options from the file. . ." as other option files were described. So I was hopeful that this would be an alternative to /etc/ppp/options, not an extension of it. But experimentation proved otherwise. Rats.)
Well, I'd hoped to find a simple answer to this problem by changing a configuration file, but it looks like it will instead require a simple wrapper to temporarily hide /etc/ppp/options from pppd, like so:
Code: Select all
#/bin/sh
mv -f /etc/ppp/options /etc/ppp/options.prev
pppoe-start1 "$@"
mv -f /etc/ppp/options.prev /etc/ppp/options
That would replace /usr/sbin/pppoe-start, which would, in turn, be renamed pppoe-start1.
Alternatively, /etc/ppp/options could be eliminated, and specific options files be created for any PPP app that needed one. But that would also require changes in those apps so that those application-specific files would be found. And that is not only for PPP apps included with Puppy, but also for PPP apps in the repositories now and in the future. That would be a nightmare.
Wait, how about all the other stuff in /etc/ppp/options other than
usepeerdns? Does Roaring Penguin need any of that?
Not according to Roaring Penguin. If you run pppoe-start in debug mode, like so:
the pppoe-debug.txt file it logs to will report:
* The following section lists /etc/ppp/options.
* You should have NOTHING in that file.
Roaring Penguin passes all its options to pppd on a command line, so does not require /etc/ppp/options.
Looking at /etc/ppp/options, it appears that, with one exception, all of the options provided by it are either identical to those passed by Roaring Penguin on the command line, or are related to using a serial port, which is not applicable to PPPoE. The one exception is
asyncmap 0, but that is the default anyway if no
asyncmap option is given.
If it was determined that, despite Roaring Penguin's claim that "You should have NOTHING in that file," something was needed that couldn't be put in by way of pppoe-setup or pppoe.conf, then a specific option file, /etc/ppp/options.rp, could be made for Roaring Penguin. In order for Roaring Penguin to find that file, a line would need to be added to /etc/ppp/pppoe.conf:
Code: Select all
PPPD_EXTRA="file /etc/ppp/options.rp"
I should point out that this suggested wrapper script has not been fully tested since I just connect to my local network, and don't use PPPoE from Puppy. I have tried the script and verified that the original /etc/ppp/options file doesn't get read, and I've run pppoe-start in debug mode and verified that the options passed to pppd are correct. But, obviously, I'm not able make a connection to make sure that everything works properly.
Also, I should make it clear that although this behavior was first noted in this "Puppy 4 Beta 2" thread, the same /etc/ppp/options file has been around since at least Puppy 1.0.4, and is still present in 4.3.1. So this behavior probably exists in various Puppies.
And, finally, this change should not be made before applying Barry's 2005 fix to pppoe-connect so that users can safely choose "server" without running into the dueling symlinks problem. Otherwise they would no longer be able to get the nameservers from their ISP's server if they wanted.
Okay, I've rambled on long enough here. This obviously is not a high priority. Most people want to use the nameservers provided by their ISP's server, and that works today (if one avoids the dueling symlinks). But for other choices, Roaring Penguin does not currently work as described in pppoe-setup or /etc/ppp/pppoe.conf. And occasionally someone wants to use OpenDNS nameservers or some other alternative to those provide by their ISP. So it would be nice to get this working some day.
--npierce