buglwIP - A Lightweight TCP/IP stack - Bugs: bug #13315, PPP PAP authentication can result...


You are not allowed to post comments on this tracker with your current authentication level.

bug #13315: PPP PAP authentication can result in erroneous callbacks

Submitted by:  None
Submitted on:  Mon 06 Jun 2005 05:37:11 PM UTC  
Category:  None Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  Simon Goldschmidt <goldsimon>
Open/Closed:  Closed Planned Release:  None
lwIP version:  CVS Head

( Jump to the original submission)

Mon 11 Jan 2010 04:40:01 PM UTC, comment #7: 

> TODO: add bugtracker entry for the original pppd

Forget that, it's fixed in the current pppd. Fixed by copying the code from pppd.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 11 Jan 2010 09:43:42 AM UTC, comment #6: 

TODO: add bugtracker entry for the original pppd, as that seems to have this bug, too. -> wait for response from pppd developers.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Fri 04 Dec 2009 03:38:06 PM UTC, comment #5: 

Seems like this bug exists, see also patch #6969 (same for _authack).

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Sat 02 May 2009 03:53:44 PM UTC, comment #4: 

I'm not really sure, but in bug #21680, Tom Evans wrote that in pppd v2.4.4, auth_withpeer_fail() (which is called at the end of the function where us_clientstate is set to UPAPCS_BADAUTH), calls lcp_close(), I wonder if that's got something to do with it or if that timeout is something not handled by the pppd code but an lwIP speciality?

In any case, it would be best to compare our code to the pppd code base to catch/solve bugs, I guess. Unfortunately, I don't really have the time for that...

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Wed 29 Aug 2007 09:20:24 AM UTC, comment #3: 

As Marc has been looking at PPP recently I wonder if you could give some input on this?  Would be nice to get a resolution to it, even if that involves marking it invalid.

Kieran Mansley <kieranm>
Project Member
Mon 26 Feb 2007 01:10:45 PM UTC, comment #2: 

Can anyone with some knowledge of PPP/PAP give some input on this.  I'm no expert so can't resolve this one.

Kieran Mansley <kieranm>
Project Member
Wed 13 Sep 2006 10:40:35 PM UTC, comment #1: 

I am not sure this bug because all PPP reconnections of my device are stable (with PAP auth).

Please your comments.

Janusz U.

Mon 06 Jun 2005 05:37:11 PM UTC, original submission:  

In the PAP implementation there is a problem which means that timeouts can occur after the PAP layer has been shut down.

The circumstances are thus :

PPP connection is made.
PAP is negotiated at LCP.
PAP authentication begins.
  (at this stage upap_timeout is set up with TIMEOUT())
PAP details are exchanged but authentication fails at the server.
  (at this stage the PAP implementation changes us_clientstate to UPAPCS_BADAUTH)
Server terminates the connection with LCP (and link layer).
This triggers 'lowerdown' calls to the layers which have been brought up.
upap_lowerdown is called and checks the us_clientstate for UPAPCS_AUTHREQ; as we've seen, it has been set to UPAPCS_BADAUTH so the UNTIMEOUT is not used.
With LCP down and probably the Link down too, a short time passes and then upap_timeout is called because the timeout has been triggered.

The danger here is that once the link layer has gone down, its resources might not be allocated - in my implementation the resources had gone away and the calls to operate on them (upap_timeout -> upap_sauthreq -> pppWrite -> nPut -> my link layer) failed when handing pbufs to a driver which no longer had any way of sending the data.

There are two choices for this; one is to UNTIMEOUT(upap_timeout) immediately the state changes away from UPAPCS_AUTHREQ (eg in upap_rauthnak). The other is to make the UNTIMEOUT(upap_timeout) call non-conditional in upap_lowerdown.

The same may be true of upap_reqtimeout which is conditional on UPAPSS_LISTEN for the server-side of the UPAP implementation. I have tested the implementation but not to as significant a degree.

Hopefully that may help someone.



No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by kieranm (Posted a comment)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-01-11 goldsimon StatusNone => Fixed
        Assigned toNone => goldsimon
        Open/ClosedOpen => Closed
    2009-08-20 kieranm Assigned tomarcbou => None
    2007-08-29 kieranm Assigned toNone => marcbou

    Back to the top

    Powered by Savane 3.5