headers
walter harms | 3 Nov 09:59
Picon
Favicon

Re: pppd & ntpd


Charlie Brady schrieb:
> 
> Easiest solution to your problem is likely to be having your client do
> ntp sync against a different server - plenty exist.
> 

This is no solution for this special case, there is only one server in reach
and that is exactly the server that does have the problem.

re,
 wh

--
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
Ben McKeegan | 12 Nov 14:09
Picon
Favicon

[PATCH] ppp: fix BUG on non-linear SKB (multilink receive)

PPP does not correctly call pskb_may_pull() on all necessary receive paths
before reading the PPP protocol, thus causing PPP to report seemingly
random 'unsupported protocols' and eventually trigger BUG_ON(skb->len <
skb->data_len) in skb_pull_rcsum() when receiving multilink protocol in
non-linear skbs.

ppp_receive_nonmp_frame() does not call pskb_may_pull() before reading the
protocol number.  For the non-mp receive path this is not a problem, as
this check is done in ppp_receive_frame().  For the mp receive path,
ppp_mp_reconstruct() usually copies the data into a new linear skb.
However, in the case where the frame is made up of a single mp fragment,
the mp header is pulled and the existing skb used.  This skb was then
passed to ppp_receive_nonmp_frame() without checking if the encapsulated
protocol header can safely be read.

Signed-off-by: Ben McKeegan <ben <at> netservers.co.uk>
---
This a long standing bug we have observed with PPP over L2TP received on
an e1000e interface, although it may arise with other PPP encapsulations
or devices.

