Re: help me hang up the phone - PPP

This is a discussion on Re: help me hang up the phone - PPP ; Dan Jacobson wrote: > As we see, I just can't get the phone hung up right away: > Terminating on signal 15. > Script /etc/ppp/ip-down started (pid 17072) > sent [LCP TermReq id=0x2 "User request"] > Script /etc/ppp/ip-down finished (pid ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: help me hang up the phone

  1. Re: help me hang up the phone

    Dan Jacobson wrote:
    > As we see, I just can't get the phone hung up right away:


    > Terminating on signal 15.
    > Script /etc/ppp/ip-down started (pid 17072)
    > sent [LCP TermReq id=0x2 "User request"]
    > Script /etc/ppp/ip-down finished (pid 17072), status = 0x1
    > sent [LCP TermReq id=0x3 "User request"]
    > sent [LCP TermReq id=0x4 "User request"]
    > Hangup (SIGHUP)
    > Modem hangup
    > Connection terminated.


    > despite pppd options in effect:


    ....

    > lcp-max-terminate 1


    I now think it likely there's an inconsistency in the pppd code
    whereby the id field of Terminate-Request is changed with each
    retransmission, even though there is no response from the peer.
    For a LCP Configure-Request pppd does not change the id field in
    retransmissions if there is no response from the peer.

    Moreover, the pppd lcp-max-{configure, failure} options appear to
    only apply when the id field is unchanged, and any reply before the
    maximum is reached resets the counter. If true, it would seem that
    the Terminate-Request id field is treated the same way and the id
    changes seen above prevented lcp-max-terminate from working.

    This is all conjecture, derived from the Terminate-Request behavior
    seen above and black-box tests with pppd. I've not been able to
    motivate myself to delve deeply into the code to be sure.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* Speak softly and carry a +6 two-handed sword. */

  2. Re: help me hang up the phone

    Clifford Kite writes:
    > I now think it likely there's an inconsistency in the pppd code
    > whereby the id field of Terminate-Request is changed with each
    > retransmission, even though there is no response from the peer.
    > For a LCP Configure-Request pppd does not change the id field in
    > retransmissions if there is no response from the peer.


    Maybe. But what does that have to do with the behavior of
    lcp-max-terminate?

    I tested the current CVS code, and it *does* respect the
    lcp-max-terminate parameter correctly.

    > Moreover, the pppd lcp-max-{configure, failure} options appear to
    > only apply when the id field is unchanged, and any reply before the
    > maximum is reached resets the counter. If true, it would seem that
    > the Terminate-Request id field is treated the same way and the id
    > changes seen above prevented lcp-max-terminate from working.


    No, I don't think that's the case.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  3. Re: help me hang up the phone

    James Carlson wrote:
    > Clifford Kite writes:
    >> I now think it likely there's an inconsistency in the pppd code
    >> whereby the id field of Terminate-Request is changed with each
    >> retransmission, even though there is no response from the peer.
    >> For a LCP Configure-Request pppd does not change the id field in
    >> retransmissions if there is no response from the peer.


    > Maybe. But what does that have to do with the behavior of
    > lcp-max-terminate?


    Reading it now, it seems to have very little to do with the behavior
    of lcp-max-terminate except to say that the behavior in regard to the
    Identifier seemed to be the opposite from that of lcp-max-configure
    when there are no replies to requests.

    It certainly does nothing to answer the question as to why the option
    lcp-max-terminate failed to work for the OP, which is what his initial
    post appeared to show had happened.

    > I tested the current CVS code, and it *does* respect the
    > lcp-max-terminate parameter correctly.


    I'm using the Linux 2.4.2 version, which may not be the current CVS
    version. I think the OP was too, and according to his original post
    the problem does exist for it.

    >> Moreover, the pppd lcp-max-{configure, failure} options appear to
    >> only apply when the id field is unchanged, and any reply before the
    >> maximum is reached resets the counter. If true, it would seem that
    >> the Terminate-Request id field is treated the same way and the id
    >> changes seen above prevented lcp-max-terminate from working.


    > No, I don't think that's the case.


    You are probably right. In reviewing what I did, it now seems that
    I concluded too much, given too little understanding of the code and
    with limited resources available for black-box testing.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/

+ Reply to Thread