Red Hat Bugzilla – Bug 116927
pppd Segmentation fault, adsl dial on demand does not work
Last modified: 2015-01-07 19:07:20 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030922 Description of problem: There is a Segmentations fault from pppd if you want use asdl with the Dial on Demand option. Please have a look at bug #114875 at: 2. Dial on Demand do not work ONBOOT=yes USERCTL=no DEFROUTE=yes DEMAND=yes After ifup starts the script "/sbin/adsl-connect" can not create the interface. /var/log/messages adsl-connect: ADSL connection lost; attempting re-connection. Debuging /sbin/adsl-connect with set -x (with help from Lars Herrmann, herrmann@redhat.com): /sbin/adsl-connect: line 317: 3493 " $SETSID $PPPD pty "$PPPOE_CMD" $PPP_STD_OPTIONS $DEMAND $PPPD_SYNC /sbin/adsl-connect: line 317: 3493 Segmentation fault $SETSID $PPPD pty "$PPPOE_CMD" $PPP_STD_OPTIONS $DEMAND $PPPD_SYNC + test -x /etc/ppp/adsl-lost + /usr/bin/logger -t adsl-connect -p daemon.notice 'ADSL connection lost; attempting re-connection.' For more details see attachment "adsl-connect-debug.txt.gz". In "adsl-connect-debug.txt.gz" you find the Segmentations fault. I think it comes from pppd or? Version-Release number of selected component (if applicable): ppp-2.4.1-14 together with rp-pppoe-3.5-4 How reproducible: Always Steps to Reproduce: 1.configure adsl with dial on demand 2.ifup interface 3. Actual Results: the pppd can not start, Segmentation fault, unable to use adsl with dial on demand option Expected Results: works correct Additional info:
Created attachment 98073 [details] debug with Segmentations fault
/sbin/adsl-connect: line 317: 3487 Segmentation fault $SETSID $PPPD pty "$PPPOE_CMD" $PPP_STD_OPTIONS $DEMAND $PPPD_SYNC + test -x /etc/ppp/adsl-lost + /usr/bin/logger -t adsl-connect -p daemon.notice 'ADSL connection lost; attempting re-connection.' + sleep 5 The pppd never starts from adsl-connect if DEMAND=yes. So I can only debug with this parameter in ifcfg-ppp0 # Please read /usr/share/doc/initscripts-*/sysconfig.txt # for the documentation of these parameters. ONBOOT=yes USERCTL=no PEERDNS=yes TYPE=xDSL DEVICE=ppp0 BOOTPROTO=dialup PIDFILE=/var/run/pppoe-adsl.pid FIREWALL=NONE PING=. PPPOE_TIMEOUT=80 LCP_FAILURE=3 LCP_INTERVAL=20 CLAMPMSS=1412 CONNECT_POLL=6 CONNECT_TIMEOUT=60 PERSIST=yes SYNCHRONOUS=no DEFROUTE=yes USER='t-online-com/123456789012@t-online-com.de' PROVIDER=T-Online ETH=eth1 In attach gdb.txt.gz you see what I do and the results from gdb. Attach messages.gdb.gz contains the messages to the pppd pids. I see the return code 1 and I ask me if there is a problem in syncronisation between pppd and pppoe? The SYNCHRONOUS=yes option create on error per packet but you need two modules from unsupported kernel for use it. I do not use SYNCHRONOUS=yes at this time. I hope it helps.
Created attachment 98168 [details] gdb protokoll
Created attachment 98169 [details] messages to gdb
Created attachment 98227 [details] messages pppd core dumps
Created attachment 98228 [details] core files (1) pppd
Created attachment 98229 [details] core file (2) pppd
Decoded backtrace from the core dumps: Core was generated by `/usr/sbin/pppd pty /usr/sbin/pppoe -p /var/run/pppoe-adsl.pid.pppoe -I eth1 -T'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 #0 0xb74dbd33 in strlen () from /lib/tls/libc.so.6 (gdb) bt #0 0xb74dbd33 in strlen () from /lib/tls/libc.so.6 #1 0x0805eddb in vslprintf (buf=0xbfffed94 "\004\005`�����\f}_�*", buflen=987, fmt=0x806f5c5 " option", args=0xbffff18c "") at utils.c:364 #2 0x0805db50 in option_error (fmt=0x0) at options.c:1000 #3 0x0805df6b in number_option (str=0xbffffce7 "yes", valp=0xb75818a0, base=0) at options.c:1294 #4 0x0805df90 in int_option (str=0x0, valp=0x0) at options.c:1314 #5 0x0805d2f8 in process_option (opt=0x8073858, cmd=0xb75818a0 "\002", argv=0xbffff38c) at options.c:631 #6 0x0805c89e in parse_args (argc=8, argv=0xbffff38c) at options.c:319 #7 0x0804d4c6 in main (argc=42, argv=0xbffff304) at main.c:294 (gdb)
There are different versions for ppp in RHEL3. # strings lib/modules/2.4.21-9.0.1.EL/kernel/drivers/net/ppp_generic.o | grep version Kernelmodules are "PPP generic driver version 2.4.2" The RPM ppp which contains the pppd is version 2.4.1. # rpm -qa ppp ppp-2.4.1-14 You see it also in the SRPM. I build a new ppp RPM based on ppp version 2.4.2 self. If I use the pppd version 2.4.2 with Dial on Demand I see in /var/log/messages: Mar 16 09:50:33 adsl01 pppd[15407]: invalid numeric parameter 'yes' for idle option Please see the decoded backtrace from the core dumps: #3 0x0805df6b in number_option (str=0xbffffce7 "yes", pppd version 2.4.2 do not crash with the false "idle yes" parameter, but dial on demand can not start. This is a bug in rp-pppoe RPM. I think, it is a good idee to build a new ppp RPM based on ppp version 2.4.2. I use this version with ADSL and FlatRate (break after 24 hours) since 14 days and it works without any errors.
Please have a look at http://people.redhat.com/twoerner/SRPMS/3.0E/ppp-2.4.1-14.1.src.rpm http://people.redhat.com/twoerner/RPMS/3.0E/ppp-2.4.1-14.1.i386.rpm
I test ppp-2.4.1-14.1.i386.rpm and rp-pppoe-3.5-4.1.i386.rpm together. The false option "idle=yes" do not come longer from rp-pppoe and so Dial on Demand can work. The last two reconnects after 24 hours shows now errors with a minimum on actions in if-down.local and if-up.local. Let me see, what are the results in two weeks with squid traffic and VPN-IPSec during the reconnets. Uwe
With this patch the pppd not longer crashs if there is an invalid parameter like "idle=yes". This was the reason for this bugreport. You can close this bug. Additional infomation: The pppd works without errors for 13 days with an minimum on actions in if-down.local and if-up.local. Now I put all my actions in if-down.local and if-up.local (Th Jul 22 2004). The result was, the same errors I reported in Bug #116921 during reconnect adsl. pppd do not wait correct for the script return. I will put more informations in Bug #116921 soon. Uwe
Closing out this issue based on feedback from the original reporter.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-276.html