It appears that ppp interfaces are broken when used with pptp for connecting to a vpn. I'm not sure if this is specific to my version of baselayout, but the problem goes as such: ppp is configured properly in /etc/conf.d/net. I've been through all of the options and chosen the ones appropriate to my configuration. The same options, when used with the pon command, work just fine. However, when used with an initscript, ppp will not work. I isolated the problem to the modules being loaded in /etc/init.d/net.ppp0 (which is a symlink to net.lo, as it should be). As the initscript runs, before the connection to the vpn is made, one of the loaded modules (presumably dhcpcd) overwrites /etc/resolv.conf with nothing. When the interface attempts to connect to the host (by hostname), the address will not resolve, and the connection fails. Note that resolv.conf is not overwritten by pptp, as no connection is ever made to the vpn. I've (temporarily) solved the problem by adding an if block to /etc/init.d/net.lo as follows: if [[ ${iface} != 'ppp0' ]]; then # pre Start any modules with for mod in ${MODULES[@]}; do einfo ${mod} if is_function "${mod}_pre_start" ; then ${mod}_pre_start "${iface}" || { eend 1; return 1; } fi done fi Obviously, this isn't the best solution. For my purposes, ppp0 now works, as it seems like the functionality that is typically provided by these modules exists in pptp. However, this looks like it may be a legitimate bug... Here's my /etc/conf.d/net: dns_options=( "timeout 1" "rotate" "inet6 false" ) config_eth0=( "dhcp" ) dhcpcd_eth0="-t 5" modules_ath0=( "wpa_supplicant" ) wpa_supplicant_ath0="-Dwext" config_ath0=( "dhcp" ) dhcpcd_ath0=( "-t 10" ) config_ppp0=( "ppp" ) pppd_ppp0="usepeerdns require-mschap-v2 refuse-eap refuse-chap refuse-mschap updetach noauth nobsdcomp nodeflate mppe required,stateless mtu 1000 mru 1000 ipparam pptp" username_ppp0="<myusername>" password_ppp0="<mypassword>" link_ppp0="pty \"pptp <myvpnserver> --nolaunchpppd\"" postup(){ if [[ ${IFACE} = "ppp0" ]]; then /sbin/route add -net <mysubnet> netmask 255.255.255.0 dev ppp0 fi return 0; } Let me know if I'm just doing something wrong... Reproducible: Always Steps to Reproduce: 1.Configure ppp0 in /etc/conf.d/net 2.Bring up the interface ppp0
Please post your `emerge --info' too.
Portage 2.1.4.4 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-tuxonice-r9 i686) ================================================================= System uname: 2.6.24-tuxonice-r9 i686 Intel(R) Pentium(R) M processor 1600MHz Timestamp of tree: Mon, 22 Sep 2008 07:01:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r13, 2.5.2-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium-m -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O3 -march=pentium-m -fomit-frame-pointer -pipe" DISTDIR="/var/portage/distfiles" FEATURES="distlocks fixpackages metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" 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 /usr/portage/local/layman/enlightenment /usr/portage/local/layman/enlightenment" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aac acl acpi alsa asf berkdb bluetooth branding bzip2 cairo cdr cli cracklib crypt ctype cups daap dbus dri dvd dvdr dvdread eds emboss encode esd evo fam firefox fortran gdbm gif gpm gstreamer hal iconv ipod ipv6 isdnlog jpeg kde kerberos ldap libnotify mad midi mikmod mono mp3 mpeg mplayer mudflap mysql ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcmcia pcre pdf perl png ppds pppd python qt qt3 qt3support qt4 quicktime readline reflection sdk sdl session soap spell spl ssl startup-notification svg sysfs tcpd tiff truetype unicode usb userlocales vorbis wifi win32codecs x86 xinerama xml xorg xv 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 auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics joystick" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="radeon vesa fbdev" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
net-dialup handle ppp, not base-system or me.
If you use the DNS name of your VPN server, you must be sure you can resolve that name with the /etc/resolv.conf you have prior to PPP interface startup. This can be done in various ways (see /etc/conf.d/net.example) but you probably want something like this: dns_servers_eth0=( local_dns_server_address ) dhcp_eth0="nodns" Closed as INVALID.
So that I'm clear on what you mean here... Wouldn't I rather have that as an option for ppp0? So something more like dhcp_ppp0="nodns" Or is that not valid? Wouldn't this prevent me from getting the VPN side's dns servers and adding them to resolv.conf? That's not what I want at all. Your solution, on the other hand, implies that I'm only ever going to be using one DNS server with eth0. That's absolutely not true. Unless I'm missing something, the problem is inherent in the order in which the steps described take place. Unfortunately, I can't test this, since it's been so long since I submitted the ticket that I don't even own the machine I was working with any more...
Correct me if I'm wrong, but I understood your problem is that simply starting eth0 interface will overwrite your /etc/resolv.conf with an empty file. Assuming this is dhcp daemon who does that (probably because DHCP server doesn't provide a DNS server in the lease), here is the solution: dns_servers_eth0=( local_dns_server_address1 local_dns_server_address2 ... ) dhcp_eth0="nodns" Setting dhcp_ppp0 to nodns would be silly because: a) normally DHCP is not used over PPP links; if you are one of those unlucky folks that needs it, you have to use a pppd plugin for that (you have to install net-dialup/ppp with dhcp USE flag enabled) b) if you don't want ppp0 startup to affect your /etc/resolv.conf, you should remove "usepeerdns" from pppd_ppp0 Re-closed as INVALID. Please leave it as such.
Let me see if I can clarify, then. The problem was that when I started ppp0, the contents of /etc/resolv.conf were removed *before* the ppp connection was attempted. Since I was connecting to my vpn server as link_ppp0="pty \"pptp <myvpnserver> --nolaunchpppd\"" this meant that resolution of <myvpnserver> failed. As I mentioned, using the pon command seemed to get around this issue, and I had no problem connecting to the VPN and acquiring an IP address that way. It was only using the initscript that caused it to fail. For that reason, I'm curious - without compiling ppp with the dhcp use flag, would ppp be able to acquire an IP address at all? If so, then perhaps a) would work, despite being a convoluted solution. b) will not work, however, as the problem is not with ppp0 stomping on /etc/resolv.conf *once it has a connection*. The problem I describe happens with or without the usepeerdns flag.
Additional clarification: This has nothing to do with dns server settings for eth0, which (for all the networks I attach to) are provided by dhcp.
PPP protocol is designed to negociate connection parameters, including IP settings like remote/local IP address and DNS servers. Now to the point... net.pppX services will generate a /etc/resolv.conf only after the connection is negociated and only when usepeerdns option has been specified. However, I've looked into the baselayout-1.12.11.1 scripts and you're right. When a net.pppX interface gets started, system_pre_start function will generate a /etc/resolv.conf file containing only a line such as this: # Generated by net-scripts for interface ppp0 Judging after the comments above system_pre_start, this function should have been called system_post_start. Workarounds: 1) change function name to system_post_start 2) don't set dns_options or at least change the variable name into dns_options_eth0 Roy, latest openrc also appears to have this problem. I think you need to rename it as system_post_start, because PPP connections can provide DNS settings only after the link was started.
(In reply to comment #9) > Roy, latest openrc also appears to have this problem. I think you need to > rename it as system_post_start, because PPP connections can provide DNS > settings only after the link was started. Other things rely on it being _pre_start, so no. You could inject DNS from PPP by using a resolvconf implementation such as openresolv which is in portage.
What other things? Is it possible to create resolv.conf in _post_start for PPP interfaces while keeping current functionality for others? AFAIK resolvconf is not a requirement for openrc, so it is only a workaround for a known openrc bug.
(In reply to comment #11) > What other things? Is it possible to create resolv.conf in _post_start for PPP > interfaces while keeping current functionality for others? See bug #112049 http://sources.gentoo.org/viewcvs.py/baselayout/trunk/net/system.sh?rev=2449&view=log The commit indictates its so that PPP does not intefer with system defined settings > AFAIK resolvconf is not a requirement for openrc, so it is only a workaround > for a known openrc bug. No it's not a requirement, but it's a solution. PPP isn't a requirement for PPP either. And with the git OpenRC version, neither are the net modules. You could consider this a heads up that pppd support will be moving back to a proper init script. Don't panic - the net modules have not been punted yet, but they don't have a future either. Lastly, your analysis of this bug is incorrect. The reporters beef is that something is overwriting his resolv.conf "with nothing". baselayout/openrc and all dhcp clients write *something* to resolv.conf - at least a comment at the top of the file. Thus, this *something* that's writing his resolv.conf isn't baselayout/openrc or a DHCP client and as such not a baselayout/openrc or dhcp bug.
(In reply to comment #12) > And with the git OpenRC version, neither are the net modules. > You could consider this a heads up that pppd support will be moving back to a > proper init script. Don't panic - the net modules have not been punted yet, but > they don't have a future either. Ah. This seems like it would fix the problem. > > Lastly, your analysis of this bug is incorrect. The reporters beef is that > something is overwriting his resolv.conf "with nothing". baselayout/openrc and > all dhcp clients write *something* to resolv.conf - at least a comment at the > top of the file. Thus, this *something* that's writing his resolv.conf isn't > baselayout/openrc or a DHCP client and as such not a baselayout/openrc or dhcp > bug. > Sorry for the imprecision, but when I said "with nothing", I meant "with no useful nameservers." The line mentioned previously: # Generated by net-scripts for interface ppp0 is written over the existing contents of the file. Judging by my (hackish) fix, it's most likely written by one of the modules started during the normal net initscript.
Remove this line from your config dns_options=( "timeout 1" "rotate" "inet6 false" ) If you need to set that AND get data from PPP in there then you will need resolvconf as it's job is to merge this kinda stuff.
How about modifying system_dns() in such way that it will refuse to generate /etc/resolv.conf if no nameserver is provided? This shouldn't affect other scenarios, since a resolv.conf w/o nameservers is pretty useless.
(In reply to comment #14) > Remove this line from your config > dns_options=( "timeout 1" "rotate" "inet6 false" ) Based on the resolv.conf man page, it doesn't seem like removing this line would have any effect? Does presence of a dns_options line like this change the way that the initscripts work other than changing the options given on generation of resolv.conf? Can anyone involved confirm that any of these three options or the presence of the line in general is causing the overwriting of resolv.conf?
Hmm... While chatting about this with my friend, he pointed out the nodns flag as well. It seems that since ppp0 is using the dhcp module, adding dhcp_ppp0="nodns" should do the trick. If anyone can confirm this with an actual ppp interface, this bug should be re-closed as INVALID.
(In reply to comment #15) > How about modifying system_dns() in such way that it will refuse to generate > /etc/resolv.conf if no nameserver is provided? This shouldn't affect other > scenarios, since a resolv.conf w/o nameservers is pretty useless. It's possible, but what happens about the case where nameservers or a domain is supplied?
That's a good question. I would assume that since the argument for dhcp is given when the interface is being brought up (before the ppp connection is established), the usepeerdns option for pppd would make it responsible for handling receipt of information from the server side.
Let me clarify what I mean. IMO this is how the function should look like: system_dns() { ... # Support resolvconf if we have it. if [[ -x /sbin/resolvconf ]] ; then echo -e "${buffer}" | resolvconf -a "${iface}" elif [ -n ${!servers} ] ; then echo -e "${buffer}" > /etc/resolv.conf chmod 644 /etc/resolv.conf fi } As you can see, resolv.conf will be generated only when at least one nameserver exists. Easy to do and unlikely to break anything else (as I've said earlier, a resolv.conf w/o nameservers is useless).
(In reply to comment #20) > As you can see, resolv.conf will be generated only when at least one nameserver > exists. Easy to do and unlikely to break anything else (as I've said earlier, a > resolv.conf w/o nameservers is useless). You cannot make that assumption - it's perfectly valid to have no nameservers in resolv.conf. In this instance, libc will assume 127.0.0.1 which some users expect. See resolv.conf(5) for details.
I wonder how many users that have a running DNS server/proxy on their localhost are willing to let baselayout create /etc/resolv.conf for them. ;)
Is this still applicable? I don't think so. I use PPP on my own router and it runs a much newer BL2 and runs a local DNS node. Please reopen if it's a problem still.
FWIW, i've been running openrc+pppoe for a while now too
