Can someone else look at this - I presently have no time for any
"community" work from the end of this week onwards, and shall be
bouncing all bugs to lkml. I'm expecting this situation to continue
until maybe Christmas time.
I'm going to try to flush as much stuff from my patch queues as
possible for the remainder of this week, and then I think it'll
be up to others.
mbligh - please assign the default owner for:
- PCMCIA bugs to [email protected]
- serial bugs to, I guess, [email protected]
I'm not sure at present what's going to happen with "community"
ARM kernel work, but I think it will certainly not be progressing
very quickly. I'll do what I can but I fear it won't be very much.
----- Forwarded message from [email protected] -----
Date: Tue, 19 Oct 2004 04:53:50 -0700
From: [email protected]
To: [email protected]
Subject: [Bug 3592] New: pppd "IPCP: timeout sending Config-Requests"
http://bugme.osdl.org/show_bug.cgi?id=3592
Summary: pppd "IPCP: timeout sending Config-Requests"
Kernel Version: 2.6.9-rc4
Status: NEW
Severity: normal
Owner: [email protected]
Submitter: [email protected]
Distribution: Gentoo
Hardware Environment:
Software Environment: ppp-2.4.1 ( tested with ppp-2.4.2 - the same error )
Problem Description: With 2.6.9-rc4 I'm getting the error when dialing to my
provider. With older kernel versions everything works fine. After remote modem
cosed the connection (rcvd [CHAP Success id=0x29 ""]) pppd keeps sending
Config-Requests
sent [IPCP ConfReq id=0x1 <addr 192.168.1.2> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Steps to reproduce:
1) Install kernel 2.6.9-rc4
2) use the following script to connect ( chap1 )
REPORT 'CONNECT'
ABORT 'BUSY'
ABORT 'ERROR'
ABORT 'NO ANSWER'
ABORT 'NO CARRIER'
ABORT 'NO DIALTONE'
ABORT 'Invalid Login'
ABORT 'Login incorrect'
TIMEOUT 45
'' 'ATZ'
'OK' 'ATS32=98'
'OK' 'ATS0=1'
'OK' 'ATDT0*******'
'CONNECT' ''
'~--' ''
3) pppd command:
/usr/sbin/pppd debug nodetach lock modem crtscts asyncmap 00000000 mru 768 mtu
768 user username remotename NT4RAS /dev/ttyS4 115200 noauth linkname ppp0
connect /usr/sbin/chat -v -f /etc/ppp/chat1
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
----- End forwarded message -----
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Tue, 2004-10-19 at 07:12, Russell King wrote:
> Software Environment: ppp-2.4.1 ( tested with ppp-2.4.2 - the same error )
> Problem Description: With 2.6.9-rc4 I'm getting the error when dialing to my
> provider. With older kernel versions everything works fine. After remote modem
> cosed the connection (rcvd [CHAP Success id=0x29 ""]) pppd keeps sending
> Config-Requests
This looks like the tty locking changes from Alan Cox.
The tty_io.c do_tty_hangup() no longer switches
the line discipline back to N_TTY, so ppp_async.c
is not aware of the hangup (ldisc->close not called).
The following is a snippet from tty_io.c:
/* Defer ldisc switch */
/* tty_deferred_ldisc_switch(N_TTY);
This should get done automatically when the port closes and
tty_release is called */
I'll setup a test connection and verify this.
--
Paul Fulghum
[email protected]
On Tue, 2004-10-19 at 09:17, Paul Fulghum wrote:
> This looks like the tty locking changes from Alan Cox.
>
> The tty_io.c do_tty_hangup() no longer switches
> the line discipline back to N_TTY, so ppp_async.c
> is not aware of the hangup (ldisc->close not called).
>
> The following is a snippet from tty_io.c:
>
> /* Defer ldisc switch */
> /* tty_deferred_ldisc_switch(N_TTY);
>
> This should get done automatically when the port closes and
> tty_release is called */
>
> I'll setup a test connection and verify this.
I have verified the problem as described above.
PPP line disciplines rely on the previous behavior
of calling ldisc->close on hangup as a method for
indicating hangup to the line discipline.
This is explicitly called out in the PPP ldisc comments.
Other line disciplines may also rely on this behavior.
Alan's changes also added the ldisc->hangup() method
to indicate hangup, but all the line disciplines
must be modified to implement this method.
--
Paul Fulghum
[email protected]
On Maw, 2004-10-19 at 16:32, Paul Fulghum wrote:
> PPP line disciplines rely on the previous behavior
> of calling ldisc->close on hangup as a method for
> indicating hangup to the line discipline.
> This is explicitly called out in the PPP ldisc comments.
I had no choice about that really with the current locking. It's on the
list to do further work although I'd not realised some odder pppd
configurations relied upon it until the bug report.
Once I've put out -ac1 to fix the other bugs I consider urgent (not tty)
I'll see what I can do. Really it would nice if the ppp maintainer would
look at this and also fix all the horrible things the code does wrongly
if for example the first byte of a received buffer is an error marker -
in general serial error processing is not robust in the ppp code it
appears.
Alan
On Wed, Oct 20, 2004 at 06:42:40PM -0500, Paul Fulghum wrote:
> I'm not sure I would characterize using DCD
> for a serial connection indicator as odd.
The default setup trusts LCP closes sent between the two ends
> > in general serial error processing is not robust in the ppp code it
> > appears.
>
> I'll look at what is needed to implement the
> new ldisc->hangup() method for the PPP line disciplines.
Thanks
On Wed, 2004-10-20 at 18:46, Alan Cox wrote:
> On Wed, Oct 20, 2004 at 06:42:40PM -0500, Paul Fulghum wrote:
> > I'm not sure I would characterize using DCD
> > for a serial connection indicator as odd.
>
> The default setup trusts LCP closes sent between the two ends
Yes.
In the case of this bug report, it looks like Window NT4
is dropping the connection without sending the LCP close.
That is crappy behavior.
DCD makes a good check on the physical layer in case
your POTS line is on the crackly side.
May I never suffer dialup again :-P
--
Paul Fulghum
[email protected]
On Wed, 2004-10-20 at 16:57, Alan Cox wrote:
> On Maw, 2004-10-19 at 16:32, Paul Fulghum wrote:
> > PPP line disciplines rely on the previous behavior
> > of calling ldisc->close on hangup as a method for
> > indicating hangup to the line discipline.
> > This is explicitly called out in the PPP ldisc comments.
>
> I had no choice about that really with the current locking. It's on the
> list to do further work although I'd not realised some odder pppd
> configurations relied upon it until the bug report.
OK
I'm not sure I would characterize using DCD
for a serial connection indicator as odd.
> Once I've put out -ac1 to fix the other bugs I consider urgent (not tty)
> I'll see what I can do. Really it would nice if the ppp maintainer would
> look at this and also fix all the horrible things the code does wrongly
> if for example the first byte of a received buffer is an error marker -
> in general serial error processing is not robust in the ppp code it
> appears.
I'll look at what is needed to implement the
new ldisc->hangup() method for the PPP line disciplines.
--
Paul Fulghum
[email protected]
On Tue, Oct 19, 2004 at 01:12:40PM +0100, Russell King wrote:
> ----- Forwarded message from [email protected] -----
>
> Date: Tue, 19 Oct 2004 04:53:50 -0700
> From: [email protected]
> To: [email protected]
> Subject: [Bug 3592] New: pppd "IPCP: timeout sending Config-Requests"
>
> http://bugme.osdl.org/show_bug.cgi?id=3592
>
> Summary: pppd "IPCP: timeout sending Config-Requests"
> Kernel Version: 2.6.9-rc4
> Status: NEW
> Severity: normal
> Owner: [email protected]
> Submitter: [email protected]
So, what can I do with this bug? Just close or reject it, or what?
Maybe Alan or Paul would like to assign this bug to themselves?
Thanks.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Sad, 2004-11-20 at 13:11, Russell King wrote:
> So, what can I do with this bug? Just close or reject it, or what?
> Maybe Alan or Paul would like to assign this bug to themselves?
>
I thought that was fixed in 10rc and 2.6.9-ac
On Sat, Nov 20, 2004 at 12:34:07PM +0000, Alan Cox wrote:
> On Sad, 2004-11-20 at 13:11, Russell King wrote:
> > So, what can I do with this bug? Just close or reject it, or what?
> > Maybe Alan or Paul would like to assign this bug to themselves?
> >
>
> I thought that was fixed in 10rc and 2.6.9-ac
Maybe, I have no idea - no one updated the bug, and I'd just like to
get rid of it one way or the other.
I'm tempted to reject it with a comment "status unknown, please resubmit
if it remains a problem" - which kind of makes a mockery of bug tracking
systems.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
Russell King wrote:
> On Sat, Nov 20, 2004 at 12:34:07PM +0000, Alan Cox wrote:
>
>>On Sad, 2004-11-20 at 13:11, Russell King wrote:
>>
>>>So, what can I do with this bug? Just close or reject it, or what?
>>>Maybe Alan or Paul would like to assign this bug to themselves?
>>>
>>
>>I thought that was fixed in 10rc and 2.6.9-ac
>
>
> Maybe, I have no idea - no one updated the bug, and I'd just like to
> get rid of it one way or the other.
This was fixed (post 2.6.9) with the addition of the ldisc->hangup
method in the ppp_async and ppp_synctty line disciplines.
The bug reporter has a Windows NT server that terminates
the connection without sending the proper LCP packets.
The Linux box had previously relied on DCD negation
to indicate loss of connection via hangup. Alan's
locking changes removed the ldisc->close from do_hangup()
so the line discipline was no longer aware of the hangup.
Adding the ldisc->hangup method restored
detection of connection loss.
I reproduced this in lab, and tested the fix successfully.
I don't remember which version the patch was accepted.
--
Paul Fulghum
[email protected]
On Sat, Nov 20, 2004 at 09:09:28AM -0600, Paul Fulghum wrote:
> Russell King wrote:
> > On Sat, Nov 20, 2004 at 12:34:07PM +0000, Alan Cox wrote:
> >
> >>On Sad, 2004-11-20 at 13:11, Russell King wrote:
> >>
> >>>So, what can I do with this bug? Just close or reject it, or what?
> >>>Maybe Alan or Paul would like to assign this bug to themselves?
> >>>
> >>
> >>I thought that was fixed in 10rc and 2.6.9-ac
> >
> >
> > Maybe, I have no idea - no one updated the bug, and I'd just like to
> > get rid of it one way or the other.
>
> This was fixed (post 2.6.9) with the addition of the ldisc->hangup
> method in the ppp_async and ppp_synctty line disciplines.
Right, I've closed the bug then. It's a shame someone else couldn't
have done that when the bug was known to have been fixed.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
Russell King wrote:
> Right, I've closed the bug then. It's a shame someone else couldn't
> have done that when the bug was known to have been fixed.
My bad.
I had not previously participated in this particular
bugzilla database. In the future, if I supply a fix
I know to be associated with a bug tracker, and
I am allowed access to change that bug, I will do so.
--
Paul Fulghum
[email protected]