Protocol Rejection - PPP

This is a discussion on Protocol Rejection - PPP ; Hey, I'm trying to setup a linux box to terminate VPDN connections for our dialup customers using L2TPD and PPPd 2.4.1. I'm using pppd-tacacs+radius plugin for authentication, and have modified parts of ipcp.c and sys-linux.c to add support for creating ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Protocol Rejection

  1. Protocol Rejection

    Hey,

    I'm trying to setup a linux box to terminate VPDN connections for our dialup
    customers using L2TPD and PPPd 2.4.1. I'm using pppd-tacacs+radius plugin
    for authentication, and have modified parts of ipcp.c and sys-linux.c to
    add support for creating the routes returned via radius attributes on
    authentication. Now when I dial in I can connect fine, IPs are brought up
    on both ends of the connection, all appropriate routes are established etc.
    However I can't get any data through the connection, an attempt to ping the
    server from the client dialled in results in error messages like this:

    rcvd [proto=0x3] 00 21 45 00 00 54 00 02 40 00 40 01 76 45 c0 a8 07 80 ca 09
    32 30 08 00 cd 5e 76 13 02 00 41 ea ...
    Unsupported protocol 0x3 received
    sent [LCP ProtRej id=0x4 00 03 00 21 45 00 00 54 00 02 40 00 40 01 76 45 c0
    a8 07 80 ca 09 32 30 08 00 cd 5e 76 13 02 00 ...]

    From what I can tell protocol 0x3 is some kind of header compressions, so in
    an attempt to work around this I have added the noccp and novj options to
    my ppp config, but this doesn't appear to have helped.

    If anyone has any idea what could be causing this problem I would greatly
    appreciate it. I've spent the last two days scouring google for information
    to no avail, so I'm really at a loss here

    Daniel

  2. Re: Protocol Rejection

    In article <41eafe72$0$724$61c65585@uq-127creek-reader-02.brisbane.pipenetworks.com.au>,
    Daniel Andersen wrote:
    >Hey,
    >
    >I'm trying to setup a linux box to terminate VPDN connections for our dialup
    >customers using L2TPD and PPPd 2.4.1. I'm using pppd-tacacs+radius plugin
    >for authentication, and have modified parts of ipcp.c and sys-linux.c to
    >add support for creating the routes returned via radius attributes on
    >authentication. Now when I dial in I can connect fine, IPs are brought up
    >on both ends of the connection, all appropriate routes are established etc.
    >However I can't get any data through the connection, an attempt to ping the
    >server from the client dialled in results in error messages like this:
    >
    >rcvd [proto=0x3] 00 21 45 00 00 54 00 02 40 00 40 01 76 45 c0 a8 07 80 ca 09
    >32 30 08 00 cd 5e 76 13 02 00 41 ea ...
    >Unsupported protocol 0x3 received
    >sent [LCP ProtRej id=0x4 00 03 00 21 45 00 00 54 00 02 40 00 40 01 76 45 c0
    >a8 07 80 ca 09 32 30 08 00 cd 5e 76 13 02 00 ...]
    >
    >From what I can tell protocol 0x3 is some kind of header compressions, so in
    >an attempt to work around this I have added the noccp and novj options to
    >my ppp config, but this doesn't appear to have helped.
    >
    >If anyone has any idea what could be causing this problem I would greatly
    >appreciate it. I've spent the last two days scouring google for information
    >to no avail, so I'm really at a loss here


    Based on the information you've provided, I have to GUESS that the machine
    receiving this message is broken and misinterpreting the beginning of the
    PPP frame from its peer. Without seeing the actual LCP negotiations, it's
    just a guess, but I wonder if your machine is seeing the 0x3 from the
    "Address and Control Field" as the protocol ID and assigning your incoming
    packets the protocol ID of 0x0003?? Is the LCP option ACFC being negotiated
    in your machine or its peer's LCP options? Can you provide a trace that
    includes the LCP negotiations? What are you using as a peer that is trying
    to connect to this machine?

    Patrick
    =========== For PPP Protocol Analysis, check out PacketView Pro! ===========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==== Read up on Usenet etiquette: http://www.faqs.org/usenet/index.html ====

  3. Re: Protocol Rejection

    patrick@klos.com wrote:

    > Based on the information you've provided, I have to GUESS that the machine
    > receiving this message is broken and misinterpreting the beginning of the
    > PPP frame from its peer. Without seeing the actual LCP negotiations, it's
    > just a guess, but I wonder if your machine is seeing the 0x3 from the
    > "Address and Control Field" as the protocol ID and assigning your incoming
    > packets the protocol ID of 0x0003?? Is the LCP option ACFC being
    > negotiated
    > in your machine or its peer's LCP options? Can you provide a trace that
    > includes the LCP negotiations? What are you using as a peer that is
    > trying to connect to this machine?
    >
    > Patrick


    Hey,

    Negotiation logs are as follows (apologies for any line wrapping):

    sent [LCP ConfReq id=0x1
    ]
    rcvd [LCP ConfReq id=0x4
    ]
    sent [LCP ConfAck id=0x4
    ]
    rcvd [LCP ConfAck id=0x1
    ]
    rcvd [LCP EchoReq id=0x0 magic=0x81ce58de]
    sent [LCP EchoRep id=0x0 magic=0xe7ed96c7]
    rcvd [PAP AuthReq id=0x3 user="dea_test" password=]
    sent [PAP AuthAck id=0x3 ""]
    sent [IPCP ConfReq id=0x1 ]
    rcvd [IPCP ConfReq id=0x1 0.0.0.0>]
    sent [IPCP ConfRej id=0x1 ]
    rcvd [IPCP ConfAck id=0x1 ]
    rcvd [IPCP ConfReq id=0x2 ]
    sent [IPCP ConfNak id=0x2 ]
    rcvd [IPCP ConfReq id=0x3 ]
    sent [IPCP ConfAck id=0x3 ]

    Nothing looks out of the ordinary there as far as I can tell (though I'm not
    really that much of an expert on LCP negotiation so i could be missing
    something really obvious here).
    The way the connection works is I dial up and get forwarded to a Cisco,
    which then does basic PAP to check the realm, then based on that
    establishes an L2TP tunnel to the Linux server and the PPP connection is
    established over that and negotations etc are then conducted between the
    server and the client dialled in. This means of course that there are a
    number of points along the chain at which these problems could actually be
    occurring, further complicating matters.

    Daniel

  4. Re: Protocol Rejection

    Daniel Andersen wrote:

    > patrick@klos.com wrote:
    >
    >> Based on the information you've provided, I have to GUESS that the
    >> machine receiving this message is broken and misinterpreting the
    >> beginning of the
    >> PPP frame from its peer. Without seeing the actual LCP negotiations,
    >> it's just a guess, but I wonder if your machine is seeing the 0x3 from
    >> the "Address and Control Field" as the protocol ID and assigning your
    >> incoming
    >> packets the protocol ID of 0x0003?? Is the LCP option ACFC being
    >> negotiated
    >> in your machine or its peer's LCP options? Can you provide a trace that
    >> includes the LCP negotiations? What are you using as a peer that is
    >> trying to connect to this machine?
    >>
    >> Patrick

    >


    Incidentally, the same error message is being reported on both the client
    *and* the server, which seems a bit odd from what I can tell.

  5. Re: Protocol Rejection

    In article <41ec5040$0$249$61c65585@uq-127creek-reader-03.brisbane.pipenetworks.com.au>,
    Daniel Andersen wrote:
    >patrick@klos.com wrote:
    >
    >> Based on the information you've provided, I have to GUESS that the machine
    >> receiving this message is broken and misinterpreting the beginning of the
    >> PPP frame from its peer. Without seeing the actual LCP negotiations, it's
    >> just a guess, but I wonder if your machine is seeing the 0x3 from the
    >> "Address and Control Field" as the protocol ID and assigning your incoming
    >> packets the protocol ID of 0x0003?? Is the LCP option ACFC being
    >> negotiated
    >> in your machine or its peer's LCP options? Can you provide a trace that
    >> includes the LCP negotiations? What are you using as a peer that is
    >> trying to connect to this machine?
    >>
    >> Patrick

    >
    >Hey,
    >
    >Negotiation logs are as follows (apologies for any line wrapping):
    >
    >sent [LCP ConfReq id=0x1
    > ]
    >rcvd [LCP ConfReq id=0x4
    > ]
    >sent [LCP ConfAck id=0x4
    > ]
    >rcvd [LCP ConfAck id=0x1
    > ]


    At this point, both sides have negotiated LCP with both "Address and
    Control Field Compression" and "Protocol Compression" (among other
    things). So far, so good.

    >rcvd [LCP EchoReq id=0x0 magic=0x81ce58de]
    >sent [LCP EchoRep id=0x0 magic=0xe7ed96c7]


    Basic link test - looks good.

    >rcvd [PAP AuthReq id=0x3 user="dea_test" password=]
    >sent [PAP AuthAck id=0x3 ""]


    Authentication - good.

    >sent [IPCP ConfReq id=0x1 ]
    >rcvd [IPCP ConfReq id=0x1 >0.0.0.0>]
    >sent [IPCP ConfRej id=0x1 ]
    >rcvd [IPCP ConfAck id=0x1 ]
    >rcvd [IPCP ConfReq id=0x2 ]
    >sent [IPCP ConfNak id=0x2 ]
    >rcvd [IPCP ConfReq id=0x3 ]
    >sent [IPCP ConfAck id=0x3 ]


    Looks like a reasonable IPCP negotiation (although slightly atypical).

    >Nothing looks out of the ordinary there as far as I can tell (though I'm not
    >really that much of an expert on LCP negotiation so i could be missing
    >something really obvious here).


    No, everything looks legit and fairly normal.

    >The way the connection works is I dial up and get forwarded to a Cisco,
    >which then does basic PAP to check the realm, then based on that
    >establishes an L2TP tunnel to the Linux server and the PPP connection is
    >established over that and negotations etc are then conducted between the
    >server and the client dialled in. This means of course that there are a
    >number of points along the chain at which these problems could actually be
    >occurring, further complicating matters.


    Do you have a trace file of the L2TP packets? That might be useful. Or
    at least continue tracing all the packets you can up to the IP packets
    that go bad.

    Based on this new info and your previous description, I'm wondering what is
    creating a bad frame such that your final machine thinks the protocol for
    the IP packet is 0x0003??

    Patrick
    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==== Read up on Usenet etiquette: http://www.faqs.org/usenet/index.html ====

  6. Re: Protocol Rejection

    patrick@klos.com wrote:

    >>Negotiation logs are as follows (apologies for any line wrapping):
    >>
    >>sent [LCP ConfReq id=0x1
    >> ]
    >>rcvd [LCP ConfReq id=0x4
    >> ]
    >>sent [LCP ConfAck id=0x4
    >> ]
    >>rcvd [LCP ConfAck id=0x1
    >> ]

    >
    > At this point, both sides have negotiated LCP with both "Address and
    > Control Field Compression" and "Protocol Compression" (among other
    > things). So far, so good.
    >


    Or maybe not. I just tried turning off pcomp specifically in the options
    file and it all works. Not sure whats going on there, I don't think any of
    the changes i made should have affected compression.. might look into it in
    a bit more detail if i find time. Thanks for your assistance.

    Daniel

  7. Re: Protocol Rejection

    In article <41ec8efb$0$680$61c65585@uq-127creek-reader-01.brisbane.pipenetworks.com.au>,
    Daniel Andersen wrote:
    >patrick@klos.com wrote:
    >
    >>>Negotiation logs are as follows (apologies for any line wrapping):
    >>>
    >>>sent [LCP ConfReq id=0x1
    >>> ]
    >>>rcvd [LCP ConfReq id=0x4
    >>> ]
    >>>sent [LCP ConfAck id=0x4
    >>> ]
    >>>rcvd [LCP ConfAck id=0x1
    >>> ]

    >>
    >> At this point, both sides have negotiated LCP with both "Address and
    >> Control Field Compression" and "Protocol Compression" (among other
    >> things). So far, so good.
    >>

    >
    >Or maybe not. I just tried turning off pcomp specifically in the options
    >file and it all works.


    Then something is clearly broken in either PPP or L2TP, but it's good you
    can get past it for now.

    >Not sure whats going on there, I don't think any of
    >the changes i made should have affected compression..


    What kind of changes did you make? And to which components. (not critical -
    just curious)

    >might look into it in
    >a bit more detail if i find time. Thanks for your assistance.


    You're welcome. Good luck!

    Patrick

  8. Re: Protocol Rejection

    patrick@klos.com wrote:
    > What kind of changes did you make? And to which components. (not
    > critical - just curious)
    >


    Just made a few changes to ipcp.c and sys-linux.c to support bringing up the
    routes specified in radius attributes after authentication, nothing that
    should have affected the function of LCP or compression. The changes
    basically just amounted to adding a couple of functions and then a loop to
    call them at the end of an existing function.

    Daniel


+ Reply to Thread