Why does pppd (pppoe) go to 95% to 100% of CPU? - Networking

This is a discussion on Why does pppd (pppoe) go to 95% to 100% of CPU? - Networking ; I have a couple of mandrake systems that have DSL internet connections handled by rp-pppoe userspace. After a few hours or days CPU usage inevitably pegs out at 95% plus. One of these systems is a pentium 133, the other ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Why does pppd (pppoe) go to 95% to 100% of CPU?

  1. Why does pppd (pppoe) go to 95% to 100% of CPU?

    I have a couple of mandrake systems that have DSL internet connections
    handled by rp-pppoe userspace. After a few hours or days CPU usage
    inevitably pegs out at 95% plus. One of these systems is a pentium 133,
    the other is a AMD Athlon XP 2500. Despite the differences in the systems'
    respective power pppd wants it all after a while.
    What could be going on?
    I've tried synchronous vs. asynchronous options in the pppoe.conf file.
    One system has clamp_mss=1412 set to on because it is a gateway for a LAN,
    the other system does not because it is standalone. None of it matters.
    Please clue me in. As I say, for a while, maybe most of a day, or a couple
    of days, things are fine--then the CPU meter pegs out slowing the systems,
    causing poor internet service for those relying on the systems and even
    maybe causing instability. One of these systems can have this problem and
    it disconnects daily at night and reconnects in the morning. The other is
    supposed to be connected always.

    thanks for all the enlightenment in advance.
    ~/h.

    --
    Get Big Brother out of my email to reply.

  2. Re: Why does pppd (pppoe) go to 95% to 100% of CPU?

    hazzmat wrote:
    > I have a couple of mandrake systems that have DSL internet connections
    > handled by rp-pppoe userspace. After a few hours or days CPU usage
    > inevitably pegs out at 95% plus. One of these systems is a pentium 133,
    > the other is a AMD Athlon XP 2500. Despite the differences in the systems'
    > respective power pppd wants it all after a while.
    > What could be going on?


    What does "tcpdump -vn -i ppp0" show at 95% plus?

    --
    Clifford Kite

  3. Re: Why does pppd (pppoe) go to 95% to 100% of CPU?

    On Sat, 17 Mar 2007 14:24:29 -0500, Clifford Kite wrote:

    > hazzmat wrote:
    >> I have a couple of mandrake systems that have DSL internet connections
    >> handled by rp-pppoe userspace. After a few hours or days CPU usage
    >> inevitably pegs out at 95% plus. One of these systems is a pentium 133,
    >> the other is a AMD Athlon XP 2500. Despite the differences in the systems'
    >> respective power pppd wants it all after a while.
    >> What could be going on?

    >
    > What does "tcpdump -vn -i ppp0" show at 95% plus?



    Thanks. I'll have to check next time this happens. I have them scripted to
    check for this high load condition periodically and alert me. I was
    heading in the direction of an automated check that restarts the dsl
    service when the high load occurs, since restarting the adsl service
    "fixes" the problem (until the next time). So you think it's fragmented
    packets that have to be put back together, or...?

    One frustrating element: I can't find out easily what options pppd should
    have. There's a number of files where rp-pppoe gets its options from or
    *might* be getting its options from. And google including
    google-groups searches on this ng as well (as all ng.s) hasn't been too
    helpful in finding me some definitive pages on what options pppd should be
    running with for ppp over ethernet.

    Thanks. I'll have the data for a full reply next time.
    ~/h.

    --
    Get Big Brother out of my email to reply.

  4. Re: Why does pppd (pppoe) go to 95% to 100% of CPU?

    I'm sending you a tcpdump taken during a time of high pppd load (87%-89%
    when I noticed and started the tcpdump command)

    Here is the line with the pppd options from adsl-connect:
    # Standard PPP options we always use
    PPP_STD_OPTIONS="$PLUGIN_OPTS noipdefault noauth default-asyncmap $DEFAULTROUTE
    hide-password nodetach $PEERDNS mtu 1492 mru 1492 noaccomp noccp nobsdcomp nodef
    late nopcomp novj novjccomp user $USER lcp-echo-interval $LCP_INTERVAL lcp-echo-
    failure $LCP_FAILURE $PPPD_EXTRA"

    If I ever changed anything there I don't remember it. Ifconfig shows the
    ethernet card used for pppoe has an MTU of 1500. This is the system that
    has CLAMP_MSS set to 1412.


    On Sun, 18 Mar 2007 17:25:46 -0500, Clifford Kite wrote:

    > hazzmat wrote:
    >> On Sat, 17 Mar 2007 14:24:29 -0500, Clifford Kite wrote:
    >>>
    >>> What does "tcpdump -vn -i ppp0" show at 95% plus?

    >
    >>

    > MSS problems seem to be encountered frequently when using PPPoE, despite
    > attempts to work around them. In particular such a problem might cause a
    > process to try again and again to do something and fail, which could be
    > happening in this case. A DNS server trying to get zone updates would
    > be a candidate.
    >
    >> .

    >
    > In the (3.8) pppoe script pppoe-connect there are a number of those
    > options given under the heading
    >
    > # Standard PPP options we always use
    >
    > which seem reasonable to me, but be aware that I've not used PPPoE.
    >
    > If you want a full listing of the pppd options currently configured
    > for pppoe, try temporarily adding the pppd "dryrun" option to say,
    > /etc/ppp/options, and start pppoe (it will fail). See man pppd.
    >




    >> --
    >> Get Big Brother out of my email to reply.


    --
    Get Big Brother out of my email to reply.

  5. Re: Why does pppd (pppoe) go to 95% to 100% of CPU?

    On Sun, 18 Mar 2007 17:25:46 -0500, Clifford Kite wrote:
    What does "tcpdump -vn -i ppp0" show at 95% plus?

    I was going to send this directly to you but then I saw you had outdone me
    in the email address obfuscation department.

    22:46:47.683683 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 63.208.196.90.53: 5812 [1au] A? myrouter.homedns.org. (50)
    22:46:47.768625 IP (tos 0x0, ttl 47, id 20391, offset 0, flags [none], proto: UDP (17), length: 271) 63.208.196.90.53 > 68.211.148.46.2048: 5812*- 1/5/6 myrouter.homedns.org. A[|domain]
    22:47:03.167880 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 76) 68.211.148.46.123 > 216.27.185.42.123: NTPv4, length 48
    Client, Leap indicator: (0), Stratum 11, poll 9s, precision -18
    Root Delay: 0.000000, Root dispersion: 0.012802, Reference-ID: 127.127.1.0
    Reference Timestamp: 3383261163.122205999 (2007/03/18 22:46:03)
    Originator Timestamp: 3383260966.028969999 (2007/03/18 22:42:46)
    Receive Timestamp: 3383260966.085657999 (2007/03/18 22:42:46)
    Transmit Timestamp: 3383261223.167523999 (2007/03/18 22:47:03)
    Originator - Receive Timestamp: +0.056687999
    Originator - Transmit Timestamp: +257.138554000
    22:47:03.278711 IP (tos 0x0, ttl 45, id 53813, offset 0, flags [DF], proto: UDP (17), length: 76) 216.27.185.42.123 > 68.211.148.46.123: NTPv4, length 48
    Server, Leap indicator: (0), Stratum 2, poll 9s, precision -20
    Root Delay: 0.064544, Root dispersion: 0.075027, Reference-ID: 192.43.244.18
    Reference Timestamp: 3383260953.416635999 (2007/03/18 22:42:33)
    Originator Timestamp: 3383261223.167523999 (2007/03/18 22:47:03)
    Receive Timestamp: 3383261223.223599999 (2007/03/18 22:47:03)
    Transmit Timestamp: 3383261223.223620999 (2007/03/18 22:47:03)
    Originator - Receive Timestamp: +0.056075999
    Originator - Transmit Timestamp: +0.056096999
    22:47:47.794580 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 63.208.196.90.53: 17877 [1au] A? myrouter.homedns.org. (50)
    22:47:47.878019 IP (tos 0x0, ttl 47, id 63177, offset 0, flags [none], proto: UDP (17), length: 271) 63.208.196.90.53 > 68.211.148.46.2048: 17877*- 1/5/6 myrouter.homedns.org. A[|domain]
    22:48:25.260800 IP (tos 0x0, ttl 127, id 10736, offset 0, flags [DF], proto: TCP (6), length: 48) 68.211.148.46.3033 > 68.215.208.239.80: S, cksum 0xb52c (correct), 2868897793:2868897793(0) win 16384
    22:48:28.263114 IP (tos 0x0, ttl 127, id 10737, offset 0, flags [DF], proto: TCP (6), length: 48) 68.211.148.46.3033 > 68.215.208.239.80: S, cksum 0xb52c (correct), 2868897793:2868897793(0) win 16384
    22:48:34.197737 IP (tos 0x0, ttl 127, id 10738, offset 0, flags [DF], proto: TCP (6), length: 48) 68.211.148.46.3033 > 68.215.208.239.80: S, cksum 0xb52c (correct), 2868897793:2868897793(0) win 16384
    22:48:47.903381 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 63.208.196.90.53: 53689 [1au] A? myrouter.homedns.org. (50)
    22:48:47.990133 IP (tos 0x0, ttl 47, id 44082, offset 0, flags [none], proto: UDP (17), length: 271) 63.208.196.90.53 > 68.211.148.46.2048: 53689*- 1/5/6 myrouter.homedns.org. A[|domain]
    22:49:10.436550 IP (tos 0x0, ttl 46, id 0, offset 0, flags [DF], proto: UDP (17), length: 485) 202.97.238.202.57877 > 68.211.148.46.1026: UDP, length 457
    22:49:31.116522 IP (tos 0x0, ttl 45, id 0, offset 0, flags [DF], proto: UDP (17), length: 485) 221.209.110.48.45878 > 68.211.148.46.1026: UDP, length 457
    22:49:48.016167 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 63.208.196.90.53: 54286 [1au] A? myrouter.homedns.org. (50)
    22:49:49.011043 IP (tos 0x0, ttl 127, id 11000, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1160 > 205.152.37.23.53: 162+ A? printer.myrouter.homedns.org. (50)
    22:49:50.016800 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 204.13.249.81.53: 13612 [1au] A? myrouter.homedns.org. (50)
    22:49:54.017927 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 204.13.250.81.53: 52486 [1au] A? myrouter.homedns.org. (50)
    22:49:54.023732 IP (tos 0x0, ttl 127, id 11032, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1160 > 205.152.37.23.53: 11938+ A? printer.myrouter.homedns.org. (50)
    22:49:58.018914 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 67) 68.211.148.46.2048 > 213.155.150.205.53: 59011 A? myrouter.homedns.org. (39)
    22:49:59.024773 IP (tos 0x0, ttl 127, id 11089, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1160 > 205.152.37.23.53: 16805+ A? printer.myrouter.homedns.org. (50)
    22:49:59.154697 IP (tos 0x0, ttl 127, id 11094, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1027 > 205.152.37.23.53: 57252+ A? printer.myrouter.homedns.org. (50)
    22:50:02.020093 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 67) 68.211.148.46.2048 > 63.170.10.81.53: 19736 A? myrouter.homedns.org. (39)
    22:50:02.868708 IP (tos 0x0, ttl 127, id 11396, offset 0, flags [none], proto: UDP (17), length: 75) 68.211.148.46.1026 > 205.152.37.23.53: 5799+ A? vandals.myrouter.homedns.org. (47)
    22:50:04.024710 IP (tos 0x0, ttl 127, id 11419, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1160 > 205.152.37.23.53: 1703+ A? printer.myrouter.homedns.org. (50)
    22:50:04.154568 IP (tos 0x0, ttl 127, id 11422, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1027 > 205.152.37.23.53: 26022+ A? printer.myrouter.homedns.org. (50)
    22:50:06.026874 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 67) 68.211.148.46.2048 > 63.208.196.90.53: 42636 A? myrouter.homedns.org. (39)
    22:50:06.029922 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 63.208.196.90.53: 21318% [1au] AAAA? ns1.dyndns.org. (43)
    22:50:06.032884 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 63.208.196.90.53: 38091% [1au] AAAA? ns2.dyndns.org. (43)
    22:50:06.035838 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 63.208.196.90.53: 38784% [1au] AAAA? NS3.DYNDNS.ORG. (43)
    22:50:06.038799 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 63.208.196.90.53: 52160% [1au] AAAA? NS4.DYNDNS.ORG. (43)
    22:50:06.041773 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 63.208.196.90.53: 45704% [1au] AAAA? ns5.dyndns.org. (43)
    22:50:08.027217 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 67) 68.211.148.46.2048 > 204.13.249.81.53: 22852 A? myrouter.homedns.org. (39)
    22:50:08.031079 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.249.81.53: 5673% [1au] AAAA? ns1.dyndns.org. (43)
    22:50:08.034071 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.249.81.53: 35620% [1au] AAAA? ns2.dyndns.org. (43)
    22:50:08.037069 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.249.81.53: 57988% [1au] AAAA? NS3.DYNDNS.ORG. (43)
    22:50:08.040063 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.249.81.53: 28994% [1au] AAAA? NS4.DYNDNS.ORG. (43)
    22:50:08.043067 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.249.81.53: 56447% [1au] AAAA? ns5.dyndns.org. (43)
    22:50:08.090832 IP (tos 0x0, ttl 50, id 11337, offset 0, flags [none], proto: UDP (17), length: 122) 204.13.249.81.53 > 68.211.148.46.2048: 28994*- 0/1/1 (94)
    22:50:08.094677 IP (tos 0x0, ttl 50, id 11343, offset 0, flags [none], proto: UDP (17), length: 122) 204.13.249.81.53 > 68.211.148.46.2048: 56447*- 0/1/1 (94)
    22:50:09.155667 IP (tos 0x0, ttl 127, id 11437, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1026 > 205.152.37.23.53: 50617+ A? printer.myrouter.homedns.org. (50)
    22:50:09.210146 IP (tos 0x0, ttl 57, id 64732, offset 0, flags [DF], proto: UDP (17), length: 108) 205.152.37.23.53 > 68.211.148.46.1026: 50617 2/0/0 printer.myrouter.homedns.org.[|domain]
    22:50:12.028322 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 67) 68.211.148.46.2048 > 204.13.250.81.53: 55874 A? myrouter.homedns.org. (39)
    22:50:12.033103 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.250.81.53: 46783% [1au] AAAA? ns1.dyndns.org. (43)
    22:50:12.036097 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.250.81.53: 55034% [1au] AAAA? ns2.dyndns.org. (43)
    22:50:12.039098 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.250.81.53: 13732% [1au] AAAA? NS3.DYNDNS.ORG. (43)
    22:50:12.140431 IP (tos 0x0, ttl 48, id 51859, offset 0, flags [none], proto: UDP (17), length: 260) 204.13.250.81.53 > 68.211.148.46.2048: 55874*- 1/5/5 myrouter.homedns.org. A[|domain]
    22:50:12.144665 IP (tos 0x0, ttl 48, id 51860, offset 0, flags [none], proto: UDP (17), length: 118) 204.13.250.81.53 > 68.211.148.46.2048: 46783*- 0/1/1 (90)
    22:50:12.155065 IP (tos 0x0, ttl 48, id 51863, offset 0, flags [none], proto: UDP (17), length: 122) 204.13.250.81.53 > 68.211.148.46.2048: 55034*- 0/1/1 (94)
    22:50:12.155514 IP (tos 0x0, ttl 48, id 51866, offset 0, flags [none],
    proto: UDP (17), length: 122) 204.13.250.81.53 > 68.211.148.46.2048:
    13732*- 0/1/1 (94)

    --
    Get Big Brother out of my email to reply.

  6. Re: Why does pppd (pppoe) go to 95% to 100% of CPU?

    hazzmat wrote:
    > On Sun, 18 Mar 2007 17:25:46 -0500, Clifford Kite wrote:
    > What does "tcpdump -vn -i ppp0" show at 95% plus?


    > I was going to send this directly to you but then I saw you had outdone me
    > in the email address obfuscation department.


    It just seems better to have open discussions.

    At this point I need to admit that I don't read tcpdump messages with
    an expert eye, so prefix all my comments with "It appears to be" :-}.
    Note also that I've shortened the IP addresses in my comments to the
    last two octets.

    > 22:46:47.683683 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 63.208.196.90.53: 5812 [1au] A? myrouter.homedns.org. (50)
    > 22:46:47.768625 IP (tos 0x0, ttl 47, id 20391, offset 0, flags [none], proto: UDP (17), length: 271) 63.208.196.90.53 > 68.211.148.46.2048: 5812*- 1/5/6 myrouter.homedns.org. A[|domain]


    Nameserver request by 148.46 and reply by 196.90.

    > 22:47:03.167880 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 76) 68.211.148.46.123 > 216.27.185.42.123: NTPv4, length 48
    > Client, Leap indicator: (0), Stratum 11, poll 9s, precision -18
    > Root Delay: 0.000000, Root dispersion: 0.012802, Reference-ID: 127.127.1.0
    > Reference Timestamp: 3383261163.122205999 (2007/03/18 22:46:03)
    > Originator Timestamp: 3383260966.028969999 (2007/03/18 22:42:46)
    > Receive Timestamp: 3383260966.085657999 (2007/03/18 22:42:46)
    > Transmit Timestamp: 3383261223.167523999 (2007/03/18 22:47:03)
    > Originator - Receive Timestamp: +0.056687999
    > Originator - Transmit Timestamp: +257.138554000
    > 22:47:03.278711 IP (tos 0x0, ttl 45, id 53813, offset 0, flags [DF], proto: UDP (17), length: 76) 216.27.185.42.123 > 68.211.148.46.123: NTPv4, length 48
    > Server, Leap indicator: (0), Stratum 2, poll 9s, precision -20
    > Root Delay: 0.064544, Root dispersion: 0.075027, Reference-ID: 192.43.244.18
    > Reference Timestamp: 3383260953.416635999 (2007/03/18 22:42:33)
    > Originator Timestamp: 3383261223.167523999 (2007/03/18 22:47:03)
    > Receive Timestamp: 3383261223.223599999 (2007/03/18 22:47:03)
    > Transmit Timestamp: 3383261223.223620999 (2007/03/18 22:47:03)
    > Originator - Receive Timestamp: +0.056075999
    > Originator - Transmit Timestamp: +0.056096999


    Time update.

    > 22:47:47.794580 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 63.208.196.90.53: 17877 [1au] A? myrouter.homedns.org. (50)
    > 22:47:47.878019 IP (tos 0x0, ttl 47, id 63177, offset 0, flags [none], proto: UDP (17), length: 271) 63.208.196.90.53 > 68.211.148.46.2048: 17877*- 1/5/6 myrouter.homedns.org. A[|domain]


    Nameserver request by 148.46 and reply by 196.90.

    > 22:48:25.260800 IP (tos 0x0, ttl 127, id 10736, offset 0, flags [DF], proto: TCP (6), length: 48) 68.211.148.46.3033 > 68.215.208.239.80: S, cksum 0xb52c (correct), 2868897793:2868897793(0) win 16384
    > 22:48:28.263114 IP (tos 0x0, ttl 127, id 10737, offset 0, flags [DF], proto: TCP (6), length: 48) 68.211.148.46.3033 > 68.215.208.239.80: S, cksum 0xb52c (correct), 2868897793:2868897793(0) win 16384
    > 22:48:34.197737 IP (tos 0x0, ttl 127, id 10738, offset 0, flags [DF], proto: TCP (6), length: 48) 68.211.148.46.3033 > 68.215.208.239.80: S, cksum 0xb52c (correct), 2868897793:2868897793(0) win 16384


    148.46 looking for a web server on 208.239.

    > 22:48:47.903381 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 63.208.196.90.53: 53689 [1au] A? myrouter.homedns.org. (50)
    > 22:48:47.990133 IP (tos 0x0, ttl 47, id 44082, offset 0, flags [none], proto: UDP (17), length: 271) 63.208.196.90.53 > 68.211.148.46.2048: 53689*- 1/5/6 myrouter.homedns.org. A[|domain]


    Nameserver request by 148.46 and reply by 196.90.

    > 22:49:10.436550 IP (tos 0x0, ttl 46, id 0, offset 0, flags [DF], proto: UDP (17), length: 485) 202.97.238.202.57877 > 68.211.148.46.1026: UDP, length 457
    > 22:49:31.116522 IP (tos 0x0, ttl 45, id 0, offset 0, flags [DF], proto: UDP (17), length: 485) 221.209.110.48.45878 > 68.211.148.46.1026: UDP, length 457


    Probes to 148.46 port 1026.

    > 22:49:48.016167 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 63.208.196.90.53: 54286 [1au] A? myrouter.homedns.org. (50)


    Nameserver request by 148.46 to 196.90, unanswered. Note that the requests
    have come at one minute intervals until now.

    > 22:49:49.011043 IP (tos 0x0, ttl 127, id 11000, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1160 > 205.152.37.23.53: 162+ A? printer.myrouter.homedns.org. (50)
    > 22:49:50.016800 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 204.13.249.81.53: 13612 [1au] A? myrouter.homedns.org. (50)
    > 22:49:54.017927 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 78) 68.211.148.46.2048 > 204.13.250.81.53: 52486 [1au] A? myrouter.homedns.org. (50)
    > 22:49:54.023732 IP (tos 0x0, ttl 127, id 11032, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1160 > 205.152.37.23.53: 11938+ A? printer.myrouter.homedns.org. (50)
    > 22:49:58.018914 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 67) 68.211.148.46.2048 > 213.155.150.205.53: 59011 A? myrouter.homedns.org. (39)


    Two nameserver requests from 148.46 to 37.23, one nameserver request to
    each of 249.81, 250.81, and 150.205, all unanswered.

    > 22:49:59.024773 IP (tos 0x0, ttl 127, id 11089, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1160 > 205.152.37.23.53: 16805+ A? printer.myrouter.homedns.org. (50)
    > 22:49:59.154697 IP (tos 0x0, ttl 127, id 11094, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1027 > 205.152.37.23.53: 57252+ A? printer.myrouter.homedns.org. (50)
    > 22:50:02.020093 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 67) 68.211.148.46.2048 > 63.170.10.81.53: 19736 A? myrouter.homedns.org. (39)
    > 22:50:02.868708 IP (tos 0x0, ttl 127, id 11396, offset 0, flags [none], proto: UDP (17), length: 75) 68.211.148.46.1026 > 205.152.37.23.53: 5799+ A? vandals.myrouter.homedns.org. (47)
    > 22:50:04.024710 IP (tos 0x0, ttl 127, id 11419, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1160 > 205.152.37.23.53: 1703+ A? printer.myrouter.homedns.org. (50)
    > 22:50:04.154568 IP (tos 0x0, ttl 127, id 11422, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1027 > 205.152.37.23.53: 26022+ A? printer.myrouter.homedns.org. (50)


    Six nameserver requests by 148.46 to 37.23, all unanswered.

    > 22:50:06.026874 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 67) 68.211.148.46.2048 > 63.208.196.90.53: 42636 A? myrouter.homedns.org. (39)
    > 22:50:06.029922 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 63.208.196.90.53: 21318% [1au] AAAA? ns1.dyndns.org. (43)
    > 22:50:06.032884 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 63.208.196.90.53: 38091% [1au] AAAA? ns2.dyndns.org. (43)
    > 22:50:06.035838 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 63.208.196.90.53: 38784% [1au] AAAA? NS3.DYNDNS.ORG. (43)
    > 22:50:06.038799 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 63.208.196.90.53: 52160% [1au] AAAA? NS4.DYNDNS.ORG. (43)
    > 22:50:06.041773 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 63.208.196.90.53: 45704% [1au] AAAA? ns5.dyndns.org. (43)


    Six nameserver requests by 148.46 to 196.90, all unanswered.

    > 22:50:08.027217 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 67) 68.211.148.46.2048 > 204.13.249.81.53: 22852 A? myrouter.homedns.org. (39)
    > 22:50:08.031079 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.249.81.53: 5673% [1au] AAAA? ns1.dyndns.org. (43)
    > 22:50:08.034071 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.249.81.53: 35620% [1au] AAAA? ns2.dyndns.org. (43)
    > 22:50:08.037069 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.249.81.53: 57988% [1au] AAAA? NS3.DYNDNS.ORG. (43)
    > 22:50:08.040063 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.249.81.53: 28994% [1au] AAAA? NS4.DYNDNS.ORG. (43)
    > 22:50:08.043067 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.249.81.53: 56447% [1au] AAAA? ns5.dyndns.org. (43)


    Six nameserver requests from 148.46 to 249.81 the first four unanswered...

    > 22:50:08.090832 IP (tos 0x0, ttl 50, id 11337, offset 0, flags [none], proto: UDP (17), length: 122) 204.13.249.81.53 > 68.211.148.46.2048: 28994*- 0/1/1 (94)
    > 22:50:08.094677 IP (tos 0x0, ttl 50, id 11343, offset 0, flags [none], proto: UDP (17), length: 122) 204.13.249.81.53 > 68.211.148.46.2048: 56447*- 0/1/1 (94)


    but with replies to the last two.

    > 22:50:09.155667 IP (tos 0x0, ttl 127, id 11437, offset 0, flags [none], proto: UDP (17), length: 78) 68.211.148.46.1026 > 205.152.37.23.53: 50617+ A? printer.myrouter.homedns.org. (50)
    > 22:50:09.210146 IP (tos 0x0, ttl 57, id 64732, offset 0, flags [DF], proto: UDP (17), length: 108) 205.152.37.23.53 > 68.211.148.46.1026: 50617 2/0/0 printer.myrouter.homedns.org.[|domain]


    Nameserver request from 148.46 to 37.23, reply by 37.23.

    > 22:50:12.028322 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 67) 68.211.148.46.2048 > 204.13.250.81.53: 55874 A? myrouter.homedns.org. (39)
    > 22:50:12.033103 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.250.81.53: 46783% [1au] AAAA? ns1.dyndns.org. (43)
    > 22:50:12.036097 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.250.81.53: 55034% [1au] AAAA? ns2.dyndns.org. (43)
    > 22:50:12.039098 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 71) 68.211.148.46.2048 > 204.13.250.81.53: 13732% [1au] AAAA? NS3.DYNDNS.ORG. (43)


    Four nameserver requests from 148.46 to 250.81...

    > 22:50:12.140431 IP (tos 0x0, ttl 48, id 51859, offset 0, flags [none], proto: UDP (17), length: 260) 204.13.250.81.53 > 68.211.148.46.2048: 55874*- 1/5/5 myrouter.homedns.org. A[|domain]
    > 22:50:12.144665 IP (tos 0x0, ttl 48, id 51860, offset 0, flags [none], proto: UDP (17), length: 118) 204.13.250.81.53 > 68.211.148.46.2048: 46783*- 0/1/1 (90)
    > 22:50:12.155065 IP (tos 0x0, ttl 48, id 51863, offset 0, flags [none], proto: UDP (17), length: 122) 204.13.250.81.53 > 68.211.148.46.2048: 55034*- 0/1/1 (94)
    > 22:50:12.155514 IP (tos 0x0, ttl 48, id 51866, offset 0, flags [none],
    > proto: UDP (17), length: 122) 204.13.250.81.53 > 68.211.148.46.2048:
    > 13732*- 0/1/1 (94)


    with replies by 250.81 to those requests.

    There were many nameserver requests by 148.46 to different hosts with no
    answer, all within approximately 20 seconds. I'm not sure what is being
    requested, or why there are no replies, but suspect if replies were forth
    coming there would be no problem.

    --
    Clifford Kite


  7. Re: Why does pppd (pppoe) go to 95% to 100% of CPU?

    On Mon, 19 Mar 2007 15:45:03 -0500, Clifford Kite wrote:

    >
    > There were many nameserver requests by 148.46 to different hosts with no
    > answer, all within approximately 20 seconds. I'm not sure what is being
    > requested, or why there are no replies, but suspect if replies were forth
    > coming there would be no problem.


    What I can say about this is that the nameserver requests are to
    dyndns.org a dynamic address dns service. They were under DDOS attack
    starting on March 10. When that system gets a new ip it's supposed to
    update its record at dyndns.org. The DDOS attack has made that sometimes
    impossible, sometimes difficult.

    Another thing I know is involved is,
    when that system loses its ip address and reconnects, ntpd no longer is
    in sync. You get 'ntpd sendto i.pa.d.dr invalid argument messages' in the
    system log. So I made it happen that ntpd gets stopped when the link goes
    down and then is restarted again when the ppp0 link comes back up.
    Seemed like a workaround for ntpd's inability to maintain connection with
    a changing IP. This certainly adds to the CPU strain, particularly when
    the link is going up and down. The only captures I've been able to get
    off the system under high load from pppd show ntpd synchronization
    exchanges like the one you saw.

    One of the problems I have had with the
    dsl service is that the ISP is somewhat casual about LCP --evidently more
    so than the Linux box. Using the default values for LCP interval and
    failure, the Linux system will conclude the ppp link is not working
    anymore, take it down and try to reconnect. Sometimes however, the peer at
    the other end doesn't think the previous session is dead yet. So the link
    cannot be reestablished and there are "too many sessions for this host"
    messages back from the ISP in the log. pppoe tries and retries for a
    while. It sorts itself out eventually--most of the time. What I really
    want is a way to make the pppoe system WAIT longer before trying to
    reconnect. That way the peer should have caught on to the fact that the
    link is down, and clear the way for a new ppp session.

    I initially thought that pppoe-timeout was related to how quickly
    pppoe tries to reconnect, but I see that it is something else
    altogether. Do you think a holdoff statement in /etc/ppp/options
    might work?

    thanks.

    --
    Get Big Brother out of my email to reply.

  8. Re: Why does pppd (pppoe) go to 95% to 100% of CPU?

    hazzmat wrote:
    > On Mon, 19 Mar 2007 15:45:03 -0500, Clifford Kite wrote:
    >>
    >> There were many nameserver requests by 148.46 to different hosts with no
    >> answer, all within approximately 20 seconds. I'm not sure what is being
    >> requested, or why there are no replies, but suspect if replies were forth
    >> coming there would be no problem.


    > What I can say about this is that the nameserver requests are to
    > dyndns.org a dynamic address dns service. They were under DDOS attack
    > starting on March 10. When that system gets a new ip it's supposed to
    > update its record at dyndns.org. The DDOS attack has made that sometimes
    > impossible, sometimes difficult.


    Does the start of the attack coincide with the start of your problem?
    Alternately, is there anything else that does coincide with it?

    > Another thing I know is involved is,
    > when that system loses its ip address and reconnects, ntpd no longer is
    > in sync. You get 'ntpd sendto i.pa.d.dr invalid argument messages' in the
    > system log. So I made it happen that ntpd gets stopped when the link goes
    > down and then is restarted again when the ppp0 link comes back up.
    > Seemed like a workaround for ntpd's inability to maintain connection with
    > a changing IP. This certainly adds to the CPU strain, particularly when
    > the link is going up and down. The only captures I've been able to get
    > off the system under high load from pppd show ntpd synchronization
    > exchanges like the one you saw.


    The one I saw was just that, one. In order for a CPU to be loaded to
    95%+ by traffic through pppd there would have be many at a high rate.
    Even the rate of DNS requests did not seem high enough to me, but the
    requests were both numerous and odd compared to the other traffic.

    > One of the problems I have had with the
    > dsl service is that the ISP is somewhat casual about LCP --evidently more
    > so than the Linux box. Using the default values for LCP interval and
    > failure, the Linux system will conclude the ppp link is not working


    Response to LCP echo-requests are an RFC requirement, but echo-requests
    or echo-replies can be lost.

    > anymore, take it down and try to reconnect. Sometimes however, the peer at
    > the other end doesn't think the previous session is dead yet. So the link
    > cannot be reestablished and there are "too many sessions for this host"
    > messages back from the ISP in the log. pppoe tries and retries for a
    > while. It sorts itself out eventually--most of the time. What I really
    > want is a way to make the pppoe system WAIT longer before trying to
    > reconnect. That way the peer should have caught on to the fact that the
    > link is down, and clear the way for a new ppp session.


    > I initially thought that pppoe-timeout was related to how quickly
    > pppoe tries to reconnect, but I see that it is something else
    > altogether. Do you think a holdoff statement in /etc/ppp/options
    > might work?


    You see something I don't, namely pppoe-timeout. A grep of rp-pppoe's
    source directory for pppoe-timeout turned up empty. Ah, I see now from
    man pppoe you probably mean the pppoe -T option which is akin to the
    pppd idle option.

    Using holdoff should introduce a delay before pppd tries to restart
    the PPP link but how will rp-pppoe know to delay the PADI requests?
    Instead you could try increasing lcp-echo-interval or lcp-echo-failure to
    delay termination of the link (and thus the beginning of PADI requests).
    Or increasing the sleep time near the end of the pppoe-connect script
    might work.

    Just to be sure (even though you said it's pppd hogging the CPU): The
    Ethernet interfaces for PPPoE should not be used for anything else.

    --
    Clifford Kite

+ Reply to Thread