resolvconf: /etc/resolv.conf manager - Experiment

[rerwin]

The /etc/resolv.conf file contains DNS IP addresses and other information for a network connection. When multiple connections are active, the file may lose data due to uncoordinated updating of that file.

The apparently standard way to manage the potential conflicts among connections is by the script, resolvconf, which maintains a merged resolv.conf, so that all connections are supported continuously. The developer of the dhcpcd network controller has published the 'openresolv' package to manage ethernet, wifi, point-to-point (PPP) and virtual private network connections. This would seem to be very useful in puppies that have both dialup and ethernet/wifi networks active or act as routers or "sharers".

Until now, Puppy has addressed the conflict issue by disabling ethernet/wifi networks when a dialup connection is attempted and not restoring the network afterward. Pupdial does this; pgprs probably should, but does not. Gpptp (for virtual private networking) saves and restores the current resolv.conf file but does not retain the original information during the virtual session. Frisbee allows concurrent wifi and ethernet connections but may be vulnerable to nameserver conflicts. Problems can arise when network connections drop and are restored, needing the appropriate DNS information at unpredictable times and causing other connections to fail.

The attached packages include the resolvconf script and the PPP (dialup, mobile, vpn) interface (ip-up, ip-down) scripts. When those scripts are present, dhcpcd and pppd will use them. The "patch" packages adapt the pupdial and gpptp scripts to accommodate resolvconf. They are provided to those willing to experiment with them, to build our confidence that puppy can utilize this managing script. Eventually, the patch and interface packages will be submitted to woof-CE, along with the then-current version of openresolv.

Note that the interface package installation also edits the resolvconf script to log each use of it, including the program that invoked it, to /tmp/debug.log. Install that package only after installing openresolv, to activate the logging. Installing openresolv after the interface package would do no harm, but would eliminate the logging.

With these packages installed, the remaining question is whether there are other parts of puppy that might be impacted by multiple concurrent network connections. We will know only by having users try them in complex networking setups. If other measures have been taken to work around the resolv.conf bottleneck, they need to be identified so we can adapt them to use resolvconf. Anyone with knowledge about possible issues is encouraged to enlighten us/me.

As usual, please report your experiences with these packages.
Richard

[Atle]

I tested with a Huawei E353, but that is a kind of a weird modem that come up as a Eth in network config.

But it did not mess with the wifi that was in Wlanmaker mode and working. Even when i added also a cable, it worked fine. I could unplug the modem and it was all flawless and the same with the cable. I was under the impression that they both worked simultaneously.

But i do not think this modem test is what you want as this modem does not use the Gpprs or Pupdial. And it would be a bit fun to know if they both worked at the same time the USB modem and and the cable.

[rerwin]

Atle,
If you have installed the openresolv and pupdial-patch packages, you also need the "interface" package. which has not been downloaded. Or did you run your test without any of them?

If your modem does not require either pupdial of pgprs, how does it get connected? Does wlanmaker do it? I need to check that pet package.

To see if resolvconf got involved, look at /tmp/debug.log. Also, watch /etc/resolv.conf while both devices have connections -- both of their nameservers should be in it. That would confirm they are both connected.
R

[Atle]

The Huewei E353 is a strange but somehow nice modem. I think its a cooperation with Linux foundadtion(kernel) and Huewai, where the kernel recognize it as a eth1 and not a usb modem.

But yes i did all the stuff without the package first in order to then see what the package does. This lever is very much Greek for me.

atle

[rerwin]

Atle,
If you downloaded the "20160319" interface package, please uninstall it and install its replacement, "20160320". The old version causes endless looping, so should be deleted completely.

I see that your modem is actually considered to be an internet sharing device that can be reconfigured as an ordinary 3G modem. I found a web page that tells how to do that. As a sharing device, it apparently handles the network connection itself, without pupdial or pgprs.

So, you probably have an eth connection to it, and other wlan-type connections to the wireless clients. It would be interesting to see how those connections interact with resolvconf. At some point, could you send or post a pdiag file taken when everything is "up"?
Richard

[jafadmin]

Hey, Richard, how have you been? Interesting project.

I remember back 2010 or so spending a couple of months experimenting with various DNS/resolv.conf scenarios.

Logically one would think DNS should function like a FIFO stack, but my research steered me more toward a LIFO type solution. Here's why:

The real problem is actually routing. Where is the default route set? What are the static routes in play?

If I'm connected to the internet and want to leave my default route set there, but I want to VPN in to my workplace and set a static route there, I need the workplace DNS servers to reply first with work related services and resources, so they need to be at the top of the list, since 8.8.8.8 isn't going to know what mysql1.mycorp.local is.

But guess what does happen? If I want to browse to www.lolcats.com over my default route connection while connected to the mycorp VPN, the mycorp.local DNS servers will resolve that for me, anyway.

So for me, it really came down to how our tools are being used, and where.

[rerwin]

jafadmin,
I was hoping you would join us, here. Thank you.

