Re: [gentoo-user] ppp-gentoo woes cont'd [SOLVED-sorta]

Re: [gentoo-user] ppp-gentoo woes cont'd [SOLVED-sorta]

[Maxim Wexler]

>>
>>> with ppp connections you are not using a dhcp client, pppd gets the
>>> nameserver ip addressess as part of the connection negotiation (if
>>> peerdns is set) and the aforemetioned script in
>>> /etc/ppp/ip-up.d/40-dns.sh writes those to /etc/resolv.conf

This is at the top of /etc/resolv.conf
# Generated by dhcpcd
# /etc/resolv.conf.head can replace this line
# /etc/resolv.conf.tail can replace this line

But according to /var/log/messages:

Mar 28 13:24:01 lumby pppd[16825]: primary   DNS address 75.153.176.1
Mar 28 13:24:01 lumby pppd[16825]: secondary DNS address 75.153.176.9

But whatever is in resolv.conf is overwritten with blanks AFTER I
connect. Which creates this odd situation where I can ping numbers,
ie, 8.8.8.8 but not com, net, org etc.

Once I "connect" I have to echo the DNS addresses into resolv.conf
before I can reach anything.

Also, I notice whenever I set up a route to my router those numbers
get wiped. Is that the default behavio(u)r?. NB, I have nothing in the
way of services other than ppp configured at all. Maybe later after I
sort it all out I'll rig up something automatic.

Thanks for everybody's hlp

MW

ps:  according to /etc/ppp/ip-up.d/40-dns.sh:

-------------------------------------------------------------------------------------------------------------------------------

#!/bin/sh

# Handle resolv.conf generation when usepeerdns pppd option is being used.
# Used parameters and environment variables:
# $1 - interface name (e.g. ppp0)
# $USEPEERDNS - set if user specified usepeerdns
# $DNS1 and $DNS2 - DNS servers reported by peer

if [ "$USEPEERDNS" ]; then

	if [ -x /sbin/resolvconf ]; then
		{
			echo "# Generated by ppp for $1"
			[ -n "$DNS1" ] && echo "nameserver $DNS1"
			[ -n "$DNS2" ] && echo "nameserver $DNS2"
		} | /sbin/resolvconf -a "$1"
	else
		# add the server supplied DNS entries to /etc/resolv.conf
		# (taken from debian's 0000usepeerdns)

		# follow any symlink to find the real file
		REALRESOLVCONF=$(readlink -f /etc/resolv.conf)
	
		if [ "$REALRESOLVCONF" != "/etc/ppp/resolv.conf" ]; then

			# merge the new nameservers with the other options from the old configuration
			{
				grep --invert-match '^nameserver[[:space:]]' $REALRESOLVCONF
				cat /etc/ppp/resolv.conf
			} > $REALRESOLVCONF.tmp

			# backup the old configuration and install the new one
			cp -dpP $REALRESOLVCONF $REALRESOLVCONF.pppd-backup
			mv $REALRESOLVCONF.tmp $REALRESOLVCONF
	
			# correct permissions
			chmod 0644 /etc/resolv.conf
			chown root:root /etc/resolv.conf
		fi
	fi

fi

--------------------------------------------------------------------------------------------------------------------------------

the software is aware of two resolv.confs, one under /etc/, one under
/etc/ppp. /etc/ppp/resolv.conf is correctly filled in, but the other
is wiped. Can anyone see why?

MW

Re: [gentoo-user] ppp-gentoo woes cont'd [SOLVED-sorta]

[Joshua Murphy]

