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 over on the normal restart timer), and the peer is sending Configure-Ack each time, but isn't bothering to send Configure-Request. The peer is either confused or broken. Based on the combination of symptoms, that's not too surprising. > embedded device is echoing the packets back to your host. No, it's not. It's sending Configure-Ack in response. I don't see anything wrong here, other than the fact that we're stuck in AckRcvd state because the peer won't send Configure-Request. > But I thought > pppd had code to detect that, and there's no sign of that detection > triggering. There's no loopback here, so nothing to detect. > I suggest you use the record option and use pppdump or wireshark on the > result, so as to find out what is happening. > > Other than that ... sounds like the embedded device wants something > different. If it works in a stable fashion with something else, a dump > of that data stream may be handy for comparison. I guess it depends on your tolerance level for broken devices and how much you value your time. ;-} -- 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