If I want to browse to www.lolcats.com over my default route connection while connected to the mycorp VPN, the mycorp.local DNS servers will resolve that for me, anyway.

This is what I woud expect, given that the priorities for namesevers are the ones for VPN, PPP, and then all other interface types. That can be overridden by entries in /etc/resolvconf.conf.

The resolvconf.conf man page in /usr/share/doc describes the options. The option that catches my eye is "private_interfaces". Try:

private_interfaces=ppp0

I tried this on my PC and saw that the nameservers for only eth0 appeared in resolv.conf. If I instead specified eth0, only the nameservers for the ppp0 interface appeared in resolv.conf. You would use whatever interface name is for your VPN connection, instead of ppp0.

EDIT: To automate making the interface private, use the command:
resolvconf -p -a ppp0 (or your substitute interface name)

That would go into the updated ip-up scripts instead of the "resolvconf -a..." command.

[jafadmin]

I'm playing with it. once I have a chance to test some scenarios I'll report back.

Meanwhile, here's a version of "ip-up" I wrote that preserves the existing nameservers and pushes the VPN, etc nameservers onto the top of the list in /etc/resolv.conf

Code: Select all

#!/bin/sh 
#
# The environment is cleared before executing this script so the path must 
# be reset. 
# 
PATH=/usr/bin:/usr/sbin:/usr/X11R7/bin:/sbin:/bin 
export PATH  

declare -a nameservers
while read line
do
   [[ "${line}" =~ ^#.*$ ]] && continue  # we don't want comment lines
   nameservers+=("$line")
done < /etc/resolv.conf

# Update DNS servers for ppp connection
[ ! -z $DNS1 ] && echo "nameserver $DNS1" > /etc/resolv.conf
[ ! -z $DNS2 ] && echo "nameserver $DNS2" >> /etc/resolv.conf

# now append our original DNS servers to the file
for x in "${nameservers[@]}"
do
    echo "${x}" >> /etc/resolv.conf
done
#End!

So why do this? Sometimes the the site you're connecting to via VPN has nameservers that only resolve the resources inside that domain, and don't use upstream forwarders. In that case you'll need their DNS servers at the top, and your usual DNS servers for the default route.

[jafadmin]

I also run workstations with linux Mint 17. They use resolvconf. For me, at least, resolvconf shoves the DNS mechanics too far under the hood. There is no simple way to see what DNS servers I'm using, or to change them. With a static resolv.conf, I easily can.

There are only two things relevant on a client machine as far as DNS is concerned. Which DNS servers to use, and where are they in the DNS stack (list). There are no algorithms to efficiently do this for us, because theres no way to predict which nameservers can resolve whatever you type in an address bar.

For those who want to have complete control over their DNS, resolv.conf is the ticket.

If I'm on a public wifi hotspot, they may be handing out Google DNS servers, but I don't want google tracking my usage. I may rather use FreeDNS, or OpenDNS, or even something else.

Being able to easily override the provisioned DNS is a powerful feature.

[Atle]

So this would apply to configurations where homebrew Wlanmaker and Routermaker are in use in case secondary adapter is mobile internet?

[rerwin]

Atle,
That would seem to be the type of situation where resolvconf might be useful. But the developer of the "makers" may already have managed the DNS/nameservers, making resolvconf unnecessary.

I am disappointed that resolvconf does not completely handle concurrent dialup and ethernet connections, in that the ethernet/wifi connection always provides the DNS server for use by the dialup connection, which is inappropriate. As jafadmin discussed above, the problem is using the DNS that is available on a particular connection or VPN. I suspect that would require separate routing tables. I am not currently able to work on that angle, but am open to having others look into it.

[Atle]

I wish i had a normal USB 3G modem to test with, but i do not.

Maybe this thread could shed some light on the issue?

I guess Tone must have tested with more than just one 3G modem?

http://www.murga-linux.com/puppy/viewtopic.php?t=100924

[Atle]

I now got a true usb mobile modem and are ready to test. Its the kind of mobile modem that uses the dial up function unlike the other modem I got as mentioned previous.

But I did a test with Sulu004, where I used the set up with Xampp, Joomla and Wlanmaker.

I got to also say that I did also follow the instructions concerning the usage of DNSmasq as seen as one of the last posts in the thread. Just so to make sure we all know its not "just" a ordinary Wlanmaker installation.

But what I did take notice of even before we start testing with USB modem, was that the connection was very slow initially as Eth0 was connected to the internet, while Wlanmaker was running.

Meanwhile if Eth0 is not connected, that appearance of the webpage at 192.168.100.1 is instant unlike the above mentioned scenario.

So yes... there are issues to resolve...

Need to reboot into the latest ISO that contains the various elements that are wanted to work flawless... But need to reboot first and update this post.

UPDATE: Here is the iso I use and I have updated the Joomla to release.

http://www.mediafire.com/download/qmvdm ... erPlus.iso

UPDATE: My ZTE MF656 modem need a update and then i probably need to do the last thing i want... ask a windows user

atle