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

Hello,

[email]michel.tempo@yahoo.fr[/email] a écrit :[color=blue]
>
> 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?[/color]

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

[email]michel.tempo@yahoo.fr[/email] writes:[color=blue]
> 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?[/color]

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
[email]pppext@ietf.org[/email] mailing list for this question.)

--
James Carlson, Solaris Networking <james.d.carlson@sun.com>
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

On Jan 10, 9:38*am, michel.te...@yahoo.fr wrote:[color=blue]
> 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?[/color]

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

[url]http://www.faqs.org/docs/linux_network/x7297.html[/url]

Bert

On Jan 10, 9:38 am, michel.te...@yahoo.fr wrote:[color=blue]
> 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[/color]

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)."

Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> writes:[color=blue]
> [email]michel.tempo@yahoo.fr[/email] a écrit :[color=green]
> > 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?[/color]
>
> Could it be the "silent" option in the PPP daemon pppd ?[/color]

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 <james.d.carlson@sun.com>
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

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

[email]michel.tempo@yahoo.fr[/email] a écrit :[color=blue]
> 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.[/color]

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.
[color=blue]
> I tried to find an RFC definition, hoping clear decision for different
> cases.[/color]

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

[email]michel.tempo@yahoo.fr[/email] writes:[color=blue]
> 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.[/color]

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 <james.d.carlson@sun.com>
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