PPP silent option : RFC??? - TCP-IP

This is a discussion on PPP silent option : RFC??? - TCP-IP ; Hello I am looking for the PPP silent option text. Despite many search hours I did not find anything. Does anyone know an RFC reference for this option? Or is it defined somewhere else? Many thanks Michel...

+ Reply to Thread
Results 1 to 9 of 9

Thread: PPP silent option : RFC???

  1. PPP silent option : RFC???

    Hello

    I am looking for the PPP silent option text.
    Despite many search hours I did not find anything.
    Does anyone know an RFC reference for this option?
    Or is it defined somewhere else?

    Many thanks
    Michel

  2. Re: PPP silent option : RFC???

    Hello,

    michel.tempo@yahoo.fr a écrit :
    >
    > I am looking for the PPP silent option text.
    > Despite many search hours I did not find anything.
    > Does anyone know an RFC reference for this option?
    > Or is it defined somewhere else?


    Could it be the "silent" option in the PPP daemon pppd ?

  3. Re: PPP silent option : RFC???

    michel.tempo@yahoo.fr writes:
    > I am looking for the PPP silent option text.
    > Despite many search hours I did not find anything.
    > Does anyone know an RFC reference for this option?
    > Or is it defined somewhere else?


    There's no such option, at least by that name. What exactly are you
    trying to do? What do you expect the option to do?

    (You might want to try out comp.protocols.ppp or even the
    pppext@ietf.org mailing list for this question.)

    --
    James Carlson, Solaris Networking
    Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  4. Re: PPP silent option : RFC???

    On Jan 10, 9:38*am, michel.te...@yahoo.fr wrote:
    > Hello
    >
    > I am looking for the PPP silent option text.
    > Despite many search hours I did *not find anything.
    > Does anyone know an RFC reference for this option?
    > Or is it defined somewhere else?


    I think you're looking for this from the Linux Network Administrators
    Guide, Chapter 8:

    "The silent option causes pppd to wait until it receives a packet from
    the calling system before it starts sending. This option prevents
    transmit timeouts from occurring when the calling system is slow in
    firing up its PPP client. The modem option makes pppd drive the modem
    control lines of the serial port. You should always turn this option
    on when using pppd with a modem."

    http://www.faqs.org/docs/linux_network/x7297.html

    Bert

  5. Re: PPP silent option : RFC???

    On Jan 10, 9:38 am, michel.te...@yahoo.fr wrote:
    > Hello
    >
    > I am looking for the PPP silent option text.
    > Despite many search hours I did not find anything.
    > Does anyone know an RFC reference for this option?
    > Or is it defined somewhere else?
    >
    > Many thanks
    > Michel


    From pppd(8) ("man 8 pppd")
    "silent With this option, pppd will not transmit LCP packets to
    initiate
    a connection until a valid LCP packet is received from the
    peer
    (as for the `passive' option with ancient versions of
    pppd)."



  6. Re: PPP silent option : RFC???

    Pascal Hambourg writes:
    > michel.tempo@yahoo.fr a écrit :
    > > I am looking for the PPP silent option text.
    > > Despite many search hours I did not find anything.
    > > Does anyone know an RFC reference for this option?
    > > Or is it defined somewhere else?

    >
    > Could it be the "silent" option in the PPP daemon pppd ?


    Good call ... the original poster referred to an "RFC," so I'd posted
    saying "no such animal." It's entirely possible he *is* referring to
    the option in pppd. If so, then there is no RFC that covers this
    behavior -- none is really needed. It's just a feature of that
    implementation.

    --
    James Carlson, Solaris Networking
    Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  7. Re: PPP silent option : RFC???


    Thanks to everybody for your answers.
    It is effectively the pppd concerning LCP packet.
    Our problem seems to be that both peers wait for the other one to
    start LCP negociation.
    I tried to find an RFC definition, hoping clear decision for different
    cases.

    Michel

  8. Re: PPP silent option : RFC???

    michel.tempo@yahoo.fr a écrit :
    > It is effectively the pppd concerning LCP packet.
    > Our problem seems to be that both peers wait for the other one to
    > start LCP negociation.


    If each peer runs pppd with the "silent" option and thus waits for the
    other to send the first LCP packet, nothing will ever happen.
    Alternatively you may try to run pppd with the "passive" option instead
    of "silent". With this option pppd will first try to initiate a
    connection, then if it gets no reply it will wait for an incoming
    connection initiated by the peer.

    > I tried to find an RFC definition, hoping clear decision for different
    > cases.


    As James said, this is beyond the scope of the RFCs.

  9. Re: PPP silent option : RFC???

    michel.tempo@yahoo.fr writes:
    > Thanks to everybody for your answers.
    > It is effectively the pppd concerning LCP packet.
    > Our problem seems to be that both peers wait for the other one to
    > start LCP negociation.
    > I tried to find an RFC definition, hoping clear decision for different
    > cases.


    There's no such RFC. Not every behavior that an implementation of
    _any_ protocol has is defined by an RFC. RFCs just don't work that
    way. Instead, they describe the on-the-wire bits necessary to acheive
    interoperability, and they *assume* that you thoroughly understand the
    environment in which you're developing and deploying your
    implementation.

    In other words, the RFCs aren't (and can't reasonably be) "complete."
    Experience and market requirements are essential ingredients in the
    mix.

    The assumption that the implementation makes is that the peer does
    *not* have the same option set. You should also note that the pppd
    man page indicates that the don't-speak-until-spoken-to "silent"
    option is not the preferred way to configure a link. The "passive"
    option is preferred, because it makes pppd try LCP first to see if the
    peer has started. That way, there's much less chance of "who should
    go first?" confusion.

    As the protocol is designed, per the RFCs, these options just don't
    exist. The RFCs (primarily RFC 1661) simply define a way for the
    underlying physical layer to tell PPP when it's ready by asserting
    "lower layer is up" -- event "Up" in the RFC 1661 state machine.

    One reasonable way to think of this pppd behavior is that the "silent"
    option is really just a modified lower layer that refuses to send an
    "Up" event until one byte is seen on the wire from the peer, rather
    than just waiting for the carrier signal from the modem. There's no
    specification that covers such things, just as there's no
    specification that tells you what you "must" or "must not" do when you
    see the DCD line transition, or you encounter a T1 yellow alarm, or
    you get a SIGTERM. These are environmental things that an implementor
    must reason out and hopefully document well for the user.

    As for the reason the option exists, it's there to deal with broken
    hardware and bad chat scripts that manage to go haywire when LCP
    behaves normally and starts sending messages as soon as the link is
    up. Contrary to what others have posted, and apparently to what some
    FAQs seem to say, *NO* normal link should have this option set. Use
    it only to work around brain-damage that you might find in a
    particular deployment, and not as an all-purpose salve.

    For what it's worth, that goes for all pppd options, and often goes
    for all tunables on all software programs. Unless you have direct
    evidence to know that you need to change the tunable or option, and
    you have a thorough understanding of the effects and drawbacks of
    changing it, DON'T CHANGE IT; USE THE DEFAULT. I can't say that
    strongly enough. Those of us who build software carefully choose
    those defaults so that they're _right_. In my experience, many more
    people get themselves into more trouble by random and incoherent
    tweaking than ever run into real bugs.

    A good configuration is minimal.

    --
    James Carlson, Solaris Networking
    Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

+ Reply to Thread