Request for confirmation

Sorry to bother you: we are cleaning up our database and it appears that
you have previously signed up to eBuppies.com mailinglists and not
confirmed your subscription.We would like to give you the opportunity to
re-confirm your subscription. The instructions on how to confirm are below.

  Almost welcome to our newsletter(s) ...

  Someone, hopefully you, has subscribed your email address to the
following newsletters:

  If this is correct, please click the following link to confirm your
subscription.
  Without this confirmation, you will not receive any newsletters.

 
http://ebuppies.com/emailserv/?p=confirm&uid=692f2f4143f3f0ae2347fda2068c703f

  If this is not correct, you do not need to do anything, simply delete
this message.

  Thank you

--
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

pppd's mtu setup

Sorry I copy these from gitweb trunk:
when lcp is up, it will call netif_set_mtu to set stack's ppp interface mtu
with MIN(MIN(mtu, mru), ao->mru), but why it is followed by ppp_send_config
with mtu only?
the 2nd setting could be different with first setting.
I can see sys-linux didn't do anything with 2nd mtu setting so it is
correct, but why there is 2nd setting and with different mtu?

    mtu = ho->neg_mru? ho->mru: PPP_MRU;

1908     mru = go->neg_mru? MAX(wo->mru, go->mru): PPP_MRU;

1909 #ifdef HAVE_MULTILINK

1910     if (!(multilink && go->neg_mrru && ho->neg_mrru))

1911 #endif /* HAVE_MULTILINK */

1912         netif_set_mtu(f->unit, MIN(MIN(mtu, mru), ao->mru));

1913     ppp_send_config(f->unit, mtu,

1914                     (ho->neg_asyncmap? ho->asyncmap: 0xffffffff),

1915                     ho->neg_pcompression, ho->neg_accompression);

thanks,
xiaozhao
--

-- 

slow transfer speed issue between two ppp based servers

Hello everybody,

I am having a connection speed issue between two ppp based servers,
and I have no idea what is going wrong and how to fix it.

I would appreciated it if somebody with advanced networking skills can
take a look at my attachments with tcpdumps and my analyse report.

http://filebin.ca/hgnpt/tcpdumps.tar.gz

I did not know a more suited mailing list for this issue.

Many thanks in advance,

Kind regards,

Jelle

------------------------------------------------------------------------

# this document describes my issue with a way to slow transfer speed
# between my sammy server with pppoe g.shdsl and an alix05 server with
# ppp hsdpa umts

------------------------------------------------------------------------

# two download tests, demonstrating that the alix05 server can download
# with 250KB/s (umts hsdpa 3g)

Re: slow transfer speed issue between two ppp based servers

Jelle de Jong wrote:
> Hello everybody,
> 
> I am having a connection speed issue between two ppp based servers,
> and I have no idea what is going wrong and how to fix it.
> 
> I would appreciated it if somebody with advanced networking skills can
> take a look at my attachments with tcpdumps and my analyse report.
> 
> http://filebin.ca/hgnpt/tcpdumps.tar.gz

Is there any chance you could make the raw tcpdump files (rather than
the decoded text output) available?  It's much harder to debug things
when information has been subtracted.

Based on what little is available here, I'm seeing what seems to be an
RTT that jumps around a lot, from a few milliseconds on up to 150
milliseconds, and causing TCP to misbehave.  It's likely that this is a
kernel issue that needs to be investigated.

--

-- 
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

PPP and buffer sizes

Hello,

I am trying to debug a performance issue I am experiencing with 
L2TP-tunnels (created using xl2tpd). When I measure the UDP-performance 
of different desired throughputs using iperf together with the tunnel, I 
see that the throughput stabilizes at a certain speed while the packet 
loss increases. When I measure the performance using TCP together with 
the tunnel, I see a very high number of packet losses, forcing 
congestion control and resulting in a significantly lower throughput 
than without tunneling.

