I have installed net-dns/openresolv-3.4.1. I am using net-firewall/ipsec-tools-0.7.3-r1+xl2tpd-1.2.7 to establish l2tp. after ppp0 is created , It doesnt appear in /var/lib/run/resolvconf/interfaces/$IFACE . this suggest that resolvconf didnt add the device and the dns information from the ppp wasnt saved. so after establishing that l2tp , you dont query the right dns servers. Reproducible: Always Steps to Reproduce: I am using openrc and baselayout look at http://forums.gentoo.org/viewtopic-t-857417.html in the second post I bypass this issue by forcing the add of the dns servers. emerge --info Portage 2.1.9.25 (default/linux/x86/10.0, gcc-4.4.4, glibc-2.11.2-r3, 2.6.36-gentoo-r5 i686) ================================================================= System uname: Linux-2.6.36-gentoo-r5-i686-Intel-R-_Pentium-R-_4_CPU_2.80GHz-with-gentoo-2.0.1 Timestamp of tree: Fri, 28 Jan 2011 08:45:01 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] app-shells/bash: 4.1_p7 dev-java/java-config: 1.3.7-r1, 2.1.11-r1 dev-lang/python: 2.6.6-r1, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1-r1 sys-apps/openrc: 9999 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.7.9-r2, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.1.2, 4.3.4, 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* @EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib/fax /usr/share/config /usr/share/openvpn/easy-rsa /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.ovh.net/gentoo-distfiles/ http://mirror.switch.ch/ftp/mirror/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://mirror.hamakor.org.il/pub/mirrors/gentoo/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/sunrise /usr/local/portage/layman/tante /usr/local/portage/layman/zugaina /usr/local/portage_overlay" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aac acl acpi alsa amr avahi berkdb bidi bluetooth bzip2 cairo caps cdparanoia cli cracklib crypt cups cxx dbus djvu dri dts fbcon ffmpeg flac fortran gdbm gif gpm gsm gstreamer gtk hal iconv jack jpeg laptop ldap lirc mjpeg mmx modules mp3 mp4 mudflap mysql ncurses nls nptl nptlonly opengl openmp pam pcre perl png pppd pulseaudio python qt4 readline samba semantic-desktop session speex spell sse sse2 ssl sysfs tcpd theora tiff truetype unicode usb v4l v4l2 vorbis win32codecs x264 x86 xcomposite xinerama xorg xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DVB_CARDS="tda1004x tda10045 tda10046" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIRC_DEVICES="hauppauge devinput" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="radeon v4l displaylink" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
when running xl2tpd -D I see: xl2tpd[17870]: start_pppd: I'm running: xl2tpd[17870]: "/usr/sbin/pppd" xl2tpd[17870]: "passive" xl2tpd[17870]: "nodetach" xl2tpd[17870]: ":" xl2tpd[17870]: "debug" xl2tpd[17870]: "file" xl2tpd[17870]: "/etc/ppp/options.l2tpd.client" so I looked in /etc/ppp/ip-up.d/40-dns.sh and see: 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" echo "40-dns.sh ran resolvconf using $DNS1 and $DNS2" >>/var/log/messag so the question now is , under what circumstance wont DNS1 and 2 be set
Created attachment 262059 [details, diff] patch 40-dns.sh in ppp to solve issue seems that we need to wait 2 seconds before adding ppp0 to openresolv. I came up with a general solution that loops until the device is added, or timeout (/20 sec) is reached
I think the problem is actually a race between dhcpcd and ppp? I see the same problem but debugging closer I see that 40-dns.sh *is* correctly updating openresolv, however, a few ticks later, dhcpcd deletes the new resolv.conf configuration.... The chain appears to be /lib/dhcpcd/dhcpcd-run-hooks calls /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf, which in turn runs this code: elif $if_down; then remove_resolv_conf I haven't debugged enough to see why it's calling the if_down option though. Perhaps what happens is that the ppp interface is initially created "down" and then brought up later? In any case the issue is that 40-dns.sh is getting run while dhcpcd is still sorting itself out and settling My process list looks something like: RUSER PID PPID PGID COMMAND root 1817 1 1817 /sbin/dhcpcd -q root 20241 1 20241 /usr/sbin/pppd /dev/ttyUSB2 unit 1 linkname ppp1 defaultmetric 4013 maxfail 0 persist file /etc/ppp/options.ppp1 root 20290 1817 1817 /bin/sh /lib/dhcpcd/dhcpcd-run-hooks root 20291 20241 20291 /bin/sh /etc/ppp/ip-up ppp1 /dev/ttyUSB2 921600 4.3.2.1 1.2.3.4 root 20293 20291 20291 /bin/sh /sbin/resolvconf -a ppp1 root 20294 20290 1817 /bin/sh /sbin/resolvconf -d ppp1 -f I'm not sure what is the best solution here. We obviously need to somehow delay the openresolv stuff until dhcpcd has settled? There is presumably some way to monitor the what dhcpcd is doing other than checking for processess? Any ideas?
Hmm, solutions seem to be: - Don't run dhcpcd on ppp interfaces - Tell dhcpcd not to run the resolv hook on that interface What seems to happen at least in my case is that pppd is setting an initial IP, then later changing the remote ip. This appears to cause dhcpcd to run twice to bring the interface up and in the middle it does a "down", which erases the resolv stuff you just added in the ppp scripts I have gone for not running dhcpcd on my ppp interfaces at all since I can't see what they are bringing?
(In reply to comment #4) > Hmm, solutions seem to be: > > - Don't run dhcpcd on ppp interfaces > - Tell dhcpcd not to run the resolv hook on that interface > > What seems to happen at least in my case is that pppd is setting an initial IP, > then later changing the remote ip. This appears to cause dhcpcd to run twice > to bring the interface up and in the middle it does a "down", which erases the > resolv stuff you just added in the ppp scripts > > I have gone for not running dhcpcd on my ppp interfaces at all since I can't > see what they are bringing? here is how I came across this issue, my setup is this: 1. my pc eth0 is connected to a modem and gets an IP in the internet via my ISP. 2. I then issue a ppp connection to a l2tp server and get a new IP address to the internet. so I can access the internet using two different IP address and gateways. 3. so I can access the ppp dns service or the eth0 dns service. this is why I use openresolv to allow both in the right priority. 4. I use dhcp to establish the IP address on both devices. 5. In case ppp is alive I want it to be the default gateway. otherwise eth0 supplies the default gateway. this is why I use dhcpcd on both. to manage it dynamically and in case ppp drops ,I can still access the pc.
Please also see bug #359069 which resolves a problem after a demand dial interface drops I mailed Roy about this on the dhcpcd mailing list and added some extra info there. Basically PPP is being a bit silly and if you debug it, it seems to first add a temp IP, then drop it, then bring up the real IP. This triggers dhcpcd to run three times and the middle run (ip changed) causes it to blank out the resolv.conf info (erasing what you setup in the ppp resolv.conf) I think the best solution is to let PPP handle resolve.conf and disable dhcpcd from trying to handle it *for that interface*. So I think you end up with something like: /etc/dhcpcd.conf: interface ppp0 nohook resolv Arguably this bug can stay open for someone else to look at, but I don't think it can be resolved with a simple code change because it's a fairly large disagreement between how PPP is assigning IP addresses and dhcpcd is reacting on a change of IP address. The workaround above is sufficient, but clearly not clean This should at least get you working? Note: I am unconvinced there are many benefits in running dhcpcd at all on PPP interfaces (on linux)? See Roys answer on his mailing list also? Metrics can be set for the PPP interface using "defaultmetric xxx"
Is that dup of bug#400845?
Hello net-dialup, I think this is more related to you guys, as it is not specific to openresolv.
*** Bug 384883 has been marked as a duplicate of this bug. ***
*** Bug 490334 has been marked as a duplicate of this bug. ***
