headers
Andrew Gaylard | 9 Oct 08:30
Picon

pppd sometimes hangs on close

We are using pppd-2.4.4 (built from source, with debugging) to terminate
multiple incoming GRE-like tunnels on a server (Ubuntu Linux 2.6.24-19-server).
Occasionally (perhaps once in 1000 times) we get the following problem:

- the parent process (the process that does the GRE marshalling) hangs on a
write() to the pty master.  This hang keeps the CPU at 100%.
- at the same time, the child process (pppd) hangs in tty_disestablish_ppp
trying to set the previous line discipline on the pty slave (sys-linux.c:560).

If I attach to the parent process with gdb, display a backtrace, and
detach, this
appears to break the deadlock, and both of them exit cleanly like nothing was
wrong.  The same happens if I use "strace -p" on the parent process.  So this
looks like a race condition somewhere.

My pppd options look like this:

ms-dns 41.204.40.19
ms-dns 41.204.40.9
novj
asyncmap 0
noauth
local
lock
hide-password
-ac
-pc
+pap
mtu 1468
mru 1468
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Gaylard | 9 Oct 09:27
Picon

patch: allow COPTS to be specified to the radius plugin by the top level make

The following little patch to the -2.4.4 tree allows the radius plugin
to be built with the same COPTS as the other parts of ppp.
Thus,
    make COPTS="-pipe -Wall -g"
at the top level will propagate down as expected.

Andrew

diff -rU5 ppp-2.4.4/pppd/plugins/radius/Makefile.linux
ppp-2.4.4-new/pppd/plugins/radius/Makefile.linux
--- ppp-2.4.4/pppd/plugins/radius/Makefile.linux        2006-06-04
05:04:14.000000000 +0000
+++ ppp-2.4.4-new/pppd/plugins/radius/Makefile.linux    2008-09-26
15:07:56.000000000 +0000
@@ -10,11 +10,12 @@
 VERSION = $(shell awk -F '"' '/VERSION/ { print $$2; }' ../../patchlevel.h)

 INSTALL        = install

 PLUGIN=radius.so radattr.so radrealms.so
-CFLAGS=-I. -I../.. -I../../../include -O2 -fPIC -DRC_LOG_FACILITY=LOG_DAEMON
+COPTS=-O2
+CFLAGS=-I. -I../.. -I../../../include $(COPTS) -fPIC
-DRC_LOG_FACILITY=LOG_DAEMON

 # Uncomment the next line to include support for Microsoft's
 # MS-CHAP authentication protocol.
 CHAPMS=y
 # Uncomment the next line to include support for MPPE.
--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Mackerras | 9 Oct 13:50
Picon

Re: pppd creates route without "gateway" flag

James Carlson writes:

> Bill Unruh writes:
> > On Wed, 17 Sep 2008, Joakim Wennergren wrote:
> > 
> > > I just looked at my routing table, and the route pppd created does not
> > > have the "G" flag like I'm used to, is there a reason for this?
> > 
> > PPP is Peer to Peer Protocol. Ie, it is from one peer to another. It has
> > nothing whatsoever to do with gateways, etc. 
> 
> I think the original poster is talking about the default route
> inserted by the "defaultroute" option.  As he rightly notes, it's
> missing the "G" flag:
> 
> > > 0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
> 
> And that is in fact a gateway route.  The issue is whether that flag
> actually matters on Linux.

Why do you say it's a gateway route?  It doesn't have a gateway
address.  It's a route to the 0.0.0.0/0 network via the ppp0 device.

Paul.
--
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
James Carlson | 14 Oct 12:26

Re: pppd creates route without "gateway" flag

Paul Mackerras writes:
> > And that is in fact a gateway route.  The issue is whether that flag
> > actually matters on Linux.
> 
> Why do you say it's a gateway route?  It doesn't have a gateway
> address.  It's a route to the 0.0.0.0/0 network via the ppp0 device.

OK; fair point.  That point-to-point peer, though, still is the
'gateway' for all packets that match that route, even though we don't
have the (effectively useless) remote address stored in the route
itself.

If the flag is missing merely because the next-hop address isn't set,
then that explains it, and there's nothing wrong at all with the
original poster's system.

--

-- 
James Carlson         42.703N 71.076W         <carlsonj <at> workingcode.com>
--
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
myteron myteron | 14 Oct 14:26

Split dialup how to detect package loss and whats 10.64.64.64

Hi there,

I am living in the midlands of Ireland and internet here is somewhat
unreliable so I have 2 connections.

First I would like to know whats 10.64.64.64 as it looks to me as
somekind of generic gateway.
I get this thru wvdial in conjunction with ppp dialing into an 02
network via an E270 gsm modem.
Havent fiubd anything explaining this on the net.

However my main issue with split dialup that I have no elegant way to
detect package loss over one connection so that I can switch over to
the other one.

What basically happens is when there is package loss behind the
gateway and the routers IP stays up it all just hangs there.
So packages hang on the statefull connection until timeout but the
kernel still tries to route thrue that gw.

Surely I could write a script that icmp's the next hop but I don't
like the idea.

Thanks

Helge
--
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 | 2 comments |
headers
James Cameron | 15 Oct 00:33
Picon
Favicon

Re: Split dialup how to detect package loss and whats 10.64.64.64

Detecting packet loss over one connection so that you can switch over to
the other one ... yes, you will find that difficult.  In your situation,
the PPP peer is the modem, and you won't get LCP Echo loss because these
travel only between pppd and the modem firmware.  LCP will continue
despite loss of radio traffic ... and it will take some time for the
modem to give up and hang up.  The only way to detect loss is to use IP
packets.

