PAP authentication - Why this happens? - PPP

This is a discussion on PAP authentication - Why this happens? - PPP ; What will happen if a ppp peer receives a PAP authenticate Ack with an identifier different from the one it sent in PAP authenticate request? The below is the log of what actually happened. I am simulating one of the ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: PAP authentication - Why this happens?

  1. PAP authentication - Why this happens?

    What will happen if a ppp peer receives a PAP authenticate
    Ack with an identifier different from the one it sent in PAP
    authenticate request?

    The below is the log of what actually happened. I am simulating
    one of the peer and using pppd in Linux as the other peer.
    The log is that of the pppd.

    Can somebody explain me the behavior from the below log?
    Is the behavior correct one?

    Log:
    ====

    Using interface ppp0
    Connect: ppp0 <--> /dev/pts/10
    rcvd [LCP ConfReq id=0x1 ]
    sent [LCP ConfReq id=0x1 ]
    sent [LCP ConfAck id=0x1 ]
    rcvd [LCP ConfAck id=0x1 ]
    sent [PAP AuthReq id=0x1 user="root" password=]
    sent [PAP AuthReq id=0x2 user="root" password=]
    rcvd [PAP AuthAck id=0x3 "login ok"]
    Remote message: login ok
    PAP authentication succeeded
    sent [LCP TermReq id=0x2 "Authentication failed"]
    sent [LCP TermReq id=0x3 "Authentication failed"]
    Connection terminated.

    Thanks,
    Sriram K


  2. Re: PAP authentication - Why this happens?

    "ksriram29@gmail.com" writes:
    > What will happen if a ppp peer receives a PAP authenticate
    > Ack with an identifier different from the one it sent in PAP
    > authenticate request?


    It's supposed to ignore it silently. It's also not supposed to happen
    at all, so it probably doesn't matter.

    > Can somebody explain me the behavior from the below log?
    > Is the behavior correct one?


    It looks like it to me.

    > rcvd [LCP ConfReq id=0x1 ]


    This system demands that the peer authenticate itself to the local
    system.

    > sent [LCP ConfReq id=0x1 ]


    The peer also demands that you authenticate to it. You're using
    bidirectional authentication.

    This is legal, but highly unusual.

    > sent [LCP ConfAck id=0x1 ]
    > rcvd [LCP ConfAck id=0x1 ]


    Both agree.

    > sent [PAP AuthReq id=0x1 user="root" password=]


    The system sends an authentication request, as demanded by the peer.

    > sent [PAP AuthReq id=0x2 user="root" password=]


    After a timeout, the local system sends another message. The first
    must have been dropped.

    > rcvd [PAP AuthAck id=0x3 "login ok"]


    The peer responds with bogus ID number.

    > Remote message: login ok
    > PAP authentication succeeded


    The local system accepts that. Oh, well. Not a big failing.

    > sent [LCP TermReq id=0x2 "Authentication failed"]
    > sent [LCP TermReq id=0x3 "Authentication failed"]


    The remote system is broken. It never bothered to send a PAP
    Authentication-Request, even though it *agreed* to do so above.
    That's what caused the failure.

    I suspect you might have "requirepap" in your configuration, and that
    you don't really want it.

    --
    James Carlson 42.703N 71.076W

  3. Re: PAP authentication - Why this happens?

    "ksriram29@gmail.com" writes:

    >What will happen if a ppp peer receives a PAP authenticate
    >Ack with an identifier different from the one it sent in PAP
    >authenticate request?


    >The below is the log of what actually happened. I am simulating
    >one of the peer and using pppd in Linux as the other peer.
    >The log is that of the pppd.


    >Can somebody explain me the behavior from the below log?
    >Is the behavior correct one?


    You do not have time stamps on this. Always include the time stamps from
    the logs. Many things ae time sensitive.


    Both the local and the remote systems demand that the other authenticate
    themselves. Both agree. You send them an authentication which succeeds, they never send
    one to you. Thus after a while your system will say they have failed, which
    it does.

    Note that if the remote side is an ISP, they almost never willl
    authenticate themselves to you. In they case they say they will, but don't.
    I have no idea what "I am simulating
    one of the peer and using pppd in Linux as the other peer" means. If this
    is you playing silly buggers, then it is not surprising that all kinds of
    nonesense can happen.



    >Log:
    >====


    >Using interface ppp0
    >Connect: ppp0 <--> /dev/pts/10
    >rcvd [LCP ConfReq id=0x1 ]
    >sent [LCP ConfReq id=0x1 ]
    >sent [LCP ConfAck id=0x1 ]
    >rcvd [LCP ConfAck id=0x1 ]
    >sent [PAP AuthReq id=0x1 user="root" password=]
    >sent [PAP AuthReq id=0x2 user="root" password=]
    >rcvd [PAP AuthAck id=0x3 "login ok"]
    >Remote message: login ok
    >PAP authentication succeeded
    >sent [LCP TermReq id=0x2 "Authentication failed"]
    >sent [LCP TermReq id=0x3 "Authentication failed"]
    >Connection terminated.


  4. Re: PAP authentication - Why this happens?

    I removed the require-pap from the options file of pppd. Now I am
    using unidirectional authentication. The authentication succeeds
    and goes to the IPCP phase.

    I am interested in knowing about why the pppd accepts the PAP
    Auth-Ack packet with the bogus identifier. Shouldn't it ignore that
    packet and continue sending PAP Auth-Req till it receives a PAP
    Auth-Ack with a valid identifier or the maximum times it is configured
    to send Auth-Req before terminating the connection.

    How do I make the logs to include timestamps? By saying "I am
    simulating
    one of the peer " what I mean is that I am sending the PPP packets from
    my
    own program.

    Thanks,
    Sriram K

    log:
    ===
    Using interface ppp0
    Connect: ppp0 <--> /dev/pts/3
    rcvd [LCP ConfReq id=0x1 ]
    sent [LCP ConfReq id=0x1]
    sent [LCP ConfAck id=0x1 ]
    rcvd [LCP ConfAck id=0x1]
    sent [PAP AuthReq id=0x1 user="root" password=]
    sent [PAP AuthReq id=0x2 user="root" password=]
    rcvd [PAP AuthAck id=0x3 "login ok"]
    Remote message: login ok
    PAP authentication succeeded
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    sent [IPCP ConfReq id=0x1 ]
    IPCP: timeout sending Config-Requests
    sent [LCP TermReq id=0x2 "No network protocols running"]
    sent [LCP TermReq id=0x3 "No network protocols running"]
    Connection terminated.


    Unruh wrote:
    > "ksriram29@gmail.com" writes:
    >
    > >What will happen if a ppp peer receives a PAP authenticate
    > >Ack with an identifier different from the one it sent in PAP
    > >authenticate request?

    >
    > >The below is the log of what actually happened. I am simulating
    > >one of the peer and using pppd in Linux as the other peer.
    > >The log is that of the pppd.

    >
    > >Can somebody explain me the behavior from the below log?
    > >Is the behavior correct one?

    >
    > You do not have time stamps on this. Always include the time stamps from
    > the logs. Many things ae time sensitive.
    >
    >
    > Both the local and the remote systems demand that the other authenticate
    > themselves. Both agree. You send them an authentication which succeeds, they never send
    > one to you. Thus after a while your system will say they have failed, which
    > it does.
    >
    > Note that if the remote side is an ISP, they almost never willl
    > authenticate themselves to you. In they case they say they will, but don't.
    > I have no idea what "I am simulating
    > one of the peer and using pppd in Linux as the other peer" means. If this
    > is you playing silly buggers, then it is not surprising that all kinds of
    > nonesense can happen.
    >
    >
    >
    > >Log:
    > >====

    >
    > >Using interface ppp0
    > >Connect: ppp0 <--> /dev/pts/10
    > >rcvd [LCP ConfReq id=0x1 ]
    > >sent [LCP ConfReq id=0x1 ]
    > >sent [LCP ConfAck id=0x1 ]
    > >rcvd [LCP ConfAck id=0x1 ]
    > >sent [PAP AuthReq id=0x1 user="root" password=]
    > >sent [PAP AuthReq id=0x2 user="root" password=]
    > >rcvd [PAP AuthAck id=0x3 "login ok"]
    > >Remote message: login ok
    > >PAP authentication succeeded
    > >sent [LCP TermReq id=0x2 "Authentication failed"]
    > >sent [LCP TermReq id=0x3 "Authentication failed"]
    > >Connection terminated.



  5. Re: PAP authentication - Why this happens?

    "ksriram29@gmail.com" writes:

    >I removed the require-pap from the options file of pppd. Now I am
    >using unidirectional authentication. The authentication succeeds
    >and goes to the IPCP phase.


    >I am interested in knowing about why the pppd accepts the PAP
    >Auth-Ack packet with the bogus identifier. Shouldn't it ignore that
    >packet and continue sending PAP Auth-Req till it receives a PAP
    >Auth-Ack with a valid identifier or the maximum times it is configured
    >to send Auth-Req before terminating the connection.


    >How do I make the logs to include timestamps? By saying "I am
    >simulating


    put
    daemon.* /var/log/daemonlog
    into /etc/sysconfig.conf

    Then run
    killall -1 syslogd
    Then post the lines from /var/log/daemonlog after you have tried to
    connect.


    >one of the peer " what I mean is that I am sending the PPP packets from
    >my
    >own program.


    Again I have no idea what you are saying.


    >Thanks,
    >Sriram K


    >log:
    >===
    >Using interface ppp0
    >Connect: ppp0 <--> /dev/pts/3
    >rcvd [LCP ConfReq id=0x1 ]
    >sent [LCP ConfReq id=0x1]
    >sent [LCP ConfAck id=0x1 ]
    >rcvd [LCP ConfAck id=0x1]
    >sent [PAP AuthReq id=0x1 user="root" password=]
    >sent [PAP AuthReq id=0x2 user="root" password=]
    >rcvd [PAP AuthAck id=0x3 "login ok"]
    >Remote message: login ok
    >PAP authentication succeeded
    >sent [IPCP ConfReq id=0x1 ]
    >sent [IPCP ConfReq id=0x1 ]
    >sent [IPCP ConfReq id=0x1 ]
    >sent [IPCP ConfReq id=0x1 ]
    >sent [IPCP ConfReq id=0x1 ]
    >sent [IPCP ConfReq id=0x1 ]
    >sent [IPCP ConfReq id=0x1 ]
    >sent [IPCP ConfReq id=0x1 ]
    >sent [IPCP ConfReq id=0x1 ]
    >sent [IPCP ConfReq id=0x1 ]
    >IPCP: timeout sending Config-Requests
    >sent [LCP TermReq id=0x2 "No network protocols running"]
    >sent [LCP TermReq id=0x3 "No network protocols running"]
    >Connection terminated.



    >Unruh wrote:
    >> "ksriram29@gmail.com" writes:
    >>
    >> >What will happen if a ppp peer receives a PAP authenticate
    >> >Ack with an identifier different from the one it sent in PAP
    >> >authenticate request?

    >>
    >> >The below is the log of what actually happened. I am simulating
    >> >one of the peer and using pppd in Linux as the other peer.
    >> >The log is that of the pppd.

    >>
    >> >Can somebody explain me the behavior from the below log?
    >> >Is the behavior correct one?

    >>
    >> You do not have time stamps on this. Always include the time stamps from
    >> the logs. Many things ae time sensitive.
    >>
    >>
    >> Both the local and the remote systems demand that the other authenticate
    >> themselves. Both agree. You send them an authentication which succeeds, they never send
    >> one to you. Thus after a while your system will say they have failed, which
    >> it does.
    >>
    >> Note that if the remote side is an ISP, they almost never willl
    >> authenticate themselves to you. In they case they say they will, but don't.
    >> I have no idea what "I am simulating
    >> one of the peer and using pppd in Linux as the other peer" means. If this
    >> is you playing silly buggers, then it is not surprising that all kinds of
    >> nonesense can happen.
    >>
    >>
    >>
    >> >Log:
    >> >====

    >>
    >> >Using interface ppp0
    >> >Connect: ppp0 <--> /dev/pts/10
    >> >rcvd [LCP ConfReq id=0x1 ]
    >> >sent [LCP ConfReq id=0x1 ]
    >> >sent [LCP ConfAck id=0x1 ]
    >> >rcvd [LCP ConfAck id=0x1 ]
    >> >sent [PAP AuthReq id=0x1 user="root" password=]
    >> >sent [PAP AuthReq id=0x2 user="root" password=]
    >> >rcvd [PAP AuthAck id=0x3 "login ok"]
    >> >Remote message: login ok
    >> >PAP authentication succeeded
    >> >sent [LCP TermReq id=0x2 "Authentication failed"]
    >> >sent [LCP TermReq id=0x3 "Authentication failed"]
    >> >Connection terminated.



  6. Re: PAP authentication - Why this happens?

    I build the PPP packet with whatever options I want using a socket
    program
    and put it on the wire.
    Thanks,
    Sriram K

    Unruh wrote:
    > "ksriram29@gmail.com" writes:
    >
    > >I removed the require-pap from the options file of pppd. Now I am
    > >using unidirectional authentication. The authentication succeeds
    > >and goes to the IPCP phase.

    >
    > >I am interested in knowing about why the pppd accepts the PAP
    > >Auth-Ack packet with the bogus identifier. Shouldn't it ignore that
    > >packet and continue sending PAP Auth-Req till it receives a PAP
    > >Auth-Ack with a valid identifier or the maximum times it is configured
    > >to send Auth-Req before terminating the connection.

    >
    > >How do I make the logs to include timestamps? By saying "I am
    > >simulating

    >
    > put
    > daemon.* /var/log/daemonlog
    > into /etc/sysconfig.conf
    >
    > Then run
    > killall -1 syslogd
    > Then post the lines from /var/log/daemonlog after you have tried to
    > connect.
    >
    >
    > >one of the peer " what I mean is that I am sending the PPP packets from
    > >my
    > >own program.

    >
    > Again I have no idea what you are saying.
    >
    >
    > >Thanks,
    > >Sriram K

    >
    > >log:
    > >===
    > >Using interface ppp0
    > >Connect: ppp0 <--> /dev/pts/3
    > >rcvd [LCP ConfReq id=0x1 ]
    > >sent [LCP ConfReq id=0x1]
    > >sent [LCP ConfAck id=0x1 ]
    > >rcvd [LCP ConfAck id=0x1]
    > >sent [PAP AuthReq id=0x1 user="root" password=]
    > >sent [PAP AuthReq id=0x2 user="root" password=]
    > >rcvd [PAP AuthAck id=0x3 "login ok"]
    > >Remote message: login ok
    > >PAP authentication succeeded
    > >sent [IPCP ConfReq id=0x1 ]
    > >sent [IPCP ConfReq id=0x1 ]
    > >sent [IPCP ConfReq id=0x1 ]
    > >sent [IPCP ConfReq id=0x1 ]
    > >sent [IPCP ConfReq id=0x1 ]
    > >sent [IPCP ConfReq id=0x1 ]
    > >sent [IPCP ConfReq id=0x1 ]
    > >sent [IPCP ConfReq id=0x1 ]
    > >sent [IPCP ConfReq id=0x1 ]
    > >sent [IPCP ConfReq id=0x1 ]
    > >IPCP: timeout sending Config-Requests
    > >sent [LCP TermReq id=0x2 "No network protocols running"]
    > >sent [LCP TermReq id=0x3 "No network protocols running"]
    > >Connection terminated.

    >
    >
    > >Unruh wrote:
    > >> "ksriram29@gmail.com" writes:
    > >>
    > >> >What will happen if a ppp peer receives a PAP authenticate
    > >> >Ack with an identifier different from the one it sent in PAP
    > >> >authenticate request?
    > >>
    > >> >The below is the log of what actually happened. I am simulating
    > >> >one of the peer and using pppd in Linux as the other peer.
    > >> >The log is that of the pppd.
    > >>
    > >> >Can somebody explain me the behavior from the below log?
    > >> >Is the behavior correct one?
    > >>
    > >> You do not have time stamps on this. Always include the time stamps from
    > >> the logs. Many things ae time sensitive.
    > >>
    > >>
    > >> Both the local and the remote systems demand that the other authenticate
    > >> themselves. Both agree. You send them an authentication which succeeds, they never send
    > >> one to you. Thus after a while your system will say they have failed, which
    > >> it does.
    > >>
    > >> Note that if the remote side is an ISP, they almost never willl
    > >> authenticate themselves to you. In they case they say they will, but don't.
    > >> I have no idea what "I am simulating
    > >> one of the peer and using pppd in Linux as the other peer" means. If this
    > >> is you playing silly buggers, then it is not surprising that all kinds of
    > >> nonesense can happen.
    > >>
    > >>
    > >>
    > >> >Log:
    > >> >====
    > >>
    > >> >Using interface ppp0
    > >> >Connect: ppp0 <--> /dev/pts/10
    > >> >rcvd [LCP ConfReq id=0x1 ]
    > >> >sent [LCP ConfReq id=0x1 ]
    > >> >sent [LCP ConfAck id=0x1 ]
    > >> >rcvd [LCP ConfAck id=0x1 ]
    > >> >sent [PAP AuthReq id=0x1 user="root" password=]
    > >> >sent [PAP AuthReq id=0x2 user="root" password=]
    > >> >rcvd [PAP AuthAck id=0x3 "login ok"]
    > >> >Remote message: login ok
    > >> >PAP authentication succeeded
    > >> >sent [LCP TermReq id=0x2 "Authentication failed"]
    > >> >sent [LCP TermReq id=0x3 "Authentication failed"]
    > >> >Connection terminated.



  7. Re: PAP authentication - Why this happens?

    "ksriram29@gmail.com" writes:
    > I am interested in knowing about why the pppd accepts the PAP
    > Auth-Ack packet with the bogus identifier.


    Because, quite simply, it doesn't do that. Look at the code in
    upap_input and upap_rauthack -- it does not do the check you're asking
    about.

    What more do you need to know?

    > Shouldn't it ignore that
    > packet and continue sending PAP Auth-Req till it receives a PAP
    > Auth-Ack with a valid identifier or the maximum times it is configured
    > to send Auth-Req before terminating the connection.


    Yes ... but since this just never happens, why do you care?

    --
    James Carlson 42.703N 71.076W

  8. Re: PAP authentication - Why this happens?

    Thanks Carlson. One last thing, is it compliant with the RFC? Because
    from what I have read I feel that it isn't.

    Thank you.
    Sriram K

    James Carlson wrote:
    > "ksriram29@gmail.com" writes:
    > > I am interested in knowing about why the pppd accepts the PAP
    > > Auth-Ack packet with the bogus identifier.

    >
    > Because, quite simply, it doesn't do that. Look at the code in
    > upap_input and upap_rauthack -- it does not do the check you're asking
    > about.
    >
    > What more do you need to know?
    >
    > > Shouldn't it ignore that
    > > packet and continue sending PAP Auth-Req till it receives a PAP
    > > Auth-Ack with a valid identifier or the maximum times it is configured
    > > to send Auth-Req before terminating the connection.

    >
    > Yes ... but since this just never happens, why do you care?
    >
    > --
    > James Carlson 42.703N 71.076W



  9. Re: PAP authentication - Why this happens?

    "ksriram29@gmail.com" writes:
    > Thanks Carlson. One last thing, is it compliant with the RFC? Because
    > from what I have read I feel that it isn't.


    Yes, it's compliant. RFC 1334 does not say that you must discard
    Authenticate-{Ack,Nak} packets with the wrong Identifier value. It
    says only:

    Identifier

    The Identifier field is one octet and aids in matching requests
    and replies. The Identifier field MUST be copied from the
    Identifier field of the Authenticate-Request which caused this
    reply.

    In other words, the authenticator is *required* to copy the Identifier
    value from the Authenticate-Request message into the corresponding
    reply. The authenticatee is under no obligation to validate this
    field in any particular way.

    Why do you feel that it is not compliant with the RFC? What
    requirement is it violating?

    Once again, I must ask: why do you care? What are you doing that
    would produce this result, and why do you insist that there must be a
    "purity test" here?

    My take on it is that testing the received Identifier value would
    actually be a bad thing to do, because it violates the cardinal rule:
    "be conservative in what you send, liberal in what you expect."
    Consider the case where you have a very slow external authentication
    server: you send AuthReq ID=1, and before it can respond, you send
    AuthReq ID=2. The server finally replies with AuthAck ID=1 -- why
    would you want to discard that? And aren't you risking an unending
    timing problem -- getting further and further behind as requests queue
    up?

    I can see no actual problem that is fixed by being overly picky about
    the Identifier value, and several problems that may be caused by
    adding such logic. (I can recommend a book that discusses some of the
    pitfalls involved in PPP implementation, if you're interested.)

    I could add logic as you suggest to pppd, but I see no reason to do
    so.

    --
    James Carlson 42.703N 71.076W

  10. Re: PAP authentication - Why this happens?

    Thanks once again Carlson. I am just a novice and in a learning curve.
    Your detailed explanations has helped me. I would like to know the
    book's
    title and its author.

    Thanks,
    Sriram K

    James Carlson wrote:
    > "ksriram29@gmail.com" writes:
    > > Thanks Carlson. One last thing, is it compliant with the RFC? Because
    > > from what I have read I feel that it isn't.

    >
    > Yes, it's compliant. RFC 1334 does not say that you must discard
    > Authenticate-{Ack,Nak} packets with the wrong Identifier value. It
    > says only:
    >
    > Identifier
    >
    > The Identifier field is one octet and aids in matching requests
    > and replies. The Identifier field MUST be copied from the
    > Identifier field of the Authenticate-Request which caused this
    > reply.
    >
    > In other words, the authenticator is *required* to copy the Identifier
    > value from the Authenticate-Request message into the corresponding
    > reply. The authenticatee is under no obligation to validate this
    > field in any particular way.
    >
    > Why do you feel that it is not compliant with the RFC? What
    > requirement is it violating?
    >
    > Once again, I must ask: why do you care? What are you doing that
    > would produce this result, and why do you insist that there must be a
    > "purity test" here?
    >
    > My take on it is that testing the received Identifier value would
    > actually be a bad thing to do, because it violates the cardinal rule:
    > "be conservative in what you send, liberal in what you expect."
    > Consider the case where you have a very slow external authentication
    > server: you send AuthReq ID=1, and before it can respond, you send
    > AuthReq ID=2. The server finally replies with AuthAck ID=1 -- why
    > would you want to discard that? And aren't you risking an unending
    > timing problem -- getting further and further behind as requests queue
    > up?
    >
    > I can see no actual problem that is fixed by being overly picky about
    > the Identifier value, and several problems that may be caused by
    > adding such logic. (I can recommend a book that discusses some of the
    > pitfalls involved in PPP implementation, if you're interested.)
    >
    > I could add logic as you suggest to pppd, but I see no reason to do
    > so.
    >
    > --
    > James Carlson 42.703N 71.076W



  11. Re: PAP authentication - Why this happens?

    "ksriram29@gmail.com" writes:

    >Thanks once again Carlson. I am just a novice and in a learning curve.
    >Your detailed explanations has helped me. I would like to know the
    >book's
    >title and its author.


    The author is one James Carlson. PPP Design and Debugging
    He tends to be coy about it.


    >Thanks,
    >Sriram K


    >James Carlson wrote:
    >> "ksriram29@gmail.com" writes:
    >> > Thanks Carlson. One last thing, is it compliant with the RFC? Because
    >> > from what I have read I feel that it isn't.

    >>
    >> Yes, it's compliant. RFC 1334 does not say that you must discard
    >> Authenticate-{Ack,Nak} packets with the wrong Identifier value. It
    >> says only:
    >>
    >> Identifier
    >>
    >> The Identifier field is one octet and aids in matching requests
    >> and replies. The Identifier field MUST be copied from the
    >> Identifier field of the Authenticate-Request which caused this
    >> reply.
    >>
    >> In other words, the authenticator is *required* to copy the Identifier
    >> value from the Authenticate-Request message into the corresponding
    >> reply. The authenticatee is under no obligation to validate this
    >> field in any particular way.
    >>
    >> Why do you feel that it is not compliant with the RFC? What
    >> requirement is it violating?
    >>
    >> Once again, I must ask: why do you care? What are you doing that
    >> would produce this result, and why do you insist that there must be a
    >> "purity test" here?
    >>
    >> My take on it is that testing the received Identifier value would
    >> actually be a bad thing to do, because it violates the cardinal rule:
    >> "be conservative in what you send, liberal in what you expect."
    >> Consider the case where you have a very slow external authentication
    >> server: you send AuthReq ID=1, and before it can respond, you send
    >> AuthReq ID=2. The server finally replies with AuthAck ID=1 -- why
    >> would you want to discard that? And aren't you risking an unending
    >> timing problem -- getting further and further behind as requests queue
    >> up?
    >>
    >> I can see no actual problem that is fixed by being overly picky about
    >> the Identifier value, and several problems that may be caused by
    >> adding such logic. (I can recommend a book that discusses some of the
    >> pitfalls involved in PPP implementation, if you're interested.)
    >>
    >> I could add logic as you suggest to pppd, but I see no reason to do
    >> so.
    >>
    >> --
    >> James Carlson 42.703N 71.076W



  12. Re: PAP authentication - Why this happens?

    Unruh writes:

    > "ksriram29@gmail.com" writes:
    >
    > >Thanks once again Carlson. I am just a novice and in a learning curve.
    > >Your detailed explanations has helped me. I would like to know the
    > >book's
    > >title and its author.

    >
    > The author is one James Carlson. PPP Design and Debugging
    > He tends to be coy about it.


    Nah. I just figure that google and amazon searches are universally
    available. ;-}

    --
    James Carlson 42.703N 71.076W

  13. Re: PAP authentication - Why this happens?

    James Carlson writes:

    >Unruh writes:


    >> "ksriram29@gmail.com" writes:
    >>
    >> >Thanks once again Carlson. I am just a novice and in a learning curve.
    >> >Your detailed explanations has helped me. I would like to know the
    >> >book's
    >> >title and its author.

    >>
    >> The author is one James Carlson. PPP Design and Debugging
    >> He tends to be coy about it.


    >Nah. I just figure that google and amazon searches are universally
    >available. ;-}


    Actually probably a bit more of a hint is required, although I must admit
    that the first book listed on an Amazon search of "ppp" is the One.
    Google is more useless since the first item is Pogo Producing Company




    >--
    >James Carlson 42.703N 71.076W


+ Reply to Thread