headers
Jonathan Goodchild | 3 Mar 2005 18:37
Picon

syncppp and rejected magic numbers

There appears to be a bug in SYNCPPP - if it receives a Configure Reject
for the LCP Magic Number option, it doesn't remove the Magic Number
option from the next Configure Request, but sends the same thing again.

Consequently the LCP negotiation fails to converge.

Fortunately (from my point of view), I can change the PPP implementation
which led me to discover this behaviour, so it's not going to cause me a
problem, but it might do someone else...

---
Jonathan Goodchild
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
domen | 6 Mar 2005 23:23

[patch 1/1] list_for_each_entry: drivers-net-ppp_generic.c


Make code more readable with list_for_each_entry.
Compile tested.

Signed-off-by: Domen Puncer <domen <at> coderock.org>
Signed-off-by: Maximilian Attems <janitor <at> sternwelten.at>
Signed-off-by: Domen Puncer <domen <at> coderock.org>
---

 kj-domen/drivers/net/ppp_generic.c |   21 ++++++---------------
 1 files changed, 6 insertions(+), 15 deletions(-)

diff -puN drivers/net/ppp_generic.c~list-for-each-entry-drivers_net_ppp_generic drivers/net/ppp_generic.c
--- kj/drivers/net/ppp_generic.c~list-for-each-entry-drivers_net_ppp_generic	2005-03-05
16:09:02.000000000 +0100
+++ kj-domen/drivers/net/ppp_generic.c	2005-03-05 16:09:02.000000000 +0100
 <at>  <at>  -1228,8 +1228,7  <at>  <at>  static int ppp_mp_explode(struct ppp *pp

 	nch = 0;
 	hdrlen = (ppp->flags & SC_MP_XSHORTSEQ)? MPHDRLEN_SSN: MPHDRLEN;
-	list = &ppp->channels;
-	while ((list = list->next) != &ppp->channels) {
+	list_for_each(list, &ppp->channels) {
 		pch = list_entry(list, struct channel, clist);
 		nch += pch->avail = (skb_queue_len(&pch->file.xq) == 0);
 		/*
 <at>  <at>  -1688,7 +1687,7  <at>  <at>  static void
 ppp_receive_mp_frame(struct ppp *ppp, struct sk_buff *skb, struct channel *pch)
 {
 	u32 mask, seq;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Fowler | 8 Mar 2005 04:49
Favicon

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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Bill Unruh | 8 Mar 2005 07:03
Picon
Picon

Re: IPCP ConfRej's forever

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Clifford Kite | 8 Mar 2005 16:58
Favicon

Re: IPCP ConfRej's forever

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?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christopher Fowler | 8 Mar 2005 17:03
Favicon

Re: IPCP ConfRej's forever

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Clifford Kite | 8 Mar 2005 17:22
Favicon

Re: IPCP ConfRej's forever

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 <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |
headers
Christopher Fowler | 8 Mar 2005 18:27
Favicon

Re: IPCP ConfRej's forever

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bill Unruh | 8 Mar 2005 18:58
Picon
Picon

Re: IPCP ConfRej's forever

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christopher Fowler | 8 Mar 2005 19:06
Favicon

Re: IPCP ConfRej's forever

Ahh.  The FC <at>  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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane