On Wed, 2 Apr 2008, James Carlson wrote:

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

Since "James Cameron" was not the original poster, your suddenly using "we"
was confusing. It was not at all clear that you were in any way related to
the original poster, and it was not clear whether your descriptions were
hypothetical or based on some facts.


>
> I can certainly use other words if those two offend you in some way.

Nope, clarification is sufficient. So when you make statements as to what
happens in the negotiation attempts, we are to take them as having some
basis in fact and personal experience.




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

Can be. But why make it so.

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

Probably true. What is that "other side"? Maybe someone here has experience
with it, rather than everyone having to guess at what is going on.


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

Then I would follow that. Agreed. But it could have been "We just purchased
5000 of those things at a really cheap non-returnable deal. You better make
them work."


--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo@vger...
More majordomo info at  http://vger.kernel.org/majordomo-info.html