Bill Unruh writes:
> On Tue, 1 Apr 2008, James Carlson wrote:
>
> > James Cameron writes:
> >> Now, looking at your log in more detail ... I'm surprised that you get
> >> an LCP ConfReq and ConfAck sequence up front consisting of 10 pairs of
> >> packets, each with the same id and magic number. It is as if the
> >
> > That's not a pppd problem. We're sending Configure-Request (over and
>
> Who is we? Are you part of this or is this a sort of royal we?
"We" are the local node for which the original poster supplied logs.
"They" are the other node -- the one that doesn't speak PPP so well
and for which we have no logs.
I can certainly use other words if those two offend you in some way.
> > over on the normal restart timer), and the peer is sending
> > Configure-Ack each time, but isn't bothering to send
> > Configure-Request.
>
> Sould not your side start to send a ConfReq with something other than
> magic?
No.
When "we" send the very first Configure-Request, we're in Req-Sent
state. We then get Configure-Ack from the peer, and we enter Ack-Rcvd
state. The peer does nothing, and time passes. Eventually, after 3
seconds by default, we get TO+. That (per the state machine) causes
us to invoke action "scr" -- Send-Configure-Request -- and return to
Req-Sent state, and the cycle starts over.
If you read section 5.1 ("Configure-Request") of RFC 1661, it
discusses how the Identifier is chosen, and explains that
implementations are permitted to leave the ID field unchanged.
Retransmit can be exactly that: retransmit, don't generate a new one
from scratch. That's how pppd does it.
The fail-safe here is TO-, the maximum restart count. If we hit that,
we fail with the familiar "LCP: timeout sending Config-Requests"
message.
In other words, the problem in the following sequence (shown by the
original poster) is not in pppd; it's in the peer that isn't bothering
to send Configure-Request, even though it's (inexplicably) able to
respond with Configure-Ack. My guess is that it has severe
implementation flaws, and thus should not be used if the data to be
carried or the time or health of the users are at all valuable.
sent [LCP ConfReq id=0x1 <magic 0x913429f5>]
rcvd [LCP ConfAck id=0x1 <magic 0x913429f5>]
sent [LCP ConfReq id=0x1 <magic 0x913429f5>]
rcvd [LCP ConfAck id=0x1 <magic 0x913429f5>]
(But do feel free to press on if seeing grotesque bugs doesn't make
you wary.)
> > I guess it depends on your tolerance level for broken devices and how
> > much you value your time. ;-}
>
> Or the pressure to make it work by higherups.
"No problem. Here's a purchase order for a different device that
actually implements PPP rather than just claiming to ..."
:-/
--
James Carlson 42.703N 71.076W <carlsonj@xxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
