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

Submitter:  None
Submitted:  Mon 06 Jun 2005 05:37:11 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group 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>
Group 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.

Anonymous
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.
--
Gerph.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    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.13-d3ae.
    Corresponding source code