I guess this is caused by buffers being filled up and packets are 
dropped, however, I have not been able to figure out which buffer or 
exactly why this happens. If I remove the tunnels and measure the 
performance, the maximum supported throughput by the network is reached, 
so both the UDP and TCP send and receive buffers are big enough. I have 
also measured the processing delay caused by the L2TP-software and that 
is at most 50 microseconds, which should not affect the results.

L2TP passes packets to PPP after they have been decapsulated and, as far 
as I have understood, PPP + IP layer processing (which is on microsecond 
scale) is the last step before the packet is sent to the application 
layer. My question is therefore, is there anything in PPP that can 
explain what I am experiencing?

Thanks in advance for any help,
Kristian
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org

Re: slow transfer speed issue between two ppp based servers

James Carlson wrote, on 11-01-10 15:38:
> Is there any chance you could make the raw tcpdump files (rather than
> the decoded text output) available?  It's much harder to debug things
> when information has been subtracted.
> 
> Based on what little is available here, I'm seeing what seems to be an
> RTT that jumps around a lot, from a few milliseconds on up to 150
> milliseconds, and causing TCP to misbehave.  It's likely that this is a
> kernel issue that needs to be investigated.

I created an new tcpdump of the issue and attached it in the mail.

http://filebin.ca/zmmnws/tcpdump01.tar.gz

I changed the sammy servers pppoe connection to an normal eth5
interface to an ciso router that is providing a 50/50mbit fiber
interface. So the upload speed of the sammy server should be very
high. But is only 30KB when uploading to my mobile umts systems. When
uploading form an other server to the umts systems the upload speed is
the max of that server (100kB) so the umts systems should not be the
problem here.

We opened the tcmpdumps with wireshark and did an analyse > export
info and it showed a lot of "TCP Fast retransmissions" compared to the
the other tcmpdump of the good download from the ashley server.

I also tried the below kernels, but it did not change anything.

linux-image-686 | 2.6.30
linux-image-686 | 2.6.31

Re: slow transfer speed issue between two ppp based servers

Jelle de Jong wrote, on 15-01-10 15:20:
> James Carlson wrote, on 11-01-10 15:38:
>> Is there any chance you could make the raw tcpdump files (rather than
>> the decoded text output) available?  It's much harder to debug things
>> when information has been subtracted.
>>
>> Based on what little is available here, I'm seeing what seems to be an
>> RTT that jumps around a lot, from a few milliseconds on up to 150
>> milliseconds, and causing TCP to misbehave.  It's likely that this is a
>> kernel issue that needs to be investigated.
> 
> I created an new tcpdump of the issue and attached it in the mail.
> 
> http://filebin.ca/zmmnws/tcpdump01.tar.gz
> 
> I changed the sammy servers pppoe connection to an normal eth5
> interface to an ciso router that is providing a 50/50mbit fiber
> interface. So the upload speed of the sammy server should be very
> high. But is only 30KB when uploading to my mobile umts systems. When
> uploading form an other server to the umts systems the upload speed is
> the max of that server (100kB) so the umts systems should not be the
> problem here.
> 
> We opened the tcmpdumps with wireshark and did an analyse > export
> info and it showed a lot of "TCP Fast retransmissions" compared to the
> the other tcmpdump of the good download from the ashley server.
> 
> I also tried the below kernels, but it did not change anything.
> 
> linux-image-686 | 2.6.30

pppd hangs on SIGHUP

Hello,

	I am experiencing a strange, intermittent problem with pppd.  I am