diff -uprN linux-2.6.31.6/drivers/net/ppp_generic.c linux-2.6.31.6-ppp-non-linear-skb/drivers/net/ppp_generic.c
--- linux-2.6.31.6/drivers/net/ppp_generic.c	2009-11-10 00:32:31.000000000 +0000
+++ linux-2.6.31.6-ppp-non-linear-skb/drivers/net/ppp_generic.c	2009-11-12
11:58:40.000000000 +0000
@@ -1944,7 +1944,13 @@ ppp_receive_mp_frame(struct ppp *ppp, st

 	/* Pull completed packets off the queue and receive them. */
 	while ((skb = ppp_mp_reconstruct(ppp)))
-		ppp_receive_nonmp_frame(ppp, skb);
(Continue reading)

Permalink | Reply | 3 comments |
headers
Libor Pechacek | 12 Nov 17:48
Picon

[PATCH 0/3] pppd man page update

Hi,

Some time ago I was debugging a problem related to IPCP negotiation, and found
out that there are some inconsistencies between pppd manual page and the code.

The following patches correct the problem.  Please, be so kind as to review the
patches, and commit them to PPP GIT repository.

Feedback is welcome.

Libor
--
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
Libor Pechacek | 12 Nov 17:50
Picon

[PATCH 1/3] man page update - default value of *-max-failure

Default maximum number of NAKs received before sending REJs was changed to 5 by
commit e9543fef.  There does not seem to be a special value for IPX, therefore
I change 3 to 5 for ipxcp-max-failure too.

Signed-off-by: Libor Pechacek <lpechacek <at> suse.cz>
---
 pppd/pppd.8 |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/pppd/pppd.8 b/pppd/pppd.8
index 8ea8200..47c5c40 100644
--- a/pppd/pppd.8
+++ b/pppd/pppd.8
@@ -455,7 +455,7 @@ Set the maximum number of IPv6CP configure-request transmissions to
 .TP
 .B ipv6cp\-max\-failure \fIn
 Set the maximum number of IPv6CP configure-NAKs returned before starting
-to send configure-Rejects instead to \fIn\fR (default 10).
+to send configure-Rejects instead to \fIn\fR (default 5).
 .TP
 .B ipv6cp\-max\-terminate \fIn
 Set the maximum number of IPv6CP terminate-request transmissions to
@@ -522,7 +522,7 @@ system will send to \fIn\fR. The default is 10.
 .TP
 .B ipxcp\-max\-failure \fIn
 Set the maximum number of IPXCP NAK frames which the local system will
-send before it rejects the options. The default value is 3.
+send before it rejects the options. The default value is 5.
 .TP
 .B ipxcp\-max\-terminate \fIn
(Continue reading)

Permalink | Reply | 0 comments |
headers
Libor Pechacek | 12 Nov 17:51
Picon

[PATCH 2/3] man page update - meaning of *-max-failure

The *-max-failure values are used not only for the configure-NAKs sent, but
also for NAKs received - see commit ec27e674.

Signed-off-by: Libor Pechacek <lpechacek <at> suse.cz>
---
 pppd/pppd.8 |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/pppd/pppd.8 b/pppd/pppd.8
index 47c5c40..622ce97 100644
--- a/pppd/pppd.8
+++ b/pppd/pppd.8
@@ -433,7 +433,8 @@ Set the maximum number of IPCP configure-request transmissions to
 .TP
 .B ipcp\-max\-failure \fIn
 Set the maximum number of IPCP configure-NAKs returned before starting
-to send configure-Rejects instead to \fIn\fR (default 10).
+to send configure-Rejects instead to \fIn\fR (default 10).  This option
+applies to configure-NAKs received as well.
 .TP
 .B ipcp\-max\-terminate \fIn
 Set the maximum number of IPCP terminate-request transmissions to
@@ -455,7 +456,8 @@ Set the maximum number of IPv6CP configure-request transmissions to
 .TP
 .B ipv6cp\-max\-failure \fIn
 Set the maximum number of IPv6CP configure-NAKs returned before starting
-to send configure-Rejects instead to \fIn\fR (default 5).
+to send configure-Rejects instead to \fIn\fR (default 5).  This option
+applies to configure-NAKs received as well.
 .TP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Libor Pechacek | 12 Nov 17:52
Picon

[PATCH 3/3] man page update - default value of ipcp-max-failure

Default maximum number of IPCP NAKs received before sending REJs was changed to
100 by commit 29bdd4bc.

Signed-off-by: Libor Pechacek <lpechacek <at> suse.cz>
---
 pppd/pppd.8 |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/pppd/pppd.8 b/pppd/pppd.8
index 622ce97..03d128c 100644
--- a/pppd/pppd.8
+++ b/pppd/pppd.8
@@ -433,7 +433,7 @@ Set the maximum number of IPCP configure-request transmissions to
 .TP
 .B ipcp\-max\-failure \fIn
 Set the maximum number of IPCP configure-NAKs returned before starting
-to send configure-Rejects instead to \fIn\fR (default 10).  This option
+to send configure-Rejects instead to \fIn\fR (default 100).  This option
 applies to configure-NAKs received as well.
 .TP
 .B ipcp\-max\-terminate \fIn
--

-- 
1.6.0.2

--
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 | 0 comments |
headers
Mark Bamler | 12 Nov 18:44

(unknown)

subscribe linux-ppp

--
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
Mark Ryden | 13 Nov 14:54
Picon

getting the device of the ppp connection

Hello,
  Is there a way from user space to know which device is the one which
the ppp connection uses ?

What I mean is this: I have eth0 - eth3 on a machine, and a ppp
connection. I want to know by a
short program which device is the one which the ppp connection is
using (I know that usually this can
be deduced by running "ps" for the corresponding ppp daemon, and
inspecting the parameters; for example, with pppoe, I have "-I eth1"
parameter (-I stands for interface). But I want a more general
way which can be used in cases when we cannot get this info).

I tried to get info by an ioctl on ("dev/ppp") thus:

  ...
  ...
  int fd = open("/dev/ppp", O_RDWR);
  int ifunit;
  int res;
  if (fd>0) {
      res = ioctl(fd,PPPIOCATTACH,&ifunit);
		
      if (res==0)
	printf("ifunit=%d\n",ifunit);
  }

and got ifunit=0 when using eth0 ; but I ****also**** got  ifunit=1
when using eth1.
So - is there a way to get the interface from the unit number ? or any other
(Continue reading)

Permalink | Reply | 6 comments |
headers
Charlie Brady | 13 Nov 15:01
Picon
Picon

Re: getting the device of the ppp connection


On Fri, 13 Nov 2009, Mark Ryden wrote:

> What I mean is this: I have eth0 - eth3 on a machine, and a ppp
> connection. I want to know by a
> short program which device is the one which the ppp connection is
> using (I know that usually this can
> be deduced by running "ps" for the corresponding ppp daemon, and
> inspecting the parameters; for example, with pppoe, I have "-I eth1"
> parameter (-I stands for interface). But I want a more general
> way which can be used in cases when we cannot get this info).

I would do this via an environment variable that you set via your start 
script:

PPPOE_DEVICE=eth1 pppoe .... -I eth1

Have a look at daemontools or runit for mechanisms to give you good 
reliable control of the execution environment of long-running processes.

---
Charlie
--
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
walter harms | 13 Nov 16:00
Picon
Favicon

Re: getting the device of the ppp connection


Charlie Brady schrieb:
> 
> On Fri, 13 Nov 2009, Mark Ryden wrote:
> 
>> What I mean is this: I have eth0 - eth3 on a machine, and a ppp
>> connection. I want to know by a
>> short program which device is the one which the ppp connection is
>> using (I know that usually this can
>> be deduced by running "ps" for the corresponding ppp daemon, and
>> inspecting the parameters; for example, with pppoe, I have "-I eth1"
>> parameter (-I stands for interface). But I want a more general
>> way which can be used in cases when we cannot get this info).
> 
> I would do this via an environment variable that you set via your start
> script:
> 
> PPPOE_DEVICE=eth1 pppoe .... -I eth1
> 
> Have a look at daemontools or runit for mechanisms to give you good
> reliable control of the execution environment of long-running processes.
> 
> ---

you can scan the output of ifconfig -a,
but normaly pppd setups a ppp0.

re,
 wh
(Continue reading)

Permalink | Reply | 3 comments |

Gmane