When dialing with persist, after line drops pppd does not redial. The following is logged: pppd[24022]: Connection terminated. pppd[24022]: tcflush failed: Input/output error pppd[24022]: Modem hangup pppd[24022]: tcsetattr: Invalid argument (line 988) pppd[24022]: tcsetattr: Invalid argument (line 1027) pppd[24022]: Exit. Reproducible: Always Steps to Reproduce:
I seem to have a similar problem here with a Speedtouch ADSL-Modem, previous versions worked fine for one month in a row: Dec 12 21:16:41 [pppd] LCP terminated by peer Dec 12 21:16:41 [pppd] Connect time 480.1 minutes. Dec 12 21:16:41 [pppd] Sent 3043544 bytes, received 108077396 bytes. Dec 12 21:16:44 [pppd] Connection terminated. Dec 12 21:16:44 [pppd] Using interface ppp0 Dec 12 21:16:44 [pppd] Connect: ppp0 <--> /dev/pts/12 Dec 12 21:16:44 [pppoa2] Starting PPPoA2 ( merged version includes new ATM/AAL5 stack ) 1.3.1_ Dec 12 21:16:44 [pppoa2] I'm the parent process, I handle the endpoint 0x07_ Dec 12 21:16:44 [pppoa2] pusb_claim_interface 1 failed_ Dec 12 21:16:45 [pppd] Modem hangup Dec 12 21:16:45 [pppd] Connection terminated. The list of changes in ppp-2.4.3 is available from http://ppp.samba.org/ftp/unpacked/ppp/README
I don't see why these bugs are related. Please give more information (useflags - necessary to see which patches were applied, emerge info, options,...).
We both seem to have the same behavior since an upgrade to ppp-2.4.3, namely that after the line drops the automatic reconnect is not working any more although the option "persist" is specified. And we both know it was working before upgrading to ppp-2.4.3. Isn't that enough similarity? einfo (no useflag change since some time now): Portage 2.0.51-r8 (gcc34-x86-2004.2, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-ck3 i686) ================================================================= System uname: 2.6.9-ck3 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz Gentoo Base System version 1.6.7 Python: dev-lang/python-2.3.4,dev-lang/python-2.2.3-r5 [2.3.4 (#1, Sep 28 2004, 22:57:25)] dev-lang/python: 2.3.4, 2.2.3-r5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.8.5-r2, 1.4_p6, 1.9.3, 1.6.3, 1.7.9 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.2-r7 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" DISTDIR="/dat4/gentoo-cvs/distfiles" FEATURES="autoaddcvs candy ccache cvs distlocks noauto noinfo sandbox strict userpriv" GENTOO_MIRRORS="ftp://gentoo.inode.at/source/ http://gentoo.inode.at/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib acpi acpi4linux alsa apache2 apm arts audiofile avi berkdb bitmap-fonts bluetooth caps cddb cdparanoia cdr clamav crypt cups curl dba dga divx4linux dvd encode esd exif f77 fftw flac foomaticdb foreign-package foreign-sysvinit fortran freetype fs gd gdbm gif gimp gimpprint gphoto2 gpm gtk gtk2 guile imagemagick imlib ipv6 jack java jpeg jpeg2k junit kde libg++ libwww lzw mad maildir mbox mikmod mmx mng monkey motif moznomail mpeg mpi mysql nas ncurses nls nocardbus nvidia oggvorbis ooo-kde opengl oss pam pdflib perl png ppds python qt quicktime readline ruby samba scanner sdl session slang sox speex spell sqlite sse ssl svg svga tcltk tcpd tetex tiff truetype type1 usb videos wmf x86 xml xml2 xv zlib linguas_de" Useflags while emerging ppp (I masked 2.4.3 for now): # ep ppp These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-dialup/ppp-2.4.2-r9 -activefilter -atm -debug -dhcp +ipv6 -mppe-mppc +pam 0 kB
same problem here. doesn't matter whether it's called directly or from net.ppp0. # emerge -pv ppp These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-dialup/ppp-2.4.3 -activefilter -atm -debug -dhcp +gtk +ipv6 -mppe-mppc +pam 0 kB
after some struggle with rp-pppoe (pppoe-server does not work with ppp-2.4.3), I managed to create a test configuration with following: - rp-pppoe + ppp-2.4.2-r9 on server part (command: pppoe-server -F) - rp-pppoe + ppp-2.4.3 on client part (command: pppd eth0 nodetach debug persist lcp-echo-interval 2 lcp-echo-failure 2) the setup worked as expected. the client restarted connection after I've restarted the pppoe-server process. Note: the "holdoff" and "maxfail" pppd should be set accordingly with your needs.
Can you clarify. Are you saying that you have a fix for the problem? Or, are you saying that there's no problem with pppd persisting??!! I don't have DSL to test with, all I have is modem dialup, and it just does not work!
veezi, did you set following params: holdoff, maxfail, lcp-echo-interval and lcp-echo-failure ? I suggest to put at least holdoff 3 maxfail 0 lcp-echo-interval 10 lcp-echo-failure 3. "just doesn't work" isn't too constructive, doesn't it? you must cooperate with us if you want your problem to be fixed. I don't have a test configuration and all I could came up was a test pppoe connection between my main computer and my laptop.
Sorry for not being constructive. I do appreciate all the hard (and free of charge) work done by all Gentoo developer volunteers. Ok, I tried adding "holdoff 3 maxfail 0 lcp-echo-interval 10 lcp-echo-failure 3". I'm getting the same tcsetattr errors (please see my first comment in this bug for the pppd log) and pppd exits without redialing. Thanks,
Same problem here with ppp-2.4.3 an manualy configured pppoe with rp-pppoe.so plugin (t-online DSL). reconnect fails since update from ppp-2.4.2. It seems that maestro paulus at http://www.samba.org/ppp has made some CVS-Changes (look at CVS-Bugs) that might be related to this problem. Something about datastructures which are not cleaned up when connection is dropped from outside. So I'm looking ahead to the next version, and maybe we should better test before marking it as stable. Dowgrading to the last 2.4.2 could go around for those who cannot wait. ervin
I didn't mark 2.4.3 as stable; don't worry, no one is going to mark a version with open bugs as stable. If you have a patch to propose, I'm anxious to see it.
I've forgotten that net-dialup/ppp ~x86 is in my package.keywords file. Excuse me. I started fundamental work: ebuild /usr/portage/net-dialup/ppp/ppp-2.4.3.ebuild unpack creates the sourcetree in /var/tmp/portage/ppp-2.4.3/work/. In ppp-2.4.3/pppd I found the mentioned sourcefiles I'm studying http://samba.org/cgi-bin/ppp-bugs/CVS?user=guest now and (bug #1105) seems to meet the problem. The patch updates auth.c from 1.101 to 1.102: http://www.samba.org/cgi-bin/cvsweb/ppp/pppd/auth.c?r1=1.101&r2=1.102 Then there are typos in options.c (bug #1103): http://samba.org/cgi-bin/ppp-bugs/CVS?id=1103;user=guest DLT_PPP_WITH_DIRECTION should be replaced with DLT_PPP_WITHDIRECTION Because of changes by previous patches initiated by 'ebuild unpack' I did not try the patch and did only a sed -i 's/DLT_PPP_WITH_DIRECTION/DLT_PPP_WITHDIRECTION/g' options.c after that I ran ebuild /usr/portage/net-dialup/ppp/ppp-2.4.3.ebuild compile and after it came to end an ebuild /usr/portage/net-dialup/ppp/ppp-2.4.3.ebuild qmerge installs everything. I restarted the pppd by /etc/init.d/net.ppp0 restart tested the connection and waited for the external termination. and: ppd is still not reconnecting, the pppd related log: Jan 9 00:41:00 postbote pppd[21231]: LCP terminated by peer Jan 9 00:41:00 postbote pppd[21231]: Connect time 1440.1 minutes. Jan 9 00:41:00 postbote pppd[21231]: Sent 8764247 bytes, received 35422454 bytes. Jan 9 00:41:00 postbote pppd[21231]: Script /etc/ppp/ip-down started (pid 17781) Jan 9 00:41:00 postbote pppd[21231]: Couldn't increase MTU to 1500 Jan 9 00:41:00 postbote pppd[21231]: Couldn't increase MRU to 1500 Jan 9 00:41:00 postbote pppd[21231]: sent [LCP TermAck id=0xc] Jan 9 00:41:00 postbote pppd[21231]: Script /etc/ppp/ip-down finished (pid 17781), status = 0x0 Jan 9 00:41:03 postbote pppd[21231]: Connection terminated. Jan 9 00:41:03 postbote pppd[21231]: PADS: Service-Name: '' Jan 9 00:41:03 postbote pppd[21231]: PPP session is 4973 Jan 9 00:41:03 postbote pppd[21231]: using channel 3 Jan 9 00:41:03 postbote pppd[21231]: Connect: ppp0 <--> eth0 Jan 9 00:41:03 postbote pppd[21231]: Couldn't increase MTU to 1500 Jan 9 00:41:03 postbote pppd[21231]: Couldn't increase MRU to 1500 Jan 9 00:41:03 postbote pppd[21231]: sent [LCP ConfReq id=0x2 <mru 1492> <magic 0x1e6ce628>] Jan 9 00:41:03 postbote pppd[21231]: Modem hangup I checked this at 9:14 and found with ps -A | grep pppd that pppd consumed 8h:27min at cpu-time. That means pppd is processing some kid of endless loop and is waiting for something that did not happen. The earlier versions print some 'connection terminated' entry to the logfile, the patches did change nothing to that behaviour, but the loop must reside between those log messages. At this point I'll pause for code view, reading gentoo dev docs and debugging. ervin
I've included in 2.4.3-r1 fixes for upstream bugs 1103-1106. Please keep us informed if you find a fix for this issue.
The patch doesn't work because it's against some kind of CVS version. You must delete all changes of '#define RCSID "$Id: fixes-from-upstream-cvs.patch,v 1.1 2005/01/09 13:54:23 mrness Exp $"' from the patchfile.
RCSID lines removed.
I have the same problem with the pppd 2.4.3 and 'persist' pppd option with the 'pon' script that runs 'ppp call provider'. Jan 23 01:10:35 security pppd[9503]: pppd 2.4.3 started by root, uid 0 Jan 23 01:11:22 security pppd[9503]: Serial connection established. Jan 23 01:11:22 security pppd[9503]: using channel 1 Jan 23 01:11:22 security pppd[9503]: Using interface ppp0 Jan 23 01:11:22 security pppd[9503]: Connect: ppp0 <--> /dev/ttyS1 ... Jan 23 01:17:26 security pppd[9503]: sent [LCP EchoReq id=0x6 magic=0x64e9bf45] Jan 23 01:17:27 security pppd[9503]: rcvd [LCP EchoRep id=0x6 magic=0xc893f6ec] Jan 23 01:17:43 security pppd[9503]: Hangup (SIGHUP) Jan 23 01:17:43 security pppd[9503]: Modem hangup Jan 23 01:17:43 security pppd[9503]: Connect time 6.3 minutes. Jan 23 01:17:43 security pppd[9503]: Sent 46604 bytes, received 742142 bytes. Jan 23 01:17:43 security pppd[9503]: Script /etc/ppp/ip-down started (pid 9713) Jan 23 01:17:43 security pppd[9503]: Connection terminated. Jan 23 01:17:43 security pppd[9503]: Script /etc/ppp/ip-down finished (pid 9713), status = 0x0 Jan 23 01:17:46 security pppd[9503]: tcgetattr: No such device or address (line 933) Jan 23 01:17:47 security pppd[9503]: tcsetattr: No such device or address (line 1027) Jan 23 01:17:47 security pppd[9503]: Exit. Persistent dialup connection fails on reconnect from time to time with the above errors in syslog. After downgrading to the ppp-2.4.2-r10 the problem disappeared.
I found this discussion (especially the last 3 messages): http://news.gmane.org/find-root.php?message_id=%3c05011913351800.04070%40sevencardstud.cable.nu%3e But it doesn't help me solve the problem. There is a bug report by Ervin Peters: http://ppp.samba.org/cgi-bin/ppp-bugs/incoming?id=1110;user=guest
Created attachment 58127 [details, diff] ppp-bug1135.diff can you please test if this patch fixes the persist bug? taken from: http://ppp.samba.org/cgi-bin/ppp-bugs/CVS?id=1135
I've commited r2 with all current upstream CVS patches applied. please test it and post the results.
Hi Alin! 1. persist is working again. That's great. 2. ebuild has a big bug on amd64. That's odd. ;-) This is how the plugins should be installed: /usr /usr/lib /usr/lib/pppd /usr/lib/pppd/2.4.3 /usr/lib/pppd/2.4.3/dhcpc.so /usr/lib/pppd/2.4.3/minconn.so /usr/lib/pppd/2.4.3/passprompt.so /usr/lib/pppd/2.4.3/passwordfd.so /usr/lib/pppd/2.4.3/radattr.so /usr/lib/pppd/2.4.3/radius.so /usr/lib/pppd/2.4.3/radrealms.so /usr/lib/pppd/2.4.3/rp-pppoe.so /usr/lib/pppd/2.4.3/winbind.so That output is taken from my Pentium-3 machine (ebuild ... install). It just works perfectly. Now the same ebuild on amd64: /usr /usr/lib /usr/lib64 /usr/lib64/dhcpc.so /usr/lib64/minconn.so /usr/lib64/passprompt.so /usr/lib64/passwordfd.so /usr/lib64/radattr.so /usr/lib64/radius.so /usr/lib64/radrealms.so /usr/lib64/rp-pppoe.so /usr/lib64/winbind.so /usr/lib/pppd /usr/lib/pppd/2.4.3 as you can see, all plugins are installed into /usr/lib64 ('lib64' is ok, since there's a symlink /usr/lib64 -> /usr/lib). But as you can also see: /usr/lib/pppd/2.4.3 is EMPTY! This is how 'capi4k-utils-20050322-r1' installs its pppd-plugins: /usr/lib/pppd/2.4.2/capiplugin.so /usr/lib/pppd/2.4.2/userpass.so /usr/lib/pppd/2.4.3/capiplugin.so /usr/lib/pppd/2.4.3/userpass.so So I think, 'ppp' should install all plugins into /usr/lib/pppd/2.4.3 (ignoring the fact, that 'lib' is a symlink to 'lib64'). But currently, 'ppp-2.4.3-r2' is broken on amd64!
Hi Stefan, Can you try to identify the problem and come up with a patch? I don't have any amd64 machine, so I am unable to do it myself.
hmmm, I think I see the problem: you're using 'dolib.so' to install the plugins. This funtion installs all Plugins to ${D}/usr/lib64 on 64-Bit machines (I assume that this is true on *all* 64-Bit machines, not just amd64). Code in question: dodir /usr/lib/pppd/$(awk -F '"' '/VERSION/ {print $2}' pppd/patchlevel.h) mv ${D}/usr/lib/*.so ${D}/usr/lib/pppd/$(awk -F '"' '/VERSION/ {print $2}' pppd/patchlevel.h) You assume that 'dolib.so' had installed all plugins into ${D}/usr/lib (which is wrong on amd64). So you find nothing and move nothing. As a result, /usr/lib/pppd/2.4.3 is empty and the plugins in /usr/lib64 are still existing. Perhaps something like this would help: [ -d ${D}/usr/lib64 ] && LIBDIR=/usr/lib64 || LIBDIR=/usr/lib dodir ${LIBDIR}/pppd/$(awk -F '"' '/VERSION/ {print $2}' pppd/patchlevel.h) mv ${D}${LIBDIR}/*.so ${D}${LIBDIR}/pppd/$(awk -F '"' '/VERSION/ {print $2}' pppd/patchlevel.h) But maybe $LIBDIR is set by portage in a special variable yet and can be used.
I looked how other ebuilds handle this problem. I think, this is the best version: ---8<-------8<-------8<-------8<-------8<----- dodir /usr/lib/pppd/$(awk -F '"' '/VERSION/ {print $2}' pppd/patchlevel.h) mv ${D}/usr/{lib,lib64}/*.so ${D}/usr/lib/pppd/$(awk -F '"' '/VERSION/ {print $2}' pppd/patchlevel.h) [ -d ${D}/usr/lib64 ] && rmdir ${D}/usr/lib64 ---8<-------8<-------8<-------8<-------8<----- This way, everything is always installed into /usr/lib. I create a patch and test it.
Created attachment 58343 [details, diff] ppp-2.4.3-r2.ebuild.patch ok, this works... ;-)
ty, Stefan. 2.4.3-r3 in CVS. I've choosed not to replace dolib.so with doins - no reason to complicate ebuild script. this bug is fixed, thank God!
nonetheless, it works now. ;) So keep in mind: dolib and friends is ok, as long ans you don't have to move some files from there to another place... *g*