running pppd version 2.4.4 under Debian "Lenny" on an old Dell Optiplex
GX260 using kernel 2.6.26-2-686.  I have a Calcomp A600 3G Wireless modem
dialing a broadband wireless carrier.  The system is configured as a linux
router running an openvpn client over the ppp0 connection, with dnsmasq
providing DHCP clients on eth0 with IP configuration and ntp providing a
clock source.  If I leave the router up and running, after 12 hours the ISP
disconnects the line.  I can avoid this by sending a SIGHUP every few hours.
I of course have pppd running with the persist option, and usually pppd will
dutifully hang up the modem and start the chat session over again to obtain
connectivity.  Frequently, however, pppd will simply hang rather than
restarting the connection.  Subsequent SIGTERM or SIGHUP signals will do
nothing whatsoever.  The only way (of which I know) to release the terminal
(/cev/ttyACM0) is to send a SIGKILL.  After doing so, /dev/ttyACM0 is
released, and I can use a utility such as minicom to access the modem.  I
can dial out and get a carrier.  I can see the ppp authentication request
from the ISP.  What I cannot do, however, is get pppd to come back up.  If I
start pppd again, it opens the /dev/ttyACM0 device and creates the lockfile,
but it does not attempt to run chat or evidently do anything else other than
refresh the lockfile if it is stale.  My only option at that point is to
reboot the host.  A warm reboot allows the router to call out again.
Rebooting the router is a rather Draconian approach, not to mention the fact
it takes a little bit of time.  The problem by no means happens every time,
but it does happen very frequently, perhaps one restart out of three. Is
there some way other than sending a SIGHUP to get pppd to hang up gracefully
and redial the line?  Is there something I can do to get pppd to start
working properly when it hangs, short of rebooting the router?

Re: pppd hangs on SIGHUP

On Tue, 19 Jan 2010, Leslie Rhorer wrote:

>
> Hello,
>
> 	I am experiencing a strange, intermittent problem with pppd.  I am
> running pppd version 2.4.4 under Debian "Lenny" on an old Dell Optiplex
> GX260 using kernel 2.6.26-2-686.  I have a Calcomp A600 3G Wireless modem
> dialing a broadband wireless carrier.  The system is configured as a linux
> router running an openvpn client over the ppp0 connection, with dnsmasq
> providing DHCP clients on eth0 with IP configuration and ntp providing a
> clock source.  If I leave the router up and running, after 12 hours the ISP
> disconnects the line.  I can avoid this by sending a SIGHUP every few hours.
> I of course have pppd running with the persist option, and usually pppd will
> dutifully hang up the modem and start the chat session over again to obtain
> connectivity.  Frequently, however, pppd will simply hang rather than
> restarting the connection.  Subsequent SIGTERM or SIGHUP signals will do
> nothing whatsoever.  The only way (of which I know) to release the terminal
> (/cev/ttyACM0) is to send a SIGKILL.  After doing so, /dev/ttyACM0 is
> released, and I can use a utility such as minicom to access the modem.  I
> can dial out and get a carrier.  I can see the ppp authentication request
> from the ISP.  What I cannot do, however, is get pppd to come back up.  If I
> start pppd again, it opens the /dev/ttyACM0 device and creates the lockfile,
> but it does not attempt to run chat or evidently do anything else other than
> refresh the lockfile if it is stale.  My only option at that point is to
> reboot the host.  A warm reboot allows the router to call out again.
> Rebooting the router is a rather Draconian approach, not to mention the fact
> it takes a little bit of time.  The problem by no means happens every time,
> but it does happen very frequently, perhaps one restart out of three. Is
> there some way other than sending a SIGHUP to get pppd to hang up gracefully

Re: pppd hangs on SIGHUP

On Tue, Jan 19, 2010 at 09:34:05PM -0800, Bill Unruh wrote:
> Leslie wrote:
> >asyncmap 0
> Not needed.

Agreed, the default is zero.

> >auth
> definitely do not want.
> You do not want them to authenticate to you.

Generally true.  This might be an exception though.  And it shouldn't
have anything to do with the reported problem of connections not
persisting after a SIGHUP.

> >"" "AT"
> Try AT&F
> instead

That will have the side-effect of resetting the modem settings.  Don't
do this if you've set them carefully prior to starting pppd.

--

-- 
James Cameron
http://quozl.linux.org.au/
--
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