ppp link starts emiting bogus ip packets - PPP

This is a discussion on ppp link starts emiting bogus ip packets - PPP ; Hello , I peform a ppp connection over isdn between 2 linux systems . The connection works fine in general. However , under unclear conditions, it exhibits strange behaviour. The most usual symptom is that the packets reaching my ppp ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: ppp link starts emiting bogus ip packets

  1. ppp link starts emiting bogus ip packets



    Hello ,

    I peform a ppp connection over isdn between 2 linux systems . The
    connection works fine in general. However , under unclear conditions, it
    exhibits strange behaviour. The most usual symptom is that the packets
    reaching my ppp interface have their source ip address distorted . For
    example , I ping 1.2.3.4 and with tcpdump I capture an echo reply towards
    me (the "client") with an erroneous random source address (like
    23.65.13.64 etc,tottaly random).
    The same occurs to any other sessions I might be running at that
    time , like ssh www etc. The source addresses for the packets reaching me
    is totally different to what the ppp "server" thinks he send to me .
    The moment that occurs pppd produces quiet a few ConfRej messages
    with some huge sequences of hex numbers for around 30 seconds . The
    link continues to stay up , sends and recievs lcp echoes ok , however it
    is unusable so I have to terminate it and reconnect.
    I cannot reproduce it in any certain way. Usually it occurs while
    I am using ssh . I have been doing downloads at full speed for more than
    24 continues hours , and the problem never occurs during this time.
    The "server" is slackware 8 and the client is slackware 9 . Both
    running 2.4.22 kernel and pppd 2.4.1 . The server is using Zyxel omninet
    plus ISDN TA and the client Intracom Netmod .
    I suspect faulty hardware , but I welcome any thoughts you may
    have.

    Best regards ,

    --
    ================================================== ===========================

    Dimitris Zilaskos

    Department of Physics @ Aristotle Univercity of Thessaloniki , Greece
    PGP key : http://tassadar.physics.auth.gr/~dzi...public_key.asc
    http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc
    MD5sum : 4f84f3f53cb046008b4abcb2a092d28d pgp_public_key.asc
    ================================================== ===========================


  2. Re: ppp link starts emiting bogus ip packets

    Dimitris Zilaskos writes:
    > example , I ping 1.2.3.4 and with tcpdump I capture an echo reply towards
    > me (the "client") with an erroneous random source address (like
    > 23.65.13.64 etc,tottaly random).

    [...]
    > The moment that occurs pppd produces quiet a few ConfRej messages
    > with some huge sequences of hex numbers for around 30 seconds . The


    That sounds symptomatic of failing (and perhaps bug-ridden) CCP data
    compression. I would start by adding "noccp" to the configuration.

    However, that's just a guess. You've not provided sufficient
    information for anyone here to diagnose the problem accurately. You
    need to provide:

    - The exact log messages produced, not verbal descriptions of
    them.

    - Your configuration files and information about the equipment
    used.

    - Any traces or results of other tests you've made.

    --
    James Carlson, Solaris Networking
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  3. Re: ppp link starts emiting bogus ip packets

    On Fri, 19 Sep 2003, James Carlson wrote:
    >
    > - The exact log messages produced, not verbal descriptions of
    > them.
    >
    > - Your configuration files and information about the equipment
    > used.
    >
    > - Any traces or results of other tests you've made.


    Thank your for replying

    This is the pppd command

    /usr/sbin/pppd -detach /dev/ttyS0 115200 connect /usr/sbin/chat -v -f
    /etc/ppp/isdn

    the /etc/ppp/isdn file contains the following:

    TIMEOUT 255 ABORT ERROR
    ABORT BUSY
    "" AT&F OK ATS95=46 OK ATS2=255 OK AT&c0 OK ATS7=255 OK
    "atdixxxxxxxx"
    CONNECT ''

    this is /etc/ppp/options

    proxyarp
    lcp-echo-interval 30
    lcp-echo-failure 4

    and this is /etc/ppp/options.ttyS0

    192.168.1.1:192.168.1.2
    asyncmap 0
    lock
    crtscts
    modem


    Here is what pppd on the "server" produces when the problem occurs

    Sep 18 01:02:25 box pppd[339]: rcvd [LCP EchoRep id=0xb6 magic=0x772c4d5f]
    Sep 18 01:02:43 box pppd[339]: rcvd [LCP ProtRej id=0x3 00 ff 0e 00 2a fd
    74 e0 ...
    Sep 18 01:02:44 box pppd[339]: rcvd [LCP ProtRej id=0x4 42 7d dd dd de d0
    8b 63 ...

    The log is too big , I have upped it at
    http://tassadar.physics.auth.gr/~dzila/ppp.txt .As you can seen in the end
    I manually terminate the connection since it is unusable .


    Unfortunately I will be in another town for the next couple of
    days and I cant provide a tcpdump capture of the bogus packets.

    Greping CCP revealed the following occuring once

    Sep 17 02:10:50 box pppd[7676]: rcvd [CCP ResetReq id=0x2]
    Sep 17 02:10:50 box pppd[7676]: sent [CCP ResetAck id=0x2]

    About the equipment : The client is using intracom netmod
    (http://netmod.intracom.gr) which is the device used by the telco here to
    terminate the isdn line and it includes an isdn modem (connects to the
    computer via usb). I have tested it extensively and does have the same
    problem elsewhere.The server is using a Zyxel Omninet Plus isdn terminal
    adaptor.I have not tested it extensively yet (aka staying online with it
    to various isps and stress testing it). It was purchased as a bargain ,
    and it lacks its original power supply , so it uses a custom made one.
    Adding to that , I have strong reasons to believe that its price was so
    low because it was stored in a basement that was flooded with water
    (thus the lack of its power supply and box). Thats why I to conclude
    to faulty hardware , but i dont have a spare isdn modem right now to test
    for sure.

    What puzzles me though is that the current setup can sustain days
    of continuous downloading at its max speed , yet it exhibits this strange
    behaviour while the only traffic present is an ssh session.

    Again thank you for your reply and apologises for the length of my
    post.

    Best regards ,
    --
    ================================================== ===========================

    Dimitris Zilaskos

    Department of Physics @ Aristotle Univercity of Thessaloniki , Greece
    PGP key : http://tassadar.physics.auth.gr/~dzi...public_key.asc
    http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc
    MD5sum : 4f84f3f53cb046008b4abcb2a092d28d pgp_public_key.asc
    ================================================== ===========================


  4. Re: ppp link starts emiting bogus ip packets

    Dimitris Zilaskos writes:
    > this is /etc/ppp/options
    >
    > proxyarp


    Are you the server? If not, then you might not want to have proxyarp
    enabled.

    > The log is too big , I have upped it at
    > http://tassadar.physics.auth.gr/~dzila/ppp.txt .As you can seen in the end
    > I manually terminate the connection since it is unusable .


    Even in the "too big" log file, you don't show the negotiation
    occurring. I don't know what to tell you.

    > Unfortunately I will be in another town for the next couple of
    > days and I cant provide a tcpdump capture of the bogus packets.


    Don't bother; they appear to be highly corrupt, and there's nothing
    that would show that the log file doesn't.

    > Greping CCP revealed the following occuring once
    >
    > Sep 17 02:10:50 box pppd[7676]: rcvd [CCP ResetReq id=0x2]
    > Sep 17 02:10:50 box pppd[7676]: sent [CCP ResetAck id=0x2]


    Yes. I think that's related. As I said in the last posting, I think
    either your system or the peer's system has a broken implementation of
    CCP, and that's what's causing this data corruption. The symptoms
    you're reporting are classic signs of failing CCP.

    Adding "noccp" to the configuration should fix it.

    > (thus the lack of its power supply and box). Thats why I to conclude
    > to faulty hardware , but i dont have a spare isdn modem right now to test
    > for sure.


    Although I can't rule that out, it does seem remotely possible.

    Another possibility would be misconfiguration. Does this system have
    a working serial cable (with full modem controls) and are both ends
    set up for hardware flow control?

    > What puzzles me though is that the current setup can sustain days
    > of continuous downloading at its max speed , yet it exhibits this strange
    > behaviour while the only traffic present is an ssh session.


    That's a key insight: ssh produces incompressible data. Data
    compression algorithms tend to fail in two cases: either with highly
    compressible data, or with incompressible data. These are the most
    important tests done on compression implementations, such as CCP.

    The fact that incompressible data is causing the link to fail almost
    guarantees that the problem is a broken implementation of CCP, as I
    said before.

    > Again thank you for your reply and apologises for the length of my
    > post.


    It's still short ...

    --
    James Carlson, Solaris Networking
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  5. Re: ppp link starts emiting bogus ip packets


    > > proxyarp

    >
    > Are you the server? If not, then you might not want to have proxyarp
    > enabled.


    yes this is on the server .

    > > The log is too big , I have upped it at

    > Even in the "too big" log file, you don't show the negotiation
    > occurring. I don't know what to tell you.


    I have upped the full log of that day with numeroous negotiations at
    http://tassadar.physics.auth.gr/~dzila/ppp2.txt . The first negotiation is
    the one that had to be terminated later due to the bogus packets (lines
    1-212).
    >
    > either your system or the peer's system has a broken implementation of
    > CCP, and that's what's causing this data corruption. The symptoms
    > you're reporting are classic signs of failing CCP.
    >
    > Adding "noccp" to the configuration should fix it.


    I will try it at first chance I get

    >
    > Another possibility would be misconfiguration. Does this system have
    > a working serial cable (with full modem controls) and are both ends
    > set up for hardware flow control?


    both ends are setup for hardware control , about the cable though , well I
    can replace it with a new one and see what happens.

    Thank you very much for your help .

    Best regards ,


    --
    ================================================== ===========================

    Dimitris Zilaskos

    Department of Physics @ Aristotle Univercity of Thessaloniki , Greece
    PGP key : http://tassadar.physics.auth.gr/~dzi...public_key.asc
    http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc
    MD5sum : 4f84f3f53cb046008b4abcb2a092d28d pgp_public_key.asc
    ================================================== ===========================


  6. Re: ppp link starts emiting bogus ip packets

    Dimitris Zilaskos writes:
    > I have upped the full log of that day with numeroous negotiations at
    > http://tassadar.physics.auth.gr/~dzila/ppp2.txt . The first negotiation is
    > the one that had to be terminated later due to the bogus packets (lines
    > 1-212).


    There's the smoking gun:

    Sep 17 02:10:30 box pppd[7676]: rcvd [LCP ProtRej id=0x3 00 51 ff 03 c0 21 09 56 00 08 1b 2c 92 51]
    Sep 17 02:10:50 box pppd[7676]: rcvd [CCP ResetReq id=0x2]
    Sep 17 02:10:50 box pppd[7676]: sent [CCP ResetAck id=0x2]

    Those are classic symptoms. Either this system or its peer has a
    broken implementation of CCP, and the resulting data corruption makes
    the link unusable. Disable CCP ("noccp" in the options) and the
    problem should go away.

    --
    James Carlson, Solaris Networking
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  7. Re: ppp link starts emiting bogus ip packets



    Ok I Have some new findings about my problem.

    Adding noccp did not make the problem go. However, I found an
    easy way to reproduce it. While I am connected over the isdn link , I open an
    ssh session to a system in the lan of the server ane initiate an ftp
    transaction between this system and another in the lan, using the default
    ftp client (ftp command in slackware ) and turning tick on. The bytes
    counter starts increasing very fast an within a minute the ppp link
    freezes , and after a while it gets terminated because no ppp echo replies
    are recieved.No errors of whatsoever in the log. The replies just stop
    coming and after 4 failures the link is terminated.
    I did the same experiment but connected to my isp this time , and
    that behaviour did not appear. So it seems that my server is broken
    somehow.

    Thank you for your help

    Best regards ,


    --
    ================================================== ===========================

    Dimitris Zilaskos

    Department of Physics @ Aristotle Univercity of Thessaloniki , Greece
    PGP key : http://tassadar.physics.auth.gr/~dzi...public_key.asc
    http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc
    MD5sum : 4f84f3f53cb046008b4abcb2a092d28d pgp_public_key.asc
    ================================================== ===========================


+ Reply to Thread