IPCP ConfRej's forever

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>]
Mar  7 22:14:23 dialup pppd[130]: rcvd [IPCP ConfReq id=0x53 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:23 dialup pppd[130]: sent [IPCP ConfRej id=0x53 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:23 dialup pppd[130]: rcvd [IPCP ConfReq id=0x54 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:23 dialup pppd[130]: sent [IPCP ConfRej id=0x54 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: rcvd [IPCP ConfReq id=0x55 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: sent [IPCP ConfRej id=0x55 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: rcvd [IPCP ConfReq id=0x56 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: sent [IPCP ConfRej id=0x56 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: rcvd [IPCP ConfReq id=0x57 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: sent [IPCP ConfRej id=0x57 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: rcvd [IPCP ConfReq id=0x58 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: sent [IPCP ConfRej id=0x58 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: rcvd [IPCP ConfReq id=0x59 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: sent [IPCP ConfRej id=0x59 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: rcvd [IPCP ConfReq id=0x5a <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: sent [IPCP ConfRej id=0x5a <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: rcvd [IPCP ConfReq id=0x5b <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: sent [IPCP ConfRej id=0x5b <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: rcvd [IPCP ConfReq id=0x5c <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: sent [IPCP ConfRej id=0x5c <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: rcvd [IPCP ConfReq id=0x5d <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:24 dialup pppd[130]: sent [IPCP ConfRej id=0x5d <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: rcvd [IPCP ConfReq id=0x5e <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: sent [IPCP ConfRej id=0x5e <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: rcvd [IPCP ConfReq id=0x5f <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: sent [IPCP ConfRej id=0x5f <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: rcvd [IPCP ConfReq id=0x60 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: sent [IPCP ConfRej id=0x60 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: rcvd [IPCP ConfReq id=0x61 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: sent [IPCP ConfRej id=0x61 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: rcvd [IPCP ConfReq id=0x62 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: sent [IPCP ConfRej id=0x62 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: rcvd [IPCP ConfReq id=0x63 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: sent [IPCP ConfRej id=0x63 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: rcvd [IPCP ConfReq id=0x64 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: sent [IPCP ConfRej id=0x64 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: rcvd [IPCP ConfReq id=0x65 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: sent [IPCP ConfRej id=0x65 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: rcvd [IPCP ConfReq id=0x66 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:25 dialup pppd[130]: sent [IPCP ConfRej id=0x66 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: rcvd [IPCP ConfReq id=0x67 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: sent [IPCP ConfRej id=0x67 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: rcvd [IPCP ConfReq id=0x68 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: sent [IPCP ConfRej id=0x68 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: rcvd [IPCP ConfReq id=0x69 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: sent [IPCP ConfRej id=0x69 <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: rcvd [IPCP ConfReq id=0x6a <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: sent [IPCP ConfRej id=0x6a <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: rcvd [IPCP ConfReq id=0x6b <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: sent [IPCP ConfRej id=0x6b <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: rcvd [IPCP ConfReq id=0x6c <addrs
10.0.6.1 10.0.6.2>]
Mar  7 22:14:26 dialup pppd[130]: sent [IPCP ConfRej id=0x6c <addrs
10.0.6.1 10.0.6.2>]
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?

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.

Thanks,
Chris Fowler

Why would you have both set both local and remote IP AND have them be incompatible? This makes no sense. Why not put both on the same address range?

Either have just one or have each set their own local but not remote IP.

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

I'm debating about upgrading to 2.4.3 on the remote end but I looked in the ChangeLog that comes with the source and see nothing about this. I assumed that if it was a bug it was not fixed due to it not being listed in the changeLog.

On Mon, 7 Mar 2005, Bill Unruh wrote:

|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
|
|Why would you have both set both local and remote IP AND have them be
|incompatible? This makes no sense. Why not put both on the same address
|range?
|
|Either have just one or have each set their own local but not remote IP.

He might want the dialed-to peer to be able to access a LAN through the dial-out peer?

---
Clifford Kite http://ckite.no-ip.net

Te remote is a locked down device. It is an embedded device running Linux. each ppp profile is tied to a port. The profile determines what command line options pppd is executed with.

In one case our FC2 server will dial in with ipaddresses that the remote needs to accept. In the other case a Windows laptop will dial-in requesting remote ip addresses.

When testnig command line arguments I found this problem of when a server dials in and tries wants to use addresses that are not configured for that profile then this forever loop occurs. since all this happens over dial-up a misconfiguration on the users part in the profile will cause a very high phone bill since the remote nor the server terminate since they can not agree on the correct addresses to use.

I guess my question would be, why the FC2 needs to supply the addresses. Potentially the only possible reason would be if the remote site MUST access the web and you want to do proxyarp. But somehow I doubt this for a locked down device. If not, then just have all the system accept that machine's addresses.

I agree that it should teminate and that this is a bug.

Ahh. The FC@ and the Remote operate in demand mode. pppd is running at all times on each but there is no physical connection between them until packets are sent. Then the connection's idle limit is 30 seconds. So the two devices speak via IP with our software but aer only connected on demand with modems.