In my experience most packet loss on GPRS modems is going to affect both
modems in the same vicinity, since the loss is mostly caused by the
cell, or the providers GPRS Core Network.

Now, on your other question ...

10.64.64.64 is a common remote IP address seen with these GPRS modems.
It comes from this line of the pppd source:

ipcp.c: ho->hisaddr = htonl(0x0a404040 + ifunit);

It is the address to use when the peer does not provide one.  The peer
in your case is the modem itself.  Not the provider's network.

You don't need a remote IP address for the link.  Don't worry about it.

The remainder of my post below is a rant, repeated from my earlier
investigation into this odd IP address.  ;-)

There is a common but false belief that a remote IP address for the link
needs to be known.
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Carlson | 15 Oct 14:09

Re: Split dialup how to detect package loss and whats 10.64.64.64

James Cameron writes:
> I've heard and seen that Windows systems show point to point links as if
> they are Ethernet adaptors ... and I shake my head in confusion.  Linux
> point to point links are different: the remote IP address has no use,
> and I find everything works fine without it.

I mostly agree with your rant; for the typical "simple" end-user
connection to an ISP, the remote address is not terribly necessary or
interesting.  But it's not quite accurate that a remote address "has
no use."

The first observation is that if you have a PPP link running IP, then
the termination point must (by definition) support IP.  Devices that
support IP but refuse to reveal an address are fairly boring, because
you usually can't talk directly to them, and they can't be managed.
Rather than being deliberately ornery, those devices ought to reveal
that address.

One obvious use of a remote address is in just testing the link at the
IP level.  If you have a remote address on the link, then you can ping
the peer and isolate IP-level link problems versus routing-related
problems.  If you don't have a usable remote address on the link, then
you can't necessarily directly ping the peer (even though it obviously
is an IP node), and anything you do contact will be at least one extra
hop away -- meaning that isolating problems is a bit harder.

Another use is in routing.  If you run a routing protocol, then the
source address on each peer's message will be local link's IP address,
and any unicast messages demanded by the protocol (e.g., running BGP)
will typically be to the remote address on the link.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rusty Russell | 16 Oct 13:13
Picon
Gravatar

[PATCH 1/5] remove CONFIG_KMOD from drivers

From: Johannes Berg <johannes <at> sipsolutions.net>

Straight forward conversions to CONFIG_MODULE; many drivers
include <linux/kmod.h> conditionally and then don't have any
other conditional code so remove it from those.

Signed-off-by: Johannes Berg <johannes <at> sipsolutions.net>
Cc: video4linux-list <at> redhat.com
Cc: David Woodhouse <dwmw2 <at> infradead.org>
Cc: linux-ppp <at> vger.kernel.org
Cc: dm-devel <at> redhat.com
Signed-off-by: Rusty Russell <rusty <at> rustcorp.com.au>
---
 drivers/md/md.c                                 |    7 -------
 drivers/media/video/cpia.c                      |    4 ----
 drivers/media/video/usbvision/usbvision-core.c  |    4 ----
 drivers/media/video/usbvision/usbvision-video.c |    4 ----
 drivers/media/video/v4l1-compat.c               |    4 ----
 drivers/media/video/v4l2-common.c               |    4 ----
 drivers/media/video/vino.c                      |    5 +----
 drivers/media/video/w9968cf.c                   |    4 ++--
 drivers/mtd/mtdpart.c                           |    2 --
 drivers/net/irda/sir_dongle.c                   |    2 --
 drivers/net/ppp_generic.c                       |   10 +++-------
 drivers/net/pppox.c                             |    9 ++-------
 drivers/video/fbmem.c                           |   17 ++---------------
 13 files changed, 10 insertions(+), 66 deletions(-)

diff -r 6251a9fdf8f9 drivers/md/md.c
--- a/drivers/md/md.c	Mon Aug 25 14:22:06 2008 +1000
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jar | 21 Oct 20:44
Picon
Picon

ppp0 and it's txqueuelen with HSDPA gsm modems

Hello

What would be "optimal" value for ppp0 device's txqueuelen, when it is 
used with HSDPA gsm modem for link which downlink speed is 1Mbit/s and 
uplink speed is 384kbit/s and ping ~80..100 ms? Is the default value 3 
just OK?

--

-- 
Best Regards, Jar
--
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 | 2 comments |
headers
Lie Arne | 22 Oct 09:11
Picon
Picon

RE: ppp0 and it's txqueuelen with HSDPA gsm modems

> -----Original Message-----
> From: linux-ppp-owner <at> vger.kernel.org 
> [mailto:linux-ppp-owner <at> vger.kernel.org] On Behalf Of Jar
> Sent: 21. oktober 2008 20:44
> To: linux-ppp <at> vger.kernel.org
> Subject: ppp0 and it's txqueuelen with HSDPA gsm modems
> 
> Hello
> 
> What would be "optimal" value for ppp0 device's txqueuelen, 
> when it is used with HSDPA gsm modem for link which downlink 
> speed is 1Mbit/s and uplink speed is 384kbit/s and ping 
> ~80..100 ms? Is the default value 3 just OK?
> 
> --
> Best Regards, Jar
Jar,

I would suggest using normal TCP calculation, i.e. that you dimension
the txqueue size after the "BDP rule": bandwidth x delay product. Using
your outbound numbers this is:
1,000,000 x 0.1 = 100,000 bits = 12,500 bytes. Assuming 1500 byte
packets, this is txqueue = 12,500 / 1500 = 8.3 packets. So you could try
txqueue size in the region 8-10, this should prevent queue starvation at
packet drop events caused by traffic overload, even if you only have one
single TCP flow.

Best regards,

Arne Lie
(Continue reading)

Permalink | Reply | 1 comment |

Gmane