James Cameron writes: > pppd tears down a connection and starts a new one, without the modem > hanging up, in response to an LCP ConfReq that arrives out of the blue > from the peer.
That's exactly what the standards require pppd to do. When an LCP Configure-Request arrives, the LCP state machine leaves Opened state. This causes all the other state machines to get lower-layer-down, and they all come down as well. > I'm thinking it's a peer bug, but I'm not sure, and I can't do anything > about the peer, as it's a consumer service by an apparently > disinterested service provider who refuses to resolve problems if > "unsupported" software is used. > > Can anyone suggest anything? I'd strongly suggest finding a different service provider. Giving your money to a "service" provider that won't even accept a valid bug report doesn't strike me as a good plan. > Is there somewhere in pppd source where I can easily disable this > response, in case I can continue the existing connection? You'd probably have to modify the link_down() routine so that it doesn't do upper_layers_down. Note that by doing so, you're essentially making pppd non-compliant with the standards. I'm also not really sure it would fix the problem. How do you really know that this is an out-of-the-blue packet, and *not* the peer attempting to renegotiate the link for some reason? If it's the latter, which I suspect is the case, then just ignoring the out-of-the-blue packet will cause the link to go dead. In other words, you can do it, but I think it'd be wrong and self-defeating to do so. > The debug and dump output is here; > http://quozl.linux.org.au/mm-5100/2005-08-12/rtt-fail.log > (the SIGHUP after the restart is generated by my ip-down script) In reading this log, it looks to me like the peer just wanted to renegotiate the link. How do you know that's not what it wanted to do? Does this behavior happen with other PPP implementations? If not, then what's different with them? Assuming that it's a peer bug (and the peer doesn't actually *want* to renegotiate the link), you might be able to find out what causes the peer to behave this way and avoid that, rather than breaking pppd's state machine. Sometimes, bug-ridden peers (which this seems to be) are tickled by seemingly innocuous behaviors. Other implementations that don't have trouble with this problematic peer might ask for options you don't ask for or exhibit timing behaviors that you don't. Getting to the bottom of such issues is essentially debugging that remote peer from afar. It's not easy at all. One other bit of concern is that the peer says "mru 1500." That's the default, and there's just never any reason to ask for the well-known default. That means the peer is probably an idiot. -- James Carlson 42.703N 71.076W <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
