Re: help me hang up the phone - PPP

This is a discussion on Re: help me hang up the phone - PPP ; J> SIGHUP makes pppd think that carrier has gone away. There's no J> point in trying to close LCP when that happens # killall -HUP pppd Hangup (SIGHUP) sent [LCP TermReq id=0x2 "User request"] rcvd [LCP TermAck id=0x2] So indeed ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: Re: help me hang up the phone

  1. Re: help me hang up the phone

    J> SIGHUP makes pppd think that carrier has gone away. There's no
    J> point in trying to close LCP when that happens
    # killall -HUP pppd
    Hangup (SIGHUP)
    sent [LCP TermReq id=0x2 "User request"]
    rcvd [LCP TermAck id=0x2]
    So indeed pppd version 2.4.2 is still dabbling with LCP.
    I suppose pending a fix, I must do
    killall -9 pppd && /etc/ppp/ip-down by hand? Any less rash steps in my
    mission to get the phone hung up within 5 seconds no matter what,
    before another 2.7 New Taiwan Dollars goes into their coffers,
    short of me having to walk over and yank the cord out? My Lucent
    Venus modem is very obedient, if I could only get pppd to talk to it
    instead of the ISP.

  2. Re: help me hang up the phone

    Dan Jacobson writes:

    ]J> SIGHUP makes pppd think that carrier has gone away. There's no
    ]J> point in trying to close LCP when that happens
    ]# killall -HUP pppd
    ]Hangup (SIGHUP)
    ]sent [LCP TermReq id=0x2 "User request"]
    ]rcvd [LCP TermAck id=0x2]

    So? It is polite to tell the other side that you are tearing down the
    link. Why is this a problem?

    Note that that negotiation takes less than a second-- far less than the
    time required to walk across the room.

    (keeping the time stamps would have made clear.)



    ]So indeed pppd version 2.4.2 is still dabbling with LCP.
    ]I suppose pending a fix, I must do
    ]killall -9 pppd && /etc/ppp/ip-down by hand? Any less rash steps in my
    ]mission to get the phone hung up within 5 seconds no matter what,
    ]before another 2.7 New Taiwan Dollars goes into their coffers,
    ]short of me having to walk over and yank the cord out? My Lucent
    ]Venus modem is very obedient, if I could only get pppd to talk to it
    ]instead of the ISP.


  3. Re: help me hang up the phone

    JC> SIGHUP makes pppd think that carrier has gone away. There's no
    JC> point in trying to close LCP when that happens

    Here we see that pppd version 2.4.2 indeed still is dabbling with LCP:
    # killall -HUP pppd
    # tail -f syslog #|cut ...
    7:41:56 pppd[3216]: Hangup (SIGHUP)
    7:41:56 pppd[3216]: Script /etc/ppp/ip-down started (pid 4027)
    7:41:56 pppd[3216]: sent [LCP TermReq id=0x2 "User request"]
    7:41:59 pppd[3216]: Script /etc/ppp/ip-down finished (pid 4027), status = 0x1
    7:41:59 pppd[3216]: sent [LCP TermReq id=0x3 "User request"]
    7:42:02 pppd[3216]: sent [LCP TermReq id=0x4 "User request"]
    7:42:03 pppd[3216]: Hangup (SIGHUP)
    7:42:03 pppd[3216]: Modem hangup
    7:42:03 pppd[3216]: Connection terminated.
    7:42:03 pppd[3216]: Connect time 8.9 minutes.
    7:42:03 pppd[3216]: Sent 384874 bytes, received 1373855 bytes.
    7:42:04 pppd[3216]: Connect time 8.9 minutes.
    7:42:04 pppd[3216]: Sent 384874 bytes, received 1373855 bytes.
    7:42:04 pppd[3216]: Exit.

    My options were unchanged from my previous posting. Odd, stat messages
    are repeated, at least here on Debian.

  4. Re: help me hang up the phone

    Carlson> If it doesn't do exactly that, then let us know about the bug

    In <87u12ncyzu.fsf@jidanni.org> I showed it doesn't, no?

    Unruh> So? It is polite to tell the other side that you are tearing down the
    Unruh> link. Why is this a problem?

    Yes, that would be ideal, but if there is no snappy response from the
    other side, then there should be alternatives available that work as
    documented, before things drag on and the next coin drops into their coffers.

    Also there should be a way to hand up other than with LCP,
    "unilaterally". lcp-max-terminate 0, 1, or whatever, never worked for
    me. The pppd program is overly polite, giving one no way to hand up
    except several LCP messages.

    Unruh> Note that that negotiation takes less than a second-- far less than the
    Unruh> time required to walk across the room.

    Under pristine conditions, perhaps, but not on every conversation with
    every other host. Especially when there's still some traffic on the
    line. Anyway, <87u12ncyzu.fsf@jidanni.org> showed it took several
    seconds, not one, and that was on a good day.

  5. Re: help me hang up the phone

    Dan Jacobson writes:
    > Carlson> If it doesn't do exactly that, then let us know about the bug
    >
    > In <87u12ncyzu.fsf@jidanni.org> I showed it doesn't, no?


    Yep.

    > Also there should be a way to hand up other than with LCP,
    > "unilaterally". lcp-max-terminate 0, 1, or whatever, never worked for
    > me. The pppd program is overly polite, giving one no way to hand up
    > except several LCP messages.


    It's not that it's overly polite. It's wrong. SIGHUP is a 'Down'
    event in RFC 1661, and should have immediately put the state machine
    back to Starting. It looks like it's treating this as a 'Close' event
    instead.

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

  6. Re: help me hang up the phone

    Dan Jacobson wrote:

    > Unruh> Note that that negotiation takes less than a second-- far less
    > than the
    > Unruh> time required to walk across the room.


    > Under pristine conditions, perhaps, but not on every conversation with
    > every other host. Especially when there's still some traffic on the
    > line. Anyway, <87u12ncyzu.fsf@jidanni.org> showed it took several
    > seconds, not one, and that was on a good day.


    Note that the cause of the long delay in termination is due to the bug
    in pppd James Carlson identified, *and* the peer's failure to respond
    to the Terminate-Requests with an Ack. The ISP here Acks the first
    such request and pppd exits within one second of a SIGHUP.

    The fact that "lcp-max-terminate 1" doesn't do what one would expect
    sounds to me like another bug, or that some minimum number of requests
    sent exists (probably the default, 3) that's not mentioned in the
    man pages.

    -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* The signal-to-noise ratio is too low in many [news] groups to make
    * them good candidates for archiving.
    * --- Mike Moraes, Answers to FAQs about Usenet */

  7. Re: help me hang up the phone

    James Carlson wrote:
    > Dan Jacobson writes:
    >> Carlson> If it doesn't do exactly that, then let us know about the bug
    >>
    >> In <87u12ncyzu.fsf@jidanni.org> I showed it doesn't, no?


    > Yep.


    >> Also there should be a way to hand up other than with LCP,
    >> "unilaterally". lcp-max-terminate 0, 1, or whatever, never worked for
    >> me. The pppd program is overly polite, giving one no way to hand up
    >> except several LCP messages.


    > It's not that it's overly polite. It's wrong. SIGHUP is a 'Down'
    > event in RFC 1661, and should have immediately put the state machine
    > back to Starting. It looks like it's treating this as a 'Close' event
    > instead.


    I've just finished reviewing what seem to be the pertinent sections of
    RFC 1661 and can't find anything saying that a SIGHUP is a Down event.

    If the PPP implementation can distinguish between a SIGHUP generated by
    a real modem hangup and one generated by a user then isn't the action
    taken upon receiving a user-generated SIGHUP an implementation detail?

    If so then sending Terminate-Request on receiving a SIGHUP would appear
    to be wrong only if it does it after a real modem hangup.

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

  8. Re: help me hang up the phone

    As
    SIGHUP This signal causes pppd to terminate the link, restore the
    serial device settings, and close the serial device.
    does not necessarily hangup immediately, I find
    killall -9 pppd
    env - /etc/ppp/ip-down.d ppp0 /dev/ttyS0 115200 0.0.0.0 0.0.0.0&
    rm /var/run/ppp0.pid
    is a workaround, for me. Perhaps the only thing it doesn't do is "restore the
    serial device settings".

  9. Re: help me hang up the phone

    Dan Jacobson writes:
    > SIGHUP This signal causes pppd to terminate the link, restore the
    > serial device settings, and close the serial device.
    > does not necessarily hangup immediately, I find
    > killall -9 pppd
    > env - /etc/ppp/ip-down.d ppp0 /dev/ttyS0 115200 0.0.0.0 0.0.0.0&
    > rm /var/run/ppp0.pid
    > is a workaround, for me. Perhaps the only thing it doesn't do is "restore the
    > serial device settings".


    It's really a very bad idea to do 'kill -9' to any application,
    including pppd. You should instead either patch it yourself or wait
    until someone else has the time to look into the problem.

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

  10. Re: help me hang up the phone

    James Carlson wrote:
    > Dan Jacobson writes:
    >> SIGHUP This signal causes pppd to terminate the link, restore the
    >> serial device settings, and close the serial device.
    >> does not necessarily hangup immediately, I find
    >> killall -9 pppd
    >> env - /etc/ppp/ip-down.d ppp0 /dev/ttyS0 115200 0.0.0.0 0.0.0.0&
    >> rm /var/run/ppp0.pid
    >> is a workaround, for me. Perhaps the only thing it doesn't do is "restore the
    >> serial device settings".


    > It's really a very bad idea to do 'kill -9' to any application,
    > including pppd. You should instead either patch it yourself or wait
    > until someone else has the time to look into the problem.


    Agreed that "kill -9" is really distasteful but it may be quite awhile
    before a solution is implemented, if at all. But what makes it a "very
    bad idea" for a user who is charged by the Telco for the time it takes
    to wait for Terminate-Requests that never arrive, and who has no other
    choice to reduce his cost?

    FWIW, I'm interested in determining why reducing the number of those
    requests with lcp-max-terminate doesn't work in pppd, even to the extent
    of looking at ("stumbling blindly about in" might be a better description)
    the pppd source code.

    -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* Slogan appropriate for a certain well-known software company:
    FAILURE IS NOT AN OPTION - it is built into the operating system
    and comes bundled with the software. And attracts maggots */

  11. Re: help me hang up the phone

    James Carlson writes:
    > > Also there should be a way to hand up other than with LCP,
    > > "unilaterally". lcp-max-terminate 0, 1, or whatever, never worked for
    > > me. The pppd program is overly polite, giving one no way to hand up
    > > except several LCP messages.

    >
    > It's not that it's overly polite. It's wrong. SIGHUP is a 'Down'
    > event in RFC 1661, and should have immediately put the state machine
    > back to Starting. It looks like it's treating this as a 'Close' event
    > instead.


    Last night I committed a fix for "lcp-max-terminate 0" into the CVS
    gate. If you still need a fix for this, check it out. It sends
    exactly one Terminate-Request, but then hangs up without waiting for
    the reply.

    While I still stand by what I said above in the abstract, I realized
    that it can't actually be fixed for pppd. The problem is that SIGHUP
    is used to do an orderly shutdown of the link in demand mode (that is,
    returning to idle state rather than exiting as SIGTERM would do). It
    wouldn't be reasonable to have SIGHUP behave differently with and
    without "demand" enabled, so the above fix for lcp-max-terminate will
    have to do.

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

  12. Re: help me hang up the phone

    Clifford Kite writes:
    > The fact that "lcp-max-terminate 1" doesn't do what one would expect
    > sounds to me like another bug, or that some minimum number of requests
    > sent exists (probably the default, 3) that's not mentioned in the
    > man pages.


    I haven't been able to confirm that behavior. In testing of the CVS
    sources, "lcp-max-terminate 1" caused one LCP Terminate-Request to be
    sent, and a restart-timer delay to wait for the reply. The only bug
    that I found (and I fixed last night) was that setting it to zero
    didn't eliminate the restart-timer delay.

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

  13. Re: help me hang up the phone

    James Carlson wrote:
    > Clifford Kite writes:
    >> The fact that "lcp-max-terminate 1" doesn't do what one would expect
    >> sounds to me like another bug, or that some minimum number of requests
    >> sent exists (probably the default, 3) that's not mentioned in the
    >> man pages.


    > I haven't been able to confirm that behavior. In testing of the CVS
    > sources, "lcp-max-terminate 1" caused one LCP Terminate-Request to be
    > sent, and a restart-timer delay to wait for the reply. The only bug
    > that I found (and I fixed last night) was that setting it to zero
    > didn't eliminate the restart-timer delay.


    The "lcp-max-terminate 1" was in reference to what the OP had said in
    his first post:

    I.e. lcp-max-terminate 1 is obviously being ignored, here in pppd
    version 2.4.2

    So it would be interesting to know how this apparent counter-example
    can be explained.

    I'm glad to hear that it should work though, and also that you've
    submitted a fix for the option to solve his problem (I haven't made
    much headway in understanding how option values are handled :/).

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* Better is the enemy of good enough. */

  14. Re: help me hang up the phone

    Dan Jacobson writes:

    ]As
    ] SIGHUP This signal causes pppd to terminate the link, restore the
    ] serial device settings, and close the serial device.
    ]does not necessarily hangup immediately, I find

    ?? How immediately do you want it?

    ]killall -9 pppd
    ]env - /etc/ppp/ip-down.d ppp0 /dev/ttyS0 115200 0.0.0.0 0.0.0.0&
    ]rm /var/run/ppp0.pid
    ]is a workaround, for me. Perhaps the only thing it doesn't do is "restore the
    ]serial device settings".

    It does not do anything, except kill and not clean up anything. does not
    run ppp/ipdown, does not reset serial port, etc.



  15. Re: help me hang up the phone

    > How immediately do you want it?

    well, there should be a way to hangup the line "as fast as possible"
    i.e., as fast as killall -9 pppd.

    > wouldn't be reasonable to have SIGHUP behave differently with and
    > without "demand" enabled


    well, as long as all is documented, then we will use whatever new
    signal we find we are supposed to use, if that is what you decide.

    > committed a fix for "lcp-max-terminate 0" into the CVS gate. It
    > sends exactly one Terminate-Request, but then hangs up without
    > waiting for the reply.


    OK, sounds good, but there should also be a way to terminate without
    sending anything, just for completeness. (User charged per 50MB
    block, anymore of anything will cause purchase of another block...

    enemy detected, any chars sent will enable tracing us... terminate
    now...

    who knows.)

    I suppose a working lcp-max-terminate 0 should work within a second,
    so that ought to be fine for me though. Be sure that the man page
    says that 0 means hangup now (and -1 means LCP forever, perhaps.)

    I'll use
    killall -9 pppd; env - /etc/ppp/ip-down & rm /var/run/ppp0.pid
    until your fixes get into Debian unstable.

  16. Re: help me hang up the phone

    Dan Jacobson writes:
    > > committed a fix for "lcp-max-terminate 0" into the CVS gate. It
    > > sends exactly one Terminate-Request, but then hangs up without
    > > waiting for the reply.

    >
    > OK, sounds good, but there should also be a way to terminate without
    > sending anything, just for completeness. (User charged per 50MB
    > block, anymore of anything will cause purchase of another block...


    If you're charged for LCP messages, then, frankly, you need to find a
    new ISP. I don't see a point to hacking pppd to support that sort of
    thing.

    > I suppose a working lcp-max-terminate 0 should work within a second,
    > so that ought to be fine for me though. Be sure that the man page
    > says that 0 means hangup now


    Yes; there are several items that need to be updated in the man page.

    > (and -1 means LCP forever, perhaps.)


    There's no '-1' option. Perhaps another day. That sounds fraught
    with peril to me.

    > I'll use
    > killall -9 pppd; env - /etc/ppp/ip-down & rm /var/run/ppp0.pid
    > until your fixes get into Debian unstable.


    Why not pull down the current CVS sources and at least try them?

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

+ Reply to Thread