Iordan Neshev wrote: > This is the peer's response: > [0x7E 0x80 0x21 0x04 0x01 0x00 0x10 0x81 0x06 0x00 0x00 0x00 0x00 0x81 > 0x06 0x00 0x00 0x00 0x00 0xF4 0x79 0x7E ] > Our device reported: > pppInput[0]: IPCP len=16 > fsm_input(IPCP): code 4,id 1, len 16 > fsm_rconfnakrej(IPCP): Rcvd id 1 state=6 (LS_REQSENT) > ipcp_rejci: received bad Reject! Yep; that violates the RFC. It's a garbage message. > The qustion is: Does somebody know why the peer rejected twice DNS1? Only the designer of that peer system knows for sure. It looks like a bug in that system. > The GSM operator did not reply this question, that's why I'm asking here. > Also, does pppd behave properly in this case? I believe that it does. It shouldn't tolerate obvious protocol violations from the peer, because it's not generally possible to "guess" what the peer might have meant for arbitrary nonsense. It should be possible, though, to create an option to allow pppd to ignore any unrequested (or duplicated) options in Reject messages. Whether doing so, and thus continuing to make a connection with an obviously malfunctioning peer, is a good idea is perhaps subject to some debate. > We are using a slightly modified pppd 2.3.11 with some backports from > all releases till pppd 2.4.5 > on an embedded device if it matters. My recommendation: get a peer that follows the standards. -- 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
