Bug 49046 - /usr/sbin/adsl-start does not connect with new kernel 2.4.3-12
Summary: /usr/sbin/adsl-start does not connect with new kernel 2.4.3-12
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rp-pppoe (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Ngo Than
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-13 09:08 UTC by Frank Eisenmenger
Modified: 2007-04-18 16:34 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-16 20:22:49 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Info on adsl debug output and kernel configuration (24.09 KB, text/plain)
2001-07-13 09:10 UTC, Frank Eisenmenger
no flags Details

Description Frank Eisenmenger 2001-07-13 09:08:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

Description of problem:
rp-pppoe (pppd) via T-DSL (ADSL) stops working when turning from kernel 
2.4.2-2 to 2.4.3-12 (Red Hat 7.1):
 "LCP: timeout sending Config-Requests"
(see details attached)

How reproducible:
Always

Steps to Reproduce:
1. Build monolithic kernel 2.4.3-12 (details attached)
2. Switch to this new kernel
3. adsl-start
	

Actual Results:  From output of command 'DEBUG=1 adsl-start':
...
pppd invocation
 /usr/bin/setsid /usr/sbin/pppd pty '/usr/sbin/pppoe -
p /var/run/pppoe.conf-adsl.pid.pppoe -I eth0 -T 80   ' ipparam ppp0  
noipdefault noauth defaultroute hide-password nodetach  local mtu 1492 mru 
1492 noaccomp noccp nobsdcomp nodeflate nopcomp  novj novjccomp user <my 
user name>#0001@t-online.de lcp-echo-interval 20 lcp-echo-failure 3   debug
 ---------------------------------------------
 using channel 1
 Using interface ppp0
 Connect: ppp0 <--> /dev/pts/0
 sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xf189145d>]
 sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xf189145d>]
 sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xf189145d>]
 sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xf189145d>]
 sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xf189145d>]
 sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xf189145d>]
 sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xf189145d>]
 sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xf189145d>]
 sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xf189145d>]
 sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xf189145d>]
 LCP: timeout sending Config-Requests
 Connection terminated.
 Waiting for 1 child processes...
  script /usr/sbin/pppoe -p /var/run/pppoe.conf-adsl.pid.pppoe -I eth0 -T 
80    -D /tmp/pppoe-debug-597/pppoe-debug.txt-0,  pid 633
 pppoe: Timeout waiting for PADO packets
 Script /usr/sbin/pppoe -p /var/run/pppoe.conf-adsl.pid.pppoe -I eth0 -T 
80    -D /tmp/pppoe-debug-597/pppoe-debug.txt-0  finished (pid 633), 
status = 0x100
 ---------------------------------------------
 Extract from /var/log/messages
 Jul 12 19:41:35 gate pppd[632]: pppd 2.4.0 started by root, uid 0
 Jul 12 19:41:35 gate pppd[632]: Using interface ppp0
 Jul 12 19:41:35 gate pppd[632]: Connect: ppp0 <--> /dev/pts/0
 Jul 12 19:42:06 gate pppd[632]: LCP: timeout sending Config-Requests 
 Jul 12 19:42:06 gate pppd[632]: Connection terminated.
 Jul 12 19:42:10 gate pppoe[633]: Timeout waiting for PADO packets
 Jul 12 19:42:10 gate pppd[632]: Exit.
 Don Jul 12 19:42:10 CEST 2001


Expected Results:  adsl-start
.Connecetd!

Additional info:

Comment 1 Frank Eisenmenger 2001-07-13 09:10:35 UTC
Created attachment 23488 [details]
Info on adsl debug output and kernel configuration

Comment 2 Michael Schwendt 2001-07-16 19:41:40 UTC
Certainly not a bug. It is due to temporary problems at Deutsche Telekom AG or
T-Online, respectively. Usually, the authentication server is unreachable for
some time or your remote access servers backbone connection is broken. If you
get this for a period longer than a few hours, consider calling the
DTAG/T-Online support hotline. Under rare circumstances it may be necessary to
reset your remote DSL port. See this independent list of unavailability periods:
http://www.friedenau.com/adsl/

Comment 3 Michael Schwendt 2001-07-16 19:54:50 UTC
Forgot to ask, can you reproduce this with the stock Red Hat kernel 2.4.3 too?

Comment 4 Michael Schwendt 2001-07-16 20:22:45 UTC
2.4.3-12:
eth0: media is unconnected, link down, or incompatible connection.

2.4.2-2:
eth0: Setting half-duplex based on auto-negotiated partner ability 0000.

Since I have different network cards, it might be specific to your system. I'll
shut up from now on. :)

Comment 5 Ngo Than 2001-07-24 09:20:01 UTC
i cannot reproduce it. it worls for me.
It should be a problem from T-Online.

Comment 6 Michael Schwendt 2001-07-28 00:12:20 UTC
Than, 

even though reporter states "How reproducible: Always" -- and according to his
log-scripts he was able to connect with the 2.2.4-2 kernel -- I also believed
this to be one of the many temporary unavailability problems with T-Online/DTAG.

_But_ does my comment from 2001-07-16 16:22:45 tell you anything? It is cut from
his "dmesg" output files. How's that difference in kernel log output to be
interpreted?




Note You need to log in before you can comment on or make changes to this bug.