While setting up a machine that requires pppoe I ran into this problem: I'm using baselayout-2.0.0, openrc-9999 and ppp-2.4.4-r13 from your (uberlord's) git overlay. If I set username_ppp0 and password_ppp0 then ppp fails like this: Jan 29 19:45:19 [pppd] PPP session is 6738 Jan 29 19:45:19 [pppd] Using interface ppp0 Jan 29 19:45:19 [pppd] Connect: ppp0 <--> eth1 Jan 29 19:45:23 [pppd] LCP terminated by peer Jan 29 19:45:25 [pppd] Terminating on signal 15 Jan 29 19:45:26 [pppd] Connection terminated. Jan 29 19:45:26 [pppd] Modem hangup Jan 29 19:45:26 [pppd] Exit. I tracked this down to the point that the password is not being 'attached' to ppp correctly. I commented the password and added pppd_ppp0=( "password xxx" [...] ). Then ppp started as usual. This does not happen with current stable baselayout-1 so it's a regression.
$ emerge --info Portage 2.1.3.19 (uclibc/ppc, gcc-4.1.2, uclibc-0.9.28.3-r2, 2.6.24-efika ppc) ================================================================= System uname: 2.6.24-efika ppc G2_LE Timestamp of tree: Sun, 27 Jan 2008 09:00:01 +0000 app-shells/bash: 3.2_p17-r1 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.61-r1 sys-devel/automake: 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="ppc" CBUILD="powerpc-gentoo-linux-uclibc" CFLAGS="-Os -pipe" CHOST="powerpc-gentoo-linux-uclibc" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-Os -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer nodoc noinfo noman sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://192.168.0.2/ http://gentoo.virginmedia.com/" LDFLAGS="-Wl,-O1" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="bitmap-fonts bzip2 cli cracklib dhcp dri gnutls ipv6 midi mudflap ncurses openmp pcre ppc readline reflection session spl truetype-fonts type1-fonts uclibc unicode xorg zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter 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 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" ELIBC="uclibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="dummy fbdev v4l" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS $ cat /etc/conf.d/net modules=( "iproute2" ) config_eth0=( "192.168.0.1/24" ) #routes_eth0=( "default via 192.168.0.1" ) config_eth1=( null ) config_ppp0=( "ppp" ) link_ppp0="eth1" plugins_ppp0=( "pppoe" ) username_ppp0="xxxxxxxxxxxx@alice-dsl.de" #password_ppp0="xxxxxxxx" pppd_ppp0=( #"noauth" "defaultroute" "usepeerdns" "holdoff 3" "child-timeout 60" "lcp-echo-interval 15" "lcp-echo-failure 3" "password xxxxxxxx" noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp ) depend_ppp0() { need net.eth1 }
uhm.. uberlord is retired. I'm reassigning to "default assignee of selcted component".
You can always file openrc specific bugs at http://bugs.marples.name/enter_bug.cgi?product=OpenRC Please attach the output of /etc/init.d/net.ppp0 --debug start. Feel free to mask out the passwords, but leave everthing else intact.
ok. will use your bug tracker next time. I wasn't aware of it.. the package in your overlay does not have metadata.xml.
Created attachment 142962 [details] output of /e/i.d/net.ppp0 --debug start
Well, it looks like openrc is doing the right thing as it's printing the password to s-s-d on fd0 To verify that is working, we can do this echo foo | /sbin/start-stop-daemon --start --exec /bin/cat -- /proc/self/fd/0 And if it works, you should see foo * start-stop-daemon: /bin/cat died So it looks like the error is with ppp.
You shouldn't use just echo when sending the password because you must send the password *without* end-of-line. "echo -n" is the right way to pass the password.
(In reply to comment #7) > You shouldn't use just echo when sending the password because you must send the > password *without* end-of-line. "echo -n" is the right way to pass the > password. > printf "%s" "${password}" is what we do and is much more portable, as echo isn't
Well, echo is an internal sh command while printf is not and therefore the password will be briefly visible to a local user through "ps -ef | grep printf" command.
(In reply to comment #9) > Well, echo is an internal sh command while printf is not and therefore the > password will be briefly visible to a local user through "ps -ef | grep printf" > command. printf is a bultin for bash and dash. Surprisingly not for busybox.
So do we have a resolution here guys?
sorry, I haven't been around my DSL connection for some weeks and last week I just forgot about this bug. Back on topic: The following two commands succeed: $ printf "%s" "xxxx" | /usr/sbin/pppd unit 0 user xxxx@alice-dsl.de remotename ppp0 linkname ppp0 defaultroute usepeerdns holdoff 3 child-timeout 60 lcp-echo-interval 15 lcp-echo-failure 3 noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp plugin passwordfd.so passwordfd 0 defaultmetric 4004 maxfail 0 persist connect true plugin rp-pppoe.so eth1 nodetach and $ printf "%s" "xxxx" | start-stop-daemon --start --exec /usr/sbin/pppd --pidfile /var/run/ppp-ppp0.pid -- unit 0 user xxxx@alice-dsl.de remotename ppp0 linkname ppp0 defaultroute usepeerdns holdoff 3 child-timeout 60 lcp-echo-interval 15 lcp-echo-failure 3 noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp plugin passwordfd.so passwordfd 0 defaultmetric 4004 maxfail 0 persist connect true plugin rp-pppoe.so eth1 nodetach pppd is doing the "right thing", is it? So the error seems to be somewhere in openrc. I'm also seeing the correct output from comment #6: # echo foo | /sbin/start-stop-daemon --start --exec /bin/cat -- /proc/self/fd/0 foo * start-stop-daemon: /bin/cat died Do we have success reports about openrc starting pppd? My config might be wrong? [ I have neither upgraded to 0.2, which is in portage nor rebuild -9999 since the initial bug report ]
you can configure whether busybox uses printf as a builtin
vapier: I'm not sure, if you got this right: I'm not using busybox but a "normal" system. comment #10 was a general statement.
i was merely responding to Roy's analysis of printf/busybox-builtin ... i made no statement about anything else
Some password problems had been solved for baselayout1 in bug #134337. If the pppd daemonized, the function detach() in pppd/main.c closed descriptors 0, 1 and 2, so it was not possible to pass passwords via stdin. I've just upgraded and I have some problems with pppd too (something with updetach), so I will check it in the evening (CET time).
I confirm the problem here to when upgrading to openrc : Apr 16 19:09:37 xwing pppd[8861]: Plugin passwordfd.so loaded. Apr 16 19:09:37 xwing pppd[8861]: Plugin rp-pppoe.so loaded. Apr 16 19:09:37 xwing pppd[8861]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.4 Apr 16 19:09:37 xwing pppd[8862]: pppd 2.4.4 started by root, uid 0 Apr 16 19:09:52 xwing pppd[8862]: PPP session is 10039 Apr 16 19:09:52 xwing pppd[8862]: Using interface ppp0 Apr 16 19:09:52 xwing pppd[8862]: Connect: ppp0 <--> net Apr 16 19:09:55 xwing pppd[8862]: CHAP authentication failed: Authentication failed Apr 16 19:09:55 xwing pppd[8862]: CHAP authentication failed Apr 16 19:09:55 xwing pppd[8862]: Connection terminated. An other way to work arround the problem is to add the "updetach" option to pppd_ppp0. But it sounds a bit weird since it will hang the boot if ADSL does not goes up correctly for any reason...
I tried to play with file descriptors for passing password, but without any success - because the startup script is using /bin/sh, not /bin/bash. So I cannot say if the problem is somewhere here. I'm using simple pppd (no pppoe or others) and it works without "updetach". With "updetach" it fails for the first time and succeeds when pppd tries to connect for the second time automatically (on the background). But this might be another story...
Command like this works: printf "%s" "password" |/usr/sbin/pppd unit 0 user user8@isp.tld remotename ppp0 linkname ppp0 noipdefault noauth defaultroute usepeerdns mtu 1492 lcp-echo-interval 15 lcp-echo-failure 3 plugin passwordfd.so passwordfd 3 defaultmetric 4006 maxfail 0 persist connect true plugin rp-pppoe.so eth1 3<&0 fd 3 is not closed by pppd when detach. But the start-stop-daemon(/sbin/rc) closes fd 3..1023 (RLIMIT_NOFILE)
Created attachment 156991 [details, diff] add --dont-closefd option to openrc
Created attachment 157049 [details, diff] little changes
Not going to fly as you're using bashisms in the script (3<&0). To work with non bash shells, we kinda have to use fd 0. In my testing, s-s-d passes this just fine. So if pppd should be patched to accept fd 0, if indeed it is the bug here.
I can confirm that pppd close stdin/stdout/stderr in certain situations, but I think passwordfd plugin must be patched, not pppd. That plugin should read and store the password the moment it gets loaded. I will create a new ppp revision and ask you guys to test it. In the mean time, just don't use password_ppp0.
(In reply to comment #23) > I can confirm that pppd close stdin/stdout/stderr in certain situations, but I > think passwordfd plugin must be patched, not pppd. That plugin should read and > store the password the moment it gets loaded. > > I will create a new ppp revision and ask you guys to test it. In the mean time, > just don't use password_ppp0. > IMHO you should rather integrate passwdfd plugin into the pppd's source code. The plug-in architecture design is inconsistent with parsing argumetns in plug-in. Or it must read passwd allways from stdin(0), without parsing any option. Or we can use /etc/ppp/pap-secrets like anybody else.
Created attachment 157809 [details, diff] passwordfd-read-early.patch Guys, please test the attached patch. This will read password from file descriptor as soon as option parser interprets "passwordfd" string.
Fixed (I hope) in ppp-2.4.4-r16. None of you seems interested in testing my patch... Nice to see so many users ready to help you when you're working to fix their problem. :-/
