| View previous topic :: View next topic |
| Author |
Message |
CleanTestr
n00b
Joined: 15 Jan 2013
Posts: 47
Location: somewhere in Rural Nebraska, USA
|
 Posted: Wed May 08, 2013 4:05 pm Post subject: [SOLVED] nomultilb & openresolv: resolv.conf not updated |
 |
|
This is now Solved on x86 and multilib, which is 'good enough for me'
(using ppp -dhcp, without dhcp and openresolv)
I'm having some difficulty migrating a 'working' x86 pppd config (without openresolv) to amd64.
[Edit]
I 'like to run' dhcpcd so eth0 and wlan0 (under netplug) can get their info (when available), but I'd rather that ppp0
get its info from the ISP without dhcp.
I'm using:
net-dns/openresolv-3.3.4
net-dialup/ppp-2.4.5-r3 USE="ipv6 pam -activefilter -atm -dhcp -eap-tls -gtk -radius"
net-misc/dhcpcd-5.6.4 USE="zeroconf"
This combo will 'always' work under x86/desktop for any number of connect attempts per booted session.
Working around an issue in amd64, I've arrived at
| Code: | ln -s /etc/ppp/resolv.conf /etc/resolv.conf
|
to 'use the same config for x86 as for amd64'.. but it seems kludge-y
[/Edit]
It initially seemed to me that somehow the dhcpcd -- which I'm running, so that it may field eth0 and wlan0
requests -- (dhcpcd, which, according to what I read on the ppp man page, installs itself as a plug-in to ppp),
was getting an empty list of DNS nodes from the system, almost as though it were getting a -1 back
from glibc.
I traced the code back to statements in glib-2.17 about converting to Linux NetLink (architecture),
where the actuall API entry-point called by dhcpcd appears to be marked __hidden(..) __asm__ static int getifaddrs(..)
in the code, and the non-NetLink API 'function' is stubbed-out, with merely a set __errno( ENOSYS ); return -1; in its body.
That part of the discussion is here : https://forums.gentoo.org/viewtopic-t-962070.html
- - - * * * <snip> a whole bunch of emerge --info and such * * * - - -
The rest of this group of messages is about why does openresolv behave differently the first
time, than any subsequent invocation?
_________________
Stan: A signal? Why didn't you wake me?
790: It was a distress signal. They only lead to trouble, so I always ignore them. --Lexx
Last edited by CleanTestr on Sat Aug 10, 2013 9:11 am; edited 30 times in total |
|
| Back to top |
|
 |
