I should always proof-read before sending. :-/ James Carlson wrote: > walter harms wrote: >> Oct 20 13:56:12 pppd[5792]: rcvd [LCP ConfReq id=0xc8 <asyncmap 0x0> <magic 0xab132318> <pcomp> <accomp>] >> Oct 20 13:56:12 pppd[5792]: sent [LCP ConfReq id=0xc9 <asyncmap 0x0> <magic 0xf79dba92> <pcomp> <accomp>] >> Oct 20 13:56:12 pppd[5792]: sent [LCP ConfAck id=0xc8 <asyncmap 0x0> <magic 0xab132318> <pcomp> <accomp>] >> Oct 20 13:56:12 pppd[5792]: rcvd [LCP ConfAck id=0xc8 <asyncmap 0x0> <magic 0xd71a0c90> <pcomp> <accomp>] > > Uh oh. It looks like the peer is broken. Note the ID number on that > message: it's 0xc8. That's the ID on the peer's own Configure-Request, > which makes no sense at all. One other clue I certainly should have noticed here is the magic number -- it's different from what we sent. So that is *not* merely an errant response on the peer's part. Why is the peer sending that last message above? I don't know. It's as though the peer is responding to an LCP Configure-Request that we never sent, at least according to the abbreviated log file presented here. (You don't need to post the whole multi-megabyte log file, but posting the LCP initial negotiation on the link and any LCP negotiation messages seen up to the point of failure would be extremely helpful.) What's the nature of the link between these two systems? Is it possible for LCP messages from one link to be replayed on another link? Is it possible for some other machine's messages to get injected on this link? Could the link itself store and replay messages? I think the first step would be finding out why the peer suddenly thought it received an LCP Configure-Request message from us with ID 0xc8 and Magic Number 0xd71a0c90, when we apparently sent no such thing. -- 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
