Bill Unruh writes:
> > 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.
Or perhaps with reference to the original poster's message ... ?
> > 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.
Because that's how pppd works. See fsm_timeout(), and the
REQSENT/ACKRCVD/ACKSENT states. These call fsm_sconfreq(f, 1), which
then tells fsm_sconfreq() to avoid generating a new ID.
The FSM also invokes the `retransmit' callback when it processes the
TO+ event, so it's possible for xCP implementations to alter the
packet before resending. In lcp_callbacks, though, this function
pointer is NULL, meaning that LCP does nothing to alter the packet on
retransmit.
I checked the CVS repository, and this logic dates back to at least
1993 when the code was first imported to CVS. I suspect it dates back
much further, probably to the mid-80's original Carnegie-Mellon
implementation.
> 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.
The original poster claims this:
I have a situation where I'm trying to maintain a PPP connection from my
Linux PC to an embedded Linux device.
I have my doubts about the peer being a "Linux" device. If it is, it
looks like it's been extensively hacked by the vendor (it sure doesn't
behave like normal pppd), and he should probably contact them for
help.
> > "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."
"It's a darned shame our acceptance testing and product evaluation
process is so shoddy, isn't it? Oh well. It's like all other
reviews; you can pay me now or pay me later, but it'll cost much more
later."
--
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
