* Re: IPCP ConfRej's forever
2005-03-08 3:49 IPCP ConfRej's forever Christopher Fowler
@ 2005-03-08 6:03 ` Bill Unruh
2005-03-08 15:58 ` Clifford Kite
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Bill Unruh @ 2005-03-08 6:03 UTC (permalink / raw)
To: linux-ppp
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: IPCP ConfRej's forever
2005-03-08 3:49 IPCP ConfRej's forever Christopher Fowler
2005-03-08 6:03 ` Bill Unruh
@ 2005-03-08 15:58 ` Clifford Kite
2005-03-08 16:03 ` Christopher Fowler
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Clifford Kite @ 2005-03-08 15:58 UTC (permalink / raw)
To: linux-ppp
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: IPCP ConfRej's forever
2005-03-08 3:49 IPCP ConfRej's forever Christopher Fowler
2005-03-08 6:03 ` Bill Unruh
2005-03-08 15:58 ` Clifford Kite
@ 2005-03-08 16:03 ` Christopher Fowler
2005-03-08 16:22 ` Clifford Kite
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Christopher Fowler @ 2005-03-08 16:03 UTC (permalink / raw)
To: linux-ppp
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 Tue, 2005-03-08 at 10:58, Clifford Kite 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
> |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
>
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: IPCP ConfRej's forever
2005-03-08 3:49 IPCP ConfRej's forever Christopher Fowler
` (2 preceding siblings ...)
2005-03-08 16:03 ` Christopher Fowler
@ 2005-03-08 16:22 ` Clifford Kite
2005-03-08 17:27 ` Christopher Fowler
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Clifford Kite @ 2005-03-08 16:22 UTC (permalink / raw)
To: linux-ppp
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: IPCP ConfRej's forever
2005-03-08 3:49 IPCP ConfRej's forever Christopher Fowler
` (3 preceding siblings ...)
2005-03-08 16:22 ` Clifford Kite
@ 2005-03-08 17:27 ` Christopher Fowler
2005-03-08 17:58 ` Bill Unruh
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Christopher Fowler @ 2005-03-08 17:27 UTC (permalink / raw)
To: linux-ppp
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.
On Tue, 2005-03-08 at 11:22, Clifford Kite wrote:
> 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
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: IPCP ConfRej's forever
2005-03-08 3:49 IPCP ConfRej's forever Christopher Fowler
` (4 preceding siblings ...)
2005-03-08 17:27 ` Christopher Fowler
@ 2005-03-08 17:58 ` Bill Unruh
2005-03-08 18:06 ` Christopher Fowler
2005-03-09 2:58 ` Herbert Xu
7 siblings, 0 replies; 9+ messages in thread
From: Bill Unruh @ 2005-03-08 17:58 UTC (permalink / raw)
To: linux-ppp
On Tue, 8 Mar 2005, Christopher Fowler wrote:
> 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.
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.
>
> 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 agree that it should teminate and that this is a bug.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: IPCP ConfRej's forever
2005-03-08 3:49 IPCP ConfRej's forever Christopher Fowler
` (5 preceding siblings ...)
2005-03-08 17:58 ` Bill Unruh
@ 2005-03-08 18:06 ` Christopher Fowler
2005-03-09 2:58 ` Herbert Xu
7 siblings, 0 replies; 9+ messages in thread
From: Christopher Fowler @ 2005-03-08 18:06 UTC (permalink / raw)
To: linux-ppp
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.
On Tue, 2005-03-08 at 12:58, Bill Unruh wrote:
> On Tue, 8 Mar 2005, Christopher Fowler wrote:
>
> > 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.
>
> 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.
>
> >
> > 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 agree that it should teminate and that this is a bug.
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: IPCP ConfRej's forever
2005-03-08 3:49 IPCP ConfRej's forever Christopher Fowler
` (6 preceding siblings ...)
2005-03-08 18:06 ` Christopher Fowler
@ 2005-03-09 2:58 ` Herbert Xu
7 siblings, 0 replies; 9+ messages in thread
From: Herbert Xu @ 2005-03-09 2:58 UTC (permalink / raw)
To: linux-ppp
Christopher Fowler <cfowler@outpostsentinel.com> wrote:
> 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.
Having experienced the same problem myself I can tell you that 2.4.3 does
fix this bug.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread