autodial on demand with ppp works fine with net-dialup/ppp-2.4.2-r15, but does not work with any newer versions. with newer version the first connect does work, but when returning to inactive, no more connect happens on demand. I just pump all the info I have how I configured ppp and than I put some protocol which shows the behaviour: bharat ~ # emerge --info ======================== Portage 2.1.1_pre5-r3 (default-linux/x86/2005.1, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-gentoo-r6 i686) ================================================================= System uname: 2.6.16-gentoo-r6 i686 Mobile AMD Athlon(tm) XP 2600+ Gentoo Base System version 1.12.4 Last Sync: Fri, 25 Aug 2006 01:54:01 +0000 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.3.5-r2, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-mp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=athlon-mp -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.inode.at/ ftp://gentoo.inode.at/source/ ftp://213.186.33.38/gentoo-distfiles/ ftp://213.186.33.37/gentoo-distfiles/" LC_ALL="en_US.UTF-8" LINGUAS="" MAKEOPTS="-j2" 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'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/webapps-experimental /usr/portage/local/layman/java-migration-packages /usr/portage/local/layman/java-gcj-overlay /usr/portage/local/layman/java-experimental /usr/portage/local/layman/initng" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X accessibility acpi alsa apache2 avi bitmap-fonts cli crypt dbus dlloader dri eds elibc_glibc emacs emboss encode foomaticdb gdbm gif gnome gpm gstreamer gtk2 hal imlib input_devices_keyboard input_devices_mouse input_devices_synaptics ipv6 isdnlog jikes jpeg kernel_linux libg++ libwww mad mikmod minimal mmx motif mp3 mpeg ncurses nls nsplugin ogg oggvorbis opengl oss pam pcre pdflib png pppd python qt3 qt4 quicktime readline reflection sdl session spell spl sse ssl tcpd truetype truetype-fonts type1-fonts unicode userland_GNU userlocales video_cards_vesa video_cards_via vorbis xml2 xmms xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 95042 [details] some protocol which shows the behaviour
You specified /dev/phone twice, one in reliance script and the other in link_ppp0. Please add debug to pppd_ppp0 and post here the log.
Another redundancy... You use defaultroute option _and_ set routes_ppp0 to "default gw 192.168.0.1".
so I did remove the redundency you mentioned above. and produced some log files - see "protocol2" if I compare the ip-down script which is used in net-dialup/ppp-2.4.2-r15 and the ip-down.baselayout which is used in ppp-2.4.3 or later, than I miss the following lines: # Recreate the default route so autodial works [ -s /etc/conf.d/net ] && . /etc/conf.d/net if [ -n "${gateway}" ] && [ "${gateway%/*}" = "$1" ]; then /sbin/route add default dev ${gateway%/*} fi which is also reflected in the "route -n" output of protocol2
Created attachment 95054 [details] /var/log/messages
Do you know what kind of software is at the other end? The peer responds with some NAKs about MPPE, but you didn't asked for this encryption! Is it by any chance some flavor of BSD? I would try the following: 1) disable all types of compressions 2) set passive option Did you tried to use ppp-2.4.2 (the version you claim it works) with the new baselayout scripts (/etc/init.d/net.ppp0 symlinked to /etc/init.d/net.lo) or did you used the old net.ppp0 script?
I do have no idea which software runs on the otherside. it is one of the big indian telephone companies also providing internet access: www.reliancecommunications.co.in I did remove all compressions and set the passive mode, but still the same behaviour. but I did try a few more things: * emergeing the ppp-2.4.3 ebuild and after that I replaced the /etc/ppp/ip-down script with the /usr/portage/net-dialup/ppp/files/ip-down script. the latter is used in the ppp-2.4.2 ebuild. and with that the whole thing works as expected. * next I moved moved back the ip-down.baselayout and played around here as well. commenting out following lines, helped to get it working: #if [ -x /etc/init.d/net.$1 ]; then # if /etc/init.d/net.$1 --quiet status ; then # export IN_BACKGROUND="true" # /etc/init.d/net.$1 --quiet stop # fi #fi the moment I uncomment these line, after the idle timeout there is not default route anymore and ppp0 has no IP and netmask anymore. I do not know what these lines are doing, but here lies my problem.
You symlinked /etc/init.d/net.ppp0 to net.lo, right?
yes, it is symlink
Problem confirmed. Roy, the latest baselayout erase IP settings from ppp interface when /etc/ppp/ip-down is executed, namely when the link goes down. This prevent pppd from reactivating the link because reactivating the link is triggered by outgoing traffic through that interface. The command that reset ppp interface settings is export IN_BACKGROUND=true /etc/init.d/net.$1 --quiet stop I've found that ip-up and ip-down scripts always end up with ret code 1. Both scripts end up with a /etc/init.d/net.$1 command, therefore something in baselayout is utterly wrong.
(In reply to comment #10) > Problem confirmed. > > Roy, the latest baselayout erase IP settings from ppp interface when > /etc/ppp/ip-down is executed, namely when the link goes down. > This prevent pppd from reactivating the link because reactivating the link is > triggered by outgoing traffic through that interface. > > The command that reset ppp interface settings is > export IN_BACKGROUND=true > /etc/init.d/net.$1 --quiet stop This has been behaviour by design since baselayout-1.11 > > I've found that ip-up and ip-down scripts always end up with ret code 1. Both > scripts end up with a /etc/init.d/net.$1 command, therefore something in > baselayout is utterly wrong. baselayout is fine, ppp is broken. If ppp requires an IP address/route for dial on demand then when the link goes down it should NOT call ip-down (by definition, taking an ip down involves removing the ip address) OR the pppd module should add fake IP address in it's post_down section. Using ppp, you will always return 1 due to the re-entrant nature of ppp. net.eth0 will only return 0 if we never background - and we're always in the background for ppp.
(In reply to comment #11) > This has been behaviour by design since baselayout-1.11 Maybe, but when I made that pppd.sh, I tested dial-on-demand successfully. We used back then a wrapper to put the link in the inactive state, which didn't interfere with pppd on anything more than additional routes and metrics. The ip-down is called when the real link goes down and it has been so since the beggining of time. > ... then when the link goes down it should NOT call ip-down How would we be able to set the link status as inactive? > OR the pppd module should add fake IP address in it's post_down section. ...OR add different commands to net.lo like active and inactive. I didn't asked you to call net.ppp0 stop in ip-down in the first place. It was your idea, not mine.
Conclusion: baselayout is not allowed to do anything else than adding additional routes on inactive->started transition or mangling with metrics. If this means not calling net.${iface} stop in ip-down, so be it, but it beats the purpose of having inactive state.
(In reply to comment #12) > > OR the pppd module should add fake IP address in it's post_down section. > > ...OR add different commands to net.lo like active and inactive. > I didn't asked you to call net.ppp0 stop in ip-down in the first place. It was > your idea, not mine. > Sorry that my solution to your bug #122396 causes this issue. I'll stop providing solutions to your bugs. (In reply to comment #13) > Conclusion: baselayout is not allowed to do anything else than adding > additional routes on inactive->started transition or mangling with metrics. baselayout brings down the network configuration when told to. > If this means not calling net.${iface} stop in ip-down, so be it, but it beats > the purpose of having inactive state. Only for ppp. netplug, ifplugd and wpa_supplicant handle it just fine. I've already told you about *possible* solutions - namely not bringing the interface down when in dial on demand OR putting a fake ip + route in pppd_post_down call.
(In reply to comment #14) > I've already told you about *possible* solutions - namely not bringing the > interface down when in dial on demand OR putting a fake ip + route in > pppd_post_down call. a) It isn't easy to check if the link is on demand or not. It might be set through pppd_ppp0 or through a file used to pass options. b) It is wrong to assume only IP is used. There are other protocols out there and I cannot make such script which saves interface settings for *any* protocols used by pppd. c) The complexity should be hidden, not exposed like you propose. What you propose would be the following: - discover what IP utilities are installed (ip vs ifconfig & route) - save the IP settings using the installed utilities - call net.ppp0 stop - restore the IP settings using the installed utilities What I propose is to leave pppd reset the PPP interface. Simple and easy to do it.
Or create a pppd_exists() function to test wether pppd exists on the given interface pppd_exists() { [[ -e "/var/run/ppp-$1.pid" ]] } And then wrap the delete address line 832 in net.lo if ! function_exists pppd_exists || ! pppd_exists "${iface}" ; then interface_del_addresses "${iface}" fi
Created attachment 95943 [details, diff] Don't delete addresses when stopping a ppp interface See if this works.
I do the patch and get no feedback? Well it's in our svn and will be in the next release.
Hold your horses. I have other jobs to do, you know? I will test it this week, rest assure. Btw, I prefer a variable like IN_BACKGROUND. ip-down script run the net.ppp0 in a child process.
Ah, I thought you patched ip-down script. Sorry for misunderstanding.
(In reply to comment #18) > I do the patch and get no feedback? Well it's in our svn and will be in the > next release. > sorry I was quite bussy the last days, anyways I did apply the patches and I see in /var/log/messages that the ppp connection gets terminated and I can reestablish the ppp connection again, as an ondemand link should behave. so it works for me now. thanx
Patch submitted in comment #17 fixes the problem.
*** Bug 146734 has been marked as a duplicate of this bug. ***
Fixed in 1.12.5