On Wed, Mar 28, 2012 at 4:05 PM, Maxim Wexler <maxim.wexler@gmail.com> wrote:
>>>
>>>> with ppp connections you are not using a dhcp client, pppd gets the
>>>> nameserver ip addressess as part of the connection negotiation (if
>>>> peerdns is set) and the aforemetioned script in
>>>> /etc/ppp/ip-up.d/40-dns.sh writes those to /etc/resolv.conf
>
> This is at the top of /etc/resolv.conf
> # Generated by dhcpcd
> # /etc/resolv.conf.head can replace this line
> # /etc/resolv.conf.tail can replace this line
>
> But according to /var/log/messages:
>
> Mar 28 13:24:01 lumby pppd[16825]: primary   DNS address 75.153.176.1
> Mar 28 13:24:01 lumby pppd[16825]: secondary DNS address 75.153.176.9
>
> But whatever is in resolv.conf is overwritten with blanks AFTER I
> connect. Which creates this odd situation where I can ping numbers,
> ie, 8.8.8.8 but not com, net, org etc.
>
> Once I "connect" I have to echo the DNS addresses into resolv.conf
> before I can reach anything.
>
> Also, I notice whenever I set up a route to my router those numbers
> get wiped. Is that the default behavio(u)r?. NB, I have nothing in the
> way of services other than ppp configured at all. Maybe later after I
> sort it all out I'll rig up something automatic.
>
> Thanks for everybody's hlp
>
> MW
>
> ps:  according to /etc/ppp/ip-up.d/40-dns.sh:
>
> -------------------------------------------------------------------------------------------------------------------------------
>
> #!/bin/sh
>
> # Handle resolv.conf generation when usepeerdns pppd option is being used.
> # Used parameters and environment variables:
> # $1 - interface name (e.g. ppp0)
> # $USEPEERDNS - set if user specified usepeerdns
> # $DNS1 and $DNS2 - DNS servers reported by peer
>
> if [ "$USEPEERDNS" ]; then
>
>        if [ -x /sbin/resolvconf ]; then
>                {
>                        echo "# Generated by ppp for $1"
>                        [ -n "$DNS1" ] && echo "nameserver $DNS1"
>                        [ -n "$DNS2" ] && echo "nameserver $DNS2"
>                } | /sbin/resolvconf -a "$1"
>        else
>                # add the server supplied DNS entries to /etc/resolv.conf
>                # (taken from debian's 0000usepeerdns)
>
>                # follow any symlink to find the real file
>                REALRESOLVCONF=$(readlink -f /etc/resolv.conf)
>
>                if [ "$REALRESOLVCONF" != "/etc/ppp/resolv.conf" ]; then
>
>                        # merge the new nameservers with the other options from the old configuration
>                        {
>                                grep --invert-match '^nameserver[[:space:]]' $REALRESOLVCONF
>                                cat /etc/ppp/resolv.conf
>                        } > $REALRESOLVCONF.tmp
>
>                        # backup the old configuration and install the new one
>                        cp -dpP $REALRESOLVCONF $REALRESOLVCONF.pppd-backup
>                        mv $REALRESOLVCONF.tmp $REALRESOLVCONF
>
>                        # correct permissions
>                        chmod 0644 /etc/resolv.conf
>                        chown root:root /etc/resolv.conf
>                fi
>        fi
>
> fi
>
> --------------------------------------------------------------------------------------------------------------------------------
>
> the software is aware of two resolv.confs, one under /etc/, one under
> /etc/ppp. /etc/ppp/resolv.conf is correctly filled in, but the other
> is wiped. Can anyone see why?
>
> MW
>

If I recall, this was my guess as the real problem you were running
into. As for what's making the last change to /etc/resolv.conf...
aside from kernel-level auditing, there's nothing I'm aware of that
can tell you. Since /etc/ppp/resolv.conf is correct but
/etc/resolv.conf isn't, one of three things is happening:

a) 40-dns.sh is running, making the changes it needs to, and they're
being promptly overwritten by something else... unlikely and
excessively hard to diagnose,
b) 40-dns.sh is running but isn't actually updating /etc/resolv.conf
properly... it looks fine, matches the default I have here (which
works on my pppoe setup at least), but could happen if one of the
assumptions it makes is wrong (or if, say, if [ "$USEPEERDNS" ]; is
coming up false), or...
c) 40-dns.sh is not even running, meaning /etc/resolv.conf never gets
updated by pppd... this would have been my first guess, except for the
fact that /etc/ppp/ip-up just outright sources all *.sh in
/etc/ppp/ip-up.d/ so... shouldn't be that (and I saved myself from
looking a bit silly, checking that beforehand).

The first step to tracking it down would probably be stepping through
that script and comparing it to your situation. Does
/etc/resolv.conf.pppd-backup exist? If so, it *is* at least making
changes to the original. I recall usepeerdns is set, so is
/sbin/resolvconf an existing, executable, file? If not, and since they
differ, I suspect it's failing somewhere in merging them. You might
add some echo calls writing out to a file in /tmp to 40-dns.sh so you
can track what, if anything, it does (and what values it's using in
the process).

My best guess, if it is 'a', is that something in the style of
networkmanager or the like, if you're running any such thing, is the
culprit, but that's pulled pretty solidly from thin air here.

-- 
Poison [BLX]
Joshua M. Murphy