lost+found
Guru
Joined: 15 Nov 2004
Posts: 509
Location: North~Sea~Coa~s~~t~~~
|
| Posted: Sun May 12, 2013 7:05 pm Post subject: |
|
|
Hi, maybe this is worth a try:
| Code: | | # emerge net-dns/openresolv |
and/or
/etc/sysctl.conf:
| Code: | | net.ipv4.ip_dynaddr = 1 |
| Code: | | # echo 1 > /proc/sys/net/ipv4/ip_dynaddr |
--
Cheers! |
|
| Back to top |
|
|
CleanTestr
n00b
Joined: 15 Jan 2013
Posts: 47
Location: somewhere in Rural Nebraska, USA
|
| Posted: Sun May 12, 2013 10:46 pm Post subject: |
|
|
It seems that 'various packages' may write to resolv.conf (notoriously: resolvconf
and network_manager; and now also your mention of openresolv).
But it seems to me that this 'new behavior' in dhcpcd. Or am I missing something?
..from the man page (dhcpcd):
| Quote: | ..dhcpcd then runs the configuration script which writes DNS information to resolvconf( 8 ),
if available, otherwise directly to /etc/resolv.conf.
|
..but, it seems to not be doing so.
Further on in the man page I find:
| Quote: | -F, --fqdn fqdn
Requests that the DHCP server updates DNS using FQDN..
..dhcpcd itself never does any DNS updates.
|
I take this to mean, that some program such as pppd must transact the DNS server, rather
than dhcpcd itself; not, that dhcpcd doesn't write DNS information to resolv.conf.
_________________
Stan: A signal? Why didn't you wake me?
790: It was a distress signal. They only lead to trouble, so I always ignore them. --Lexx |
|
| Back to top |
|
|
Sven Vermeulen
Retired Dev
Joined: 29 Aug 2002
Posts: 1345
Location: Mechelen, Belgium
|
| Posted: Sat May 18, 2013 6:09 pm Post subject: |
|
|
dhcpcd does write into resolv.conf, it doesn't do DNS updates. Those are two different things.
resolv.conf tells the system where the DNS servers are that the system should consult if a hostname needs to be resolved to an IP address (or vice-versa).
DNS updates themselves tell that an IP address a.b.c.d is for host "foobar" (and much, much more). What the manpage says is that dhcpcd (DHCP client) does not do DNS updates (i.e. changing the database where all that data is stored).
_________________
Please add "[solved]" to the initial topic title when it is solved. |
|
| Back to top |
|
|
CleanTestr
n00b
Joined: 15 Jan 2013
Posts: 47
Location: somewhere in Rural Nebraska, USA
|
| Posted: Wed May 22, 2013 11:25 pm Post subject: |
|
|
I've now observed this to happen also in
keyworded: ~amd64 dhcpcd-5.6.8
It may possibly have something to do with dhcp preserving state across
subsequent invocations, and not re-acquiring DNS information.
I tend to killall ppp to take the link down; after that command, I tend to see
this problem more often.
I haven't tried lost+found's suggestions, as yet.
_________________
Stan: A signal? Why didn't you wake me?
790: It was a distress signal. They only lead to trouble, so I always ignore them. --Lexx |
|
| Back to top |
|
|
CleanTestr
n00b
Joined: 15 Jan 2013
Posts: 47
Location: somewhere in Rural Nebraska, USA
|
| Posted: Wed May 22, 2013 11:51 pm Post subject: |
|
|
This does indeed have something to do with dhcpcd preserving state:
When I first invoke pppd call <something>, I get 3 processes running:
- pppd
- pppob (the pts virtual terminal)
- dhcpcd -q
If I then killall pppd pppob dhcpcd, then a subsequent pppd call <something>,
produces 2 processes running:
- pppd
- pppob (the pts virtual terminal)
and everything Works!
But if I don't kill dhcpcd (which I wasn't doing, since the Dawn of Time),
I observe the above failure.
to lost+found:
| Code: | | /proc/sys/net/ipv4/ip_dynaddr = 0 |
in /etc/sysctl.conf:
| Code: | | #net.ipv4.ip_dynaddr = 0 |
_________________
Stan: A signal? Why didn't you wake me?
790: It was a distress signal. They only lead to trouble, so I always ignore them. --Lexx |
|
| Back to top |
|
|
CleanTestr
n00b
Joined: 15 Jan 2013
Posts: 47
Location: somewhere in Rural Nebraska, USA
|
| Posted: Thu May 23, 2013 12:57 am Post subject: |
|
|
Furthermore, if I, in the middle of a pppd session, then dhcpcd -q &,
dhcpcd starts running, and trashes resolv.conf. Yee-Haw! 
_________________
Stan: A signal? Why didn't you wake me?
790: It was a distress signal. They only lead to trouble, so I always ignore them. --Lexx |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Thu May 23, 2013 9:29 am Post subject: |
|
|
You've not read what others have said and I'm the dhcpcd and openresolv author so please listen.
The default behavior of dhcpcd is to re-write resolv.conf each time a network event happens, such as obtaining or renewing a DHCP lease.
The default behavior of pppd is to re-write resolv.conf each time a network event happens, such as obtaining a PPP address.
This is not new behavior and has been a long standing default of nearly every nix based system since inception.
You indicate you've worked around this by editing /etc/dhcpcd.conf.tail, but your debug output shows otherwise. I suggest it may have been over-written in an update maybe?
I also suggest you emerge openresolv, a working resolvconf implementation specifically designed to solve the above problem in a standard way.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
CleanTestr
n00b
Joined: 15 Jan 2013
Posts: 47
Location: somewhere in Rural Nebraska, USA
|
| Posted: Thu May 23, 2013 2:26 pm Post subject: |
|
|
Ok. I'll try using openresolv.
If I:
then cat /etc/resolv.conf:
| Code: | # Generated by resolvconf
search my_domain
nameserver ...
nameserver ...
|
and resolvconf -l:
| Code: | # resolv.conf from lo
# Generated by net-scripts for interface lo
domain my_domain
# resolv.conf from ppp0
# Generated by ppp for ppp0
nameserver ...
nameserver ...
|
* Good! *, I *like* ...
If I now
and wait a bit, then
| Code: | pppd call isp
cat /etc/resolv.conf
|
shows
| Code: | # Generated by resolvconf
search my_domain
|
and resolvconf -l:
| Code: | # resolv.conf from lo
# Generated by net-scripts for interface lo
domain my_domain
|
So, no dice 
_________________
Stan: A signal? Why didn't you wake me?
790: It was a distress signal. They only lead to trouble, so I always ignore them. --Lexx |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
