On Mon, 7 Mar 2005, Christopher Fowler wrote: |I have two hosts that are configured to dial each other on demand. | |One host is setup as 10.0.6.1:10.0.6.2 and the other as |192.168.5.6:192.168.5.7. When the 10.0.6.1 sends the IPCP ConfReq |packet to request the remote accept the config of 10.0.6.1:10.0.6.2 it |is promptly rejected by the 192.168.5.6 machine. This is totally |understandable since I did not provide the command line options |ipcp-allow-remote and ipcp-allow-local. My problem is that when this |happens the ppp proces on 192.168.5.6 never terminates the connection. |I get a stream of the folloing messages in syslog: | |Mar 7 22:14:23 dialup pppd[130]: rcvd [IPCP ConfReq id=0x52 <addrs |10.0.6.1 10.0.6.2>] |Mar 7 22:14:23 dialup pppd[130]: sent [IPCP ConfRej id=0x52 <addrs |10.0.6.1 10.0.6.2>]
<snip> |Mar 7 22:14:26 dialup pppd[130]: sent [IPCP ConfReq id=0x10] |Mar 7 22:14:26 dialup pppd[130]: rcvd [IPCP ConfReq id=0x6d <addrs |10.0.6.1 10.0.6.2>] |Mar 7 22:14:26 dialup pppd[130]: sent [IPCP ConfRej id=0x6d <addrs |10.0.6.1 10.0.6.2>] | | |And it goes on forever and ever. Should'nt there be a point where no |IPCP address could be negotiated and the remote terminate the |connection? First I'm not an expert, but this looks like the old-style IP addresses negotiation. That is, pppd fell back to this after failing to complete IPCP with the normal IP address option. Termination would seem to me to be appropriate after either side sends an IPCP request without any IP addresses that the other side accepts. |Could this be version related? The version that is on the remote is |2.4.1 and the version on local (10.0.6.1) is 2.4.2. Neither version is doing what I would consider as the Right Thing. But, since 2.4.1 apparently doesn't accept the empty IPCP request *finally* sent by 2.4.2 (near the end above), the 2.4.1 version appears to be the worst offender. --- Clifford Kite http://ckite.no-ip.net - 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
