NAK'ing a CHAP request. - PPP

This is a discussion on NAK'ing a CHAP request. - PPP ; Good day. What is the proper format of a NAK to a MD5 CHAP request of the format: 03 05 C0 23 05? Sending back a configure NAK with 03 05 C0 23 05 seems to be failing on some ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: NAK'ing a CHAP request.

  1. NAK'ing a CHAP request.

    Good day.

    What is the proper format of a NAK to a MD5 CHAP request of the format: 03
    05 C0 23 05?
    Sending back a configure NAK with 03 05 C0 23 05 seems to be failing on some
    service providers, but sending back just 03 05 C0 23 seems to succeed. I
    have torn through the rfc's (1334, 1661 in particular) and if I have
    interpreted it correctly, it appears as thought the NAK should contain the
    same command received (including the data packets)? Is this not the case
    and if not, could someone point me to where I can read up on the details of
    proper NAK packet formats.

    Thanks in advance.



  2. Re: NAK'ing a CHAP request.

    "John Doehead" writes:
    > What is the proper format of a NAK to a MD5 CHAP request of the format: 03
    > 05 C0 23 05?


    It should contain the desired protocol.

    > Sending back a configure NAK with 03 05 C0 23 05 seems to be failing on some
    > service providers, but sending back just 03 05 C0 23 seems to succeed. I


    Neither of those make any sense as a Configure-Nak. If you don't have
    some other preferred authentication protocol, then you shouldn't be
    sending Configure-Nak -- you should send Configure-Reject instead.

    If you're trying to say "use PAP instead," then that should be 03 04
    C0 23 -- see RFC 1334 section 2.1. PAP doesn't have any option data.

    03 05 C0 23 05 doesn't make sense as PAP, since PAP doesn't take any
    option data. Better-written implementations should accept it, but
    some may not.

    03 05 C0 23 is just impossible. That's a malformed option; the option
    length doesn't match the Length value.

    > have torn through the rfc's (1334, 1661 in particular) and if I have
    > interpreted it correctly, it appears as thought the NAK should contain the
    > same command received (including the data packets)? Is this not the case
    > and if not, could someone point me to where I can read up on the details of
    > proper NAK packet formats.


    RFC 1661, section 5.3:

    Each Configuration Option which is allowed only a single instance
    MUST be modified to a value acceptable to the Configure-Nak
    sender. The default value MAY be used, when this differs from the
    requested value.
    [...]
    Reception of a valid Configure-Nak indicates that when a new
    Configure-Request is sent, the Configuration Options MAY be
    modified as specified in the Configure-Nak. When multiple

    The options data for Configure-Nak should have what you want the peer
    to send you in its next Configure-Request.

    (I can recommend a book if you're interested ...)

    --
    James Carlson, IP Systems Group
    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: NAK'ing a CHAP request.

    Thanks very much! That helps... a couple more comments:

    Sorry about the typo...03 05 C0 23 was supposed to read 03 04 C0 23 (my
    question was due to my confusion thinking that the NAK'd request might have
    to be an echo of the initial request and so I was wondering why 03 04 C0 23
    was working as a NAK response).

    This all makes sense now as you have clarified it perfectly - NAK with the
    parameters that are acceptable.

    ....and yes, I would be very much interested in any book recommendations you
    could make.

    Once again, thank you.

    "James Carlson" wrote in message
    news:xoavoeoly66j.fsf@sun.com...
    > "John Doehead" writes:
    > > What is the proper format of a NAK to a MD5 CHAP request of the format:

    03
    > > 05 C0 23 05?

    >
    > It should contain the desired protocol.
    >
    > > Sending back a configure NAK with 03 05 C0 23 05 seems to be failing on

    some
    > > service providers, but sending back just 03 05 C0 23 seems to succeed.

    I
    >
    > Neither of those make any sense as a Configure-Nak. If you don't have
    > some other preferred authentication protocol, then you shouldn't be
    > sending Configure-Nak -- you should send Configure-Reject instead.
    >
    > If you're trying to say "use PAP instead," then that should be 03 04
    > C0 23 -- see RFC 1334 section 2.1. PAP doesn't have any option data.
    >
    > 03 05 C0 23 05 doesn't make sense as PAP, since PAP doesn't take any
    > option data. Better-written implementations should accept it, but
    > some may not.
    >
    > 03 05 C0 23 is just impossible. That's a malformed option; the option
    > length doesn't match the Length value.
    >
    > > have torn through the rfc's (1334, 1661 in particular) and if I have
    > > interpreted it correctly, it appears as thought the NAK should contain

    the
    > > same command received (including the data packets)? Is this not the

    case
    > > and if not, could someone point me to where I can read up on the details

    of
    > > proper NAK packet formats.

    >
    > RFC 1661, section 5.3:
    >
    > Each Configuration Option which is allowed only a single instance
    > MUST be modified to a value acceptable to the Configure-Nak
    > sender. The default value MAY be used, when this differs from the
    > requested value.
    > [...]
    > Reception of a valid Configure-Nak indicates that when a new
    > Configure-Request is sent, the Configuration Options MAY be
    > modified as specified in the Configure-Nak. When multiple
    >
    > The options data for Configure-Nak should have what you want the peer
    > to send you in its next Configure-Request.
    >
    > (I can recommend a book if you're interested ...)
    >
    > --
    > James Carlson, IP Systems Group
    > 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




  4. Re: NAK'ing a CHAP request.

    "John Doehead" writes:
    > Thanks very much! That helps... a couple more comments:
    >
    > Sorry about the typo...03 05 C0 23 was supposed to read 03 04 C0 23 (my
    > question was due to my confusion thinking that the NAK'd request might have
    > to be an echo of the initial request and so I was wondering why 03 04 C0 23
    > was working as a NAK response).


    No -- Configure-Ack and Configure-Reject must be echoed exactly as-is,
    but Configure-Nak is different.

    Well, almost. At least that was the original design intent. There
    are some broken NCPs defined that require the Configure-Ack to differ
    in some small ways, so it's not completely true.

    > This all makes sense now as you have clarified it perfectly - NAK with the
    > parameters that are acceptable.
    >
    > ...and yes, I would be very much interested in any book recommendations you
    > could make.



    http://www.amazon.com/exec/obidos/tg...books&n=507846


    Although, honestly, I'd council anyone away from reinventing the
    wheel. There's perfectly good source code available on the net for
    PPP, it's under a fairly flexible BSD license, and it's quite mature.

    --
    James Carlson, IP Systems Group
    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: NAK'ing a CHAP request.

    You just had to offer up some more tantalizing information, didn't you?

    > Although, honestly, I'd council anyone away from reinventing the
    > wheel. There's perfectly good source code available on the net for
    > PPP, it's under a fairly flexible BSD license, and it's quite mature.

    How would I go about finding the above source? A quick scan on google turns
    up references to the BSD compress utility but I have not yet found mention
    of the source.

    I too would rather work from a *mature* source base...in an effort to do so,
    my PPP implementation was derived from a technote from my chipset
    manufacturer...the problem is that it is only a very basic implementation
    which does not scale well over various providers (i.e. I have had to code
    magic-number support which wasn't there in the first place).

    Cheers.

    "James Carlson" wrote in message
    news:xoavfz9xxyhs.fsf@sun.com...
    > "John Doehead" writes:
    > > Thanks very much! That helps... a couple more comments:
    > >
    > > Sorry about the typo...03 05 C0 23 was supposed to read 03 04 C0 23 (my
    > > question was due to my confusion thinking that the NAK'd request might

    have
    > > to be an echo of the initial request and so I was wondering why 03 04 C0

    23
    > > was working as a NAK response).

    >
    > No -- Configure-Ack and Configure-Reject must be echoed exactly as-is,
    > but Configure-Nak is different.
    >
    > Well, almost. At least that was the original design intent. There
    > are some broken NCPs defined that require the Configure-Ack to differ
    > in some small ways, so it's not completely true.
    >
    > > This all makes sense now as you have clarified it perfectly - NAK with

    the
    > > parameters that are acceptable.
    > >
    > > ...and yes, I would be very much interested in any book recommendations

    you
    > > could make.

    >
    >
    >

    http://www.amazon.com/exec/obidos/tg...084912502/sr=8
    -2/ref=sr_8_xs_ap_i2_xgl14/103-0342719-0021420?v=glance&s=books&n=507846
    >
    >
    > Although, honestly, I'd council anyone away from reinventing the
    > wheel. There's perfectly good source code available on the net for
    > PPP, it's under a fairly flexible BSD license, and it's quite mature.
    >
    > --
    > James Carlson, IP Systems Group
    > 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




  6. Re: NAK'ing a CHAP request.

    "John Doehead" writes:


    ]...and yes, I would be very much interested in any book recommendations you
    ]could make.

    He means the book written by James D Carlson .
    PPP Design Implimentation and Debugging.
    It is supposed to be very good.


    ]"James Carlson" wrote in message
    ]>
    ]> (I can recommend a book if you're interested ...)
    ]>
    ]> --
    ]> James Carlson, IP Systems Group
    ]> 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: NAK'ing a CHAP request.

    "John Doehead" writes:

    ]You just had to offer up some more tantalizing information, didn't you?

    ]> Although, honestly, I'd council anyone away from reinventing the
    ]> wheel. There's perfectly good source code available on the net for
    ]> PPP, it's under a fairly flexible BSD license, and it's quite mature.
    ]How would I go about finding the above source? A quick scan on google turns
    ]up references to the BSD compress utility but I have not yet found mention
    ]of the source.

    ]I too would rather work from a *mature* source base...in an effort to do so,
    ]my PPP implementation was derived from a technote from my chipset
    ]manufacturer...the problem is that it is only a very basic implementation
    ]which does not scale well over various providers (i.e. I have had to code
    ]magic-number support which wasn't there in the first place).


    pppd
    ftp.samba.org/pub/ppp

  8. Re: NAK'ing a CHAP request.

    "John Doehead" writes:
    > You just had to offer up some more tantalizing information, didn't you?


    Couldn't help it, I suppose.

    > > Although, honestly, I'd council anyone away from reinventing the
    > > wheel. There's perfectly good source code available on the net for
    > > PPP, it's under a fairly flexible BSD license, and it's quite mature.

    > How would I go about finding the above source? A quick scan on google turns
    > up references to the BSD compress utility but I have not yet found mention
    > of the source.


    Among the links here (which, yes, I have to update someday):

    http://carlson-ne.home.comcast.net/ppp/reference.html

    Are several links for PPP sources, including:

    ftp://ftp.samba.org/pub/ppp/

    (Home page for that is http://samba.org/ppp/)

    > I too would rather work from a *mature* source base...in an effort to do so,
    > my PPP implementation was derived from a technote from my chipset
    > manufacturer...the problem is that it is only a very basic implementation
    > which does not scale well over various providers (i.e. I have had to code
    > magic-number support which wasn't there in the first place).


    At least look over the open sources. You might find that tailoring it
    down to fit your application may be easier than scaling up a toy
    implementation.

    --
    James Carlson, IP Systems Group
    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

  9. Re: NAK'ing a CHAP request.

    Thanks very much...I will definitely give this a look.

    Unfortunately, due to time constraints and the fact that I am close to
    having this working now, I am hoping it will take less time for me to
    resolve the current issue, than to tailor down the code sample.

    As I mentioned, I have a PPP implementation which negotiates the connection
    fine on 2 of 3 wireless carriers. The 3rd carrier is causing me some grief.
    I have a serial port analyzer capture of a DUN session through Windows that
    is successful in establishing a PPP session.
    I also have a capture of my code (in an embedded unit) that is not
    successful. (Both traces could be provided in an Excel format to show the
    communications).

    I will summarize the difference below:

    DUN Connection:
    Carrier: LCP config req
    DUN client: ACKs req in 19 ms
    DUN client: PAP config req 6 ms later
    Carrier: ACKs PAP req 327 ms later
    IP address resolution continues successfully

    Embedded connection (my code):
    1) Carrier: LCP config req
    2) Embedded client: ACKs req in 32 ms
    3) Embedded client: PAP config req 1330 ms later
    Carrier: Repeats initial LCP config req above ACKs PAP req 327 ms later
    Steps 1, 2, and 3 are continually repeated, with the carrier never ACK'ing
    my PAP request.

    I have tried reducing the delay in 3) to be approximately 350 ms to no avail
    but don't really understand why the difference in behaviour.

    One thing of note however is that the initial config request in the Embedded
    connection in 1) has ID 255 and this ID stays the same through the repeated
    1, 2, 3 sequence.

    Any help would GREATLY be appreciated.
    Cheers.




    "James Carlson" wrote in message
    news:xoavwu38vgn4.fsf@sun.com...
    > "John Doehead" writes:
    > > You just had to offer up some more tantalizing information, didn't you?

    >
    > Couldn't help it, I suppose.
    >
    > > > Although, honestly, I'd council anyone away from reinventing the
    > > > wheel. There's perfectly good source code available on the net for
    > > > PPP, it's under a fairly flexible BSD license, and it's quite mature.

    > > How would I go about finding the above source? A quick scan on google

    turns
    > > up references to the BSD compress utility but I have not yet found

    mention
    > > of the source.

    >
    > Among the links here (which, yes, I have to update someday):
    >
    > http://carlson-ne.home.comcast.net/ppp/reference.html
    >
    > Are several links for PPP sources, including:
    >
    > ftp://ftp.samba.org/pub/ppp/
    >
    > (Home page for that is http://samba.org/ppp/)
    >
    > > I too would rather work from a *mature* source base...in an effort to do

    so,
    > > my PPP implementation was derived from a technote from my chipset
    > > manufacturer...the problem is that it is only a very basic

    implementation
    > > which does not scale well over various providers (i.e. I have had to

    code
    > > magic-number support which wasn't there in the first place).

    >
    > At least look over the open sources. You might find that tailoring it
    > down to fit your application may be easier than scaling up a toy
    > implementation.
    >
    > --
    > James Carlson, IP Systems Group
    > 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




  10. Re: NAK'ing a CHAP request.

    Sorry, typo in previous post
    The line that reads:
    Carrier: Repeats initial LCP comfit req above ACKs PAP req 327 ms later
    Should read:
    Carrier: Repeats initial LCP comfit req above

    Damn cut & paste .

    "John Doehead" wrote in message
    news:F2Mqc.15$SQ2.3@edtnps89...
    > Thanks very much...I will definitely give this a look.
    >
    > Unfortunately, due to time constraints and the fact that I am close to
    > having this working now, I am hoping it will take less time for me to
    > resolve the current issue, than to tailor down the code sample.
    >
    > As I mentioned, I have a PPP implementation which negotiates the

    connection
    > fine on 2 of 3 wireless carriers. The 3rd carrier is causing me some

    grief.
    > I have a serial port analyzer capture of a DUN session through Windows

    that
    > is successful in establishing a PPP session.
    > I also have a capture of my code (in an embedded unit) that is not
    > successful. (Both traces could be provided in an Excel format to show the
    > communications).
    >
    > I will summarize the difference below:
    >
    > DUN Connection:
    > Carrier: LCP config req
    > DUN client: ACKs req in 19 ms
    > DUN client: PAP config req 6 ms later
    > Carrier: ACKs PAP req 327 ms later
    > IP address resolution continues successfully
    >
    > Embedded connection (my code):
    > 1) Carrier: LCP config req
    > 2) Embedded client: ACKs req in 32 ms
    > 3) Embedded client: PAP config req 1330 ms later
    > Carrier: Repeats initial LCP config req above ACKs PAP req 327 ms later
    > Steps 1, 2, and 3 are continually repeated, with the carrier never ACK'ing
    > my PAP request.
    >
    > I have tried reducing the delay in 3) to be approximately 350 ms to no

    avail
    > but don't really understand why the difference in behaviour.
    >
    > One thing of note however is that the initial config request in the

    Embedded
    > connection in 1) has ID 255 and this ID stays the same through the

    repeated
    > 1, 2, 3 sequence.
    >
    > Any help would GREATLY be appreciated.
    > Cheers.
    >
    >
    >
    >
    > "James Carlson" wrote in message
    > news:xoavwu38vgn4.fsf@sun.com...
    > > "John Doehead" writes:
    > > > You just had to offer up some more tantalizing information, didn't

    you?
    > >
    > > Couldn't help it, I suppose.
    > >
    > > > > Although, honestly, I'd council anyone away from reinventing the
    > > > > wheel. There's perfectly good source code available on the net for
    > > > > PPP, it's under a fairly flexible BSD license, and it's quite

    mature.
    > > > How would I go about finding the above source? A quick scan on google

    > turns
    > > > up references to the BSD compress utility but I have not yet found

    > mention
    > > > of the source.

    > >
    > > Among the links here (which, yes, I have to update someday):
    > >
    > > http://carlson-ne.home.comcast.net/ppp/reference.html
    > >
    > > Are several links for PPP sources, including:
    > >
    > > ftp://ftp.samba.org/pub/ppp/
    > >
    > > (Home page for that is http://samba.org/ppp/)
    > >
    > > > I too would rather work from a *mature* source base...in an effort to

    do
    > so,
    > > > my PPP implementation was derived from a technote from my chipset
    > > > manufacturer...the problem is that it is only a very basic

    > implementation
    > > > which does not scale well over various providers (i.e. I have had to

    > code
    > > > magic-number support which wasn't there in the first place).

    > >
    > > At least look over the open sources. You might find that tailoring it
    > > down to fit your application may be easier than scaling up a toy
    > > implementation.
    > >
    > > --
    > > James Carlson, IP Systems Group
    > > 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

    >
    >




  11. Re: NAK'ing a CHAP request.

    "John Doehead" writes:
    > Unfortunately, due to time constraints and the fact that I am close to
    > having this working now, I am hoping it will take less time for me to
    > resolve the current issue, than to tailor down the code sample.


    Don't forget that you (or someone who knows where you live) may have
    to maintain the results. ;-}

    > DUN Connection:
    > Carrier: LCP config req
    > DUN client: ACKs req in 19 ms
    > DUN client: PAP config req 6 ms later
    > Carrier: ACKs PAP req 327 ms later
    > IP address resolution continues successfully
    >
    > Embedded connection (my code):
    > 1) Carrier: LCP config req
    > 2) Embedded client: ACKs req in 32 ms
    > 3) Embedded client: PAP config req 1330 ms later
    > Carrier: Repeats initial LCP config req above ACKs PAP req 327 ms later
    > Steps 1, 2, and 3 are continually repeated, with the carrier never ACK'ing
    > my PAP request.


    Please provide a regular debug log. It's hard to tell exactly what
    you mean there. (I suppose I could decode 'excel' but text would be
    much preferred.)

    On what you've posted:

    - I don't see LCP completing. You need to have LCP
    Configure-Request and LCP Configure-Ack sent by both sides.
    Does that happen?

    - PAP doesn't have a Configure-Request message. Did you mean
    Authenticate-Request?

    Repeating often means that the peer is unable to hear you, and that's
    often due to ACCM errors.

    Other than that, without a debug log, it's hard to tell.

    > I have tried reducing the delay in 3) to be approximately 350 ms to no avail
    > but don't really understand why the difference in behaviour.


    Timing should _not_ matter, unless the peer is bug-ridden.

    > One thing of note however is that the initial config request in the Embedded
    > connection in 1) has ID 255 and this ID stays the same through the repeated
    > 1, 2, 3 sequence.


    Eeek!

    Don't do that. At least try using different ID numbers for different
    (not-retransmitted) packets.

    --
    James Carlson, IP Systems Group
    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

  12. Re: NAK'ing a CHAP request.

    Comments embedded:

    "James Carlson" wrote in message
    news:xoavk6z8uzby.fsf@sun.com...
    > "John Doehead" writes:
    > > Unfortunately, due to time constraints and the fact that I am close to
    > > having this working now, I am hoping it will take less time for me to
    > > resolve the current issue, than to tailor down the code sample.

    >
    > Don't forget that you (or someone who knows where you live) may have
    > to maintain the results. ;-}

    Definitely...it is exactly that that has got me into this mess - starting
    off from another's code base
    >
    > > DUN Connection:
    > > Carrier: LCP config req
    > > DUN client: ACKs req in 19 ms
    > > DUN client: PAP config req 6 ms later
    > > Carrier: ACKs PAP req 327 ms later
    > > IP address resolution continues successfully
    > >
    > > Embedded connection (my code):
    > > 1) Carrier: LCP config req
    > > 2) Embedded client: ACKs req in 32 ms
    > > 3) Embedded client: PAP config req 1330 ms later
    > > Carrier: Repeats initial LCP config req above ACKs PAP req 327 ms later
    > > Steps 1, 2, and 3 are continually repeated, with the carrier never

    ACK'ing
    > > my PAP request.

    >
    > Please provide a regular debug log. It's hard to tell exactly what
    > you mean there. (I suppose I could decode 'excel' but text would be
    > much preferred.)

    Would you like one sent via email?
    >
    > On what you've posted:
    >
    > - I don't see LCP completing. You need to have LCP
    > Configure-Request and LCP Configure-Ack sent by both sides.
    > Does that happen?

    Yes. Sorry, wasn't clear...2) was doing the LCP Configure-Ack
    >
    > - PAP doesn't have a Configure-Request message. Did you mean
    > Authenticate-Request?

    Yes. Code C023...Auth Request, but never get the Auth Req Ack, instead the
    initial LCP config req is just repeated.
    >
    > Repeating often means that the peer is unable to hear you, and that's
    > often due to ACCM errors.

    Don't think this is the case since all other requests seem to get responses,
    and it is always the auth-req that never seems to get the response.
    >
    > Other than that, without a debug log, it's hard to tell.
    >
    > > I have tried reducing the delay in 3) to be approximately 350 ms to no

    avail
    > > but don't really understand why the difference in behaviour.

    >
    > Timing should _not_ matter, unless the peer is bug-ridden.
    >
    > > One thing of note however is that the initial config request in the

    Embedded
    > > connection in 1) has ID 255 and this ID stays the same through the

    repeated
    > > 1, 2, 3 sequence.

    >
    > Eeek!
    >
    > Don't do that. At least try using different ID numbers for different
    > (not-retransmitted) packets.

    Oops yet again...that repeated ID is actually in the carriers request, not
    our code. Although it may be bad *practice*, is this a sign of a potential
    issue? Strangely, it doesn't hapeen when the carrier is talking to a DUN
    connection.
    >
    > --
    > James Carlson, IP Systems Group
    > 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




  13. Re: NAK'ing a CHAP request.

    "John Doehead" writes:
    > > Please provide a regular debug log. It's hard to tell exactly what
    > > you mean there. (I suppose I could decode 'excel' but text would be
    > > much preferred.)

    > Would you like one sent via email?


    OK.

    > > - PAP doesn't have a Configure-Request message. Did you mean
    > > Authenticate-Request?

    > Yes. Code C023...Auth Request, but never get the Auth Req Ack, instead the
    > initial LCP config req is just repeated.


    It sounds like the peer can't hear you -- and possibly didn't hear
    your LCP Configure-Ack either.

    > > Repeating often means that the peer is unable to hear you, and that's
    > > often due to ACCM errors.

    > Don't think this is the case since all other requests seem to get responses,
    > and it is always the auth-req that never seems to get the response.


    PAP is the first thing that runs right after LCP negotiates. Before
    LCP negotiates, the ACCM is set to the default (FFFFFFFF). Once LCP
    goes to Opened (after you send or receive that last Configure-Ack) it
    switches to the negotiated value.

    This means that if the next protocol right after LCP fails, you should
    suspect ACCM first, and perhaps ACFC or PFC.

    > > Don't do that. At least try using different ID numbers for different
    > > (not-retransmitted) packets.

    > Oops yet again...that repeated ID is actually in the carriers request, not
    > our code. Although it may be bad *practice*, is this a sign of a potential
    > issue? Strangely, it doesn't hapeen when the carrier is talking to a DUN
    > connection.


    If you're seeing a repeated ID from the peer, that usually means that
    the peer is retransmitting. And he'll do that if he can't hear you.

    (It could just be a bug on his part, though.)

    --
    James Carlson, IP Systems Group
    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

  14. Re: NAK'ing a CHAP request.

    What sort of errors would be occurring in ACCM and how can I verify this?

    I will fire the debug log to this email.

    Thanks for taking the time with this.


    "James Carlson" wrote in message
    news:xoavbrkkuxr1.fsf@sun.com...
    > "John Doehead" writes:
    > > > Please provide a regular debug log. It's hard to tell exactly what
    > > > you mean there. (I suppose I could decode 'excel' but text would be
    > > > much preferred.)

    > > Would you like one sent via email?

    >
    > OK.
    >
    > > > - PAP doesn't have a Configure-Request message. Did you mean
    > > > Authenticate-Request?

    > > Yes. Code C023...Auth Request, but never get the Auth Req Ack, instead

    the
    > > initial LCP config req is just repeated.

    >
    > It sounds like the peer can't hear you -- and possibly didn't hear
    > your LCP Configure-Ack either.
    >
    > > > Repeating often means that the peer is unable to hear you, and that's
    > > > often due to ACCM errors.

    > > Don't think this is the case since all other requests seem to get

    responses,
    > > and it is always the auth-req that never seems to get the response.

    >
    > PAP is the first thing that runs right after LCP negotiates. Before
    > LCP negotiates, the ACCM is set to the default (FFFFFFFF). Once LCP
    > goes to Opened (after you send or receive that last Configure-Ack) it
    > switches to the negotiated value.
    >
    > This means that if the next protocol right after LCP fails, you should
    > suspect ACCM first, and perhaps ACFC or PFC.
    >
    > > > Don't do that. At least try using different ID numbers for different
    > > > (not-retransmitted) packets.

    > > Oops yet again...that repeated ID is actually in the carriers request,

    not
    > > our code. Although it may be bad *practice*, is this a sign of a

    potential
    > > issue? Strangely, it doesn't hapeen when the carrier is talking to a

    DUN
    > > connection.

    >
    > If you're seeing a repeated ID from the peer, that usually means that
    > the peer is retransmitting. And he'll do that if he can't hear you.
    >
    > (It could just be a bug on his part, though.)
    >
    > --
    > James Carlson, IP Systems Group
    > 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




  15. Re: NAK'ing a CHAP request.

    "John Doehead" writes:
    > What sort of errors would be occurring in ACCM and how can I verify this?


    Any of the following:

    - If the ACCM requested by the peer is 0x000a0000, then it's
    fairly likely that the peer has one of the well-known
    implementation bugs. Adapting from your side to also
    request 0x000a0000 is the only good solution to the
    problem, even though it's not required by the standards.

    - If the data path between you and the peer is unable to
    handle one or more characters in the range 00 through 1F
    hex, and the corresponding bit is set to zero in the ACCM
    (disabling escaping), then the link is misconfigured.

    - If your implementation or the peer has misinterpreted how
    the ACCM option works, then that'd lead to trouble. Sending
    ACCM in LCP Configure-Request with some bits set to zero
    means "you don't have to escape these particular characters
    when you send them to me, but you still can if you want."
    Sending LCP Configure-Ack with some bits set to zero means
    "I might not escape some of these characters when I send
    them to you, though I still may if I choose." And the
    actual ACCM on the link must be kept at the default of
    FFFFFFFF until LCP goes all the way to Opened state, though
    you *may* have to deal with bug-ridden peers that fail to
    manage the transition correctly.

    > I will fire the debug log to this email.


    OK.

    --
    James Carlson, IP Systems Group
    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

  16. Re: NAK'ing a CHAP request.

    Aight, that was a mouthful...I will verify that ACCM is being handled
    correctly - still a bit of a PPP noob - before hassling you any more.

    The debug file will have to wait as my analyzer does not export it to a
    *friendly* format with timestamps so I will try to work some magic on this.

    Thanks again.

    "James Carlson" wrote in message
    news:xoav3c5wurof.fsf@sun.com...
    > "John Doehead" writes:
    > > What sort of errors would be occurring in ACCM and how can I verify

    this?
    >
    > Any of the following:
    >
    > - If the ACCM requested by the peer is 0x000a0000, then it's
    > fairly likely that the peer has one of the well-known
    > implementation bugs. Adapting from your side to also
    > request 0x000a0000 is the only good solution to the
    > problem, even though it's not required by the standards.
    >
    > - If the data path between you and the peer is unable to
    > handle one or more characters in the range 00 through 1F
    > hex, and the corresponding bit is set to zero in the ACCM
    > (disabling escaping), then the link is misconfigured.
    >
    > - If your implementation or the peer has misinterpreted how
    > the ACCM option works, then that'd lead to trouble. Sending
    > ACCM in LCP Configure-Request with some bits set to zero
    > means "you don't have to escape these particular characters
    > when you send them to me, but you still can if you want."
    > Sending LCP Configure-Ack with some bits set to zero means
    > "I might not escape some of these characters when I send
    > them to you, though I still may if I choose." And the
    > actual ACCM on the link must be kept at the default of
    > FFFFFFFF until LCP goes all the way to Opened state, though
    > you *may* have to deal with bug-ridden peers that fail to
    > manage the transition correctly.
    >
    > > I will fire the debug log to this email.

    >
    > OK.
    >
    > --
    > James Carlson, IP Systems Group
    > 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




  17. Re: NAK'ing a CHAP request.

    Comments inline.
    "James Carlson" wrote in message
    news:xoav3c5wurof.fsf@sun.com...
    > "John Doehead" writes:
    > > What sort of errors would be occurring in ACCM and how can I verify

    this?
    >
    > Any of the following:
    >
    > - If the ACCM requested by the peer is 0x000a0000, then it's
    > fairly likely that the peer has one of the well-known
    > implementation bugs. Adapting from your side to also
    > request 0x000a0000 is the only good solution to the
    > problem, even though it's not required by the standards.

    Funny you should say that...the code base I worked from used that very
    ACCM...it worked on the other two carriers, but not on this...this must
    imply that the other two did not escape any characters? What should I look
    for to determine if the code base we used had this 'implementation bug'?
    >
    > - If the data path between you and the peer is unable to
    > handle one or more characters in the range 00 through 1F
    > hex, and the corresponding bit is set to zero in the ACCM
    > (disabling escaping), then the link is misconfigured.

    We remap/escape any characters < 0x20, but the async map was set to
    0x000A0000. I am a little confused since this seems to be the wrong map for
    those characters. Also, this sequence concerns me due to your point above -
    what exactly is the implementation bug result in? Does this not then imply
    that the 2 previous carriers we had success with are not encoding any
    characters?

    >
    > - If your implementation or the peer has misinterpreted how
    > the ACCM option works, then that'd lead to trouble. Sending
    > ACCM in LCP Configure-Request with some bits set to zero
    > means "you don't have to escape these particular characters
    > when you send them to me, but you still can if you want."
    > Sending LCP Configure-Ack with some bits set to zero means
    > "I might not escape some of these characters when I send
    > them to you, though I still may if I choose." And the
    > actual ACCM on the link must be kept at the default of
    > FFFFFFFF until LCP goes all the way to Opened state, though
    > you *may* have to deal with bug-ridden peers that fail to
    > manage the transition correctly.

    I have tried setting the ACCM to both 0xFFFFFFFF and 0x00000000 to no avail.

    Cheers.
    > --
    > James Carlson, IP Systems Group
    > 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




  18. Re: NAK'ing a CHAP request.

    And somewhere around the time of 05/18/2004 15:06, the world stopped and
    listened as John Doehead contributed the following to humanity:

    > You just had to offer up some more tantalizing information, didn't you?
    >
    >
    >>Although, honestly, I'd council anyone away from reinventing the
    >>wheel. There's perfectly good source code available on the net for
    >>PPP, it's under a fairly flexible BSD license, and it's quite mature.

    >
    > How would I go about finding the above source? A quick scan on google turns
    > up references to the BSD compress utility but I have not yet found mention
    > of the source.
    >
    > I too would rather work from a *mature* source base...in an effort to do so,
    > my PPP implementation was derived from a technote from my chipset
    > manufacturer...the problem is that it is only a very basic implementation
    > which does not scale well over various providers (i.e. I have had to code
    > magic-number support which wasn't there in the first place).
    >
    > Cheers.
    >


    http://www.freebsd.org/cgi/cvsweb.cg...=RELENG_4_9_BP

    That's the base source code used in FreeBSD.
    --
    Daniel Rudy

    Remove nospam, invalid, and 0123456789 to reply.

  19. Re: NAK'ing a CHAP request.

    "John Doehead" writes:
    > > - If the ACCM requested by the peer is 0x000a0000, then it's
    > > fairly likely that the peer has one of the well-known
    > > implementation bugs. Adapting from your side to also
    > > request 0x000a0000 is the only good solution to the
    > > problem, even though it's not required by the standards.

    > Funny you should say that...the code base I worked from used that very
    > ACCM...it worked on the other two carriers, but not on this...this must
    > imply that the other two did not escape any characters? What should I look
    > for to determine if the code base we used had this 'implementation bug'?


    The bug (as best it's known) is that some implementations seem not to
    understand that ACCM (like nearly all PPP options) is negotiated
    independently in each direction.

    For example, let's suppose we have this sequence:

    Peer A Peer B
    LCP Configure-Request ->
    ACCM = 00011000
    <- LCP Configure-Request
    ACCM = 00000002
    LCP Configure-Ack ->
    ACCM = 00000002
    <- LCP Configure-Ack
    ACCM = 00011000

    In this case, in accepting 00000002 from the other side, Peer A has
    agreed to escape at least the value '01' hex (as 7D 21) when it sends
    data to Peer B. It may -- at its option, and without notifying Peer B
    -- decide to escape other characters.

    Similarly, Peer B has agreed to escape '0C' and '10' hex when it
    transmits data.

    > > - If the data path between you and the peer is unable to
    > > handle one or more characters in the range 00 through 1F
    > > hex, and the corresponding bit is set to zero in the ACCM
    > > (disabling escaping), then the link is misconfigured.

    > We remap/escape any characters < 0x20, but the async map was set to
    > 0x000A0000. I am a little confused since this seems to be the wrong map for
    > those characters. Also, this sequence concerns me due to your point above -
    > what exactly is the implementation bug result in? Does this not then imply
    > that the 2 previous carriers we had success with are not encoding any
    > characters?


    That ACCM means that the peer wants you to escape at least 11 and 13
    hex -- also known as ^Q and ^S, ASCII DC1 and DC3, or XON and XOFF.

    The result is _sometimes_ fairly easy to see with a line analyzer --
    one side starts sending values that the other side specifically said
    need to be escaped. At other times, it can be difficult because the
    problem is deeper in an implementation (one peer said it would accept
    a particular value without escaping, and yet it actually doesn't).
    Those cases need good debug tools.

    If you are writing your own PPP and you don't have a line analyzer,
    you're living on the hairy edge. I recommend looking into getting
    one, such as SerialView from Klos. It'll save you a lot of time
    looking at the wrong things.

    > > them to you, though I still may if I choose." And the
    > > actual ACCM on the link must be kept at the default of
    > > FFFFFFFF until LCP goes all the way to Opened state, though
    > > you *may* have to deal with bug-ridden peers that fail to
    > > manage the transition correctly.

    > I have tried setting the ACCM to both 0xFFFFFFFF and 0x00000000 to no avail.


    Without seeing the data on the wire, it's tough to make a guess about
    what might be going on.

    --
    James Carlson, IP Systems Group
    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

  20. Re: NAK'ing a CHAP request.

    Cool...thanks.

    We are using the FTS analyzer and it has been a great help.

    Re the ACCM, the ported code has the following logic:
    Sending (pbyData is input array):
    if (pbyData[uiCount] < 0x20 ||
    pbyData[uiCount] == 0x7D ||
    pbyData[uiCount] == 0x7E)
    {
    chTmp = 0x7D;
    USART_Transmit(USART0, &chTmp, 1);//send out byte
    chTmp = pbyData[uiCount] ^ 0x20;
    USART_Transmit(USART0, &chTmp, 1);//send out byte
    }
    else
    {
    USART_Transmit(USART0, &pbyData[uiCount], 1);
    }
    Receiving:
    if (ucByte == 0x7E)
    { // start or end of a packet
    if (guiRxFramePtr && (uiRxChkSum==0xF0B8))
    {
    gpucFrame[guiRxFramePtr++] = ucByte; // insert character
    in buffer
    //uiPacket = gpucFrame[2]*256 + gpucFrame[3]; // if CRC
    passes accept packet
    pbyData = gpucFrame;
    pbyData += PPPProtocolType;
    *puiDataLen = (unsigned int)(gpucFrame[IPLengthOffset]) *
    0x100 + (gpucFrame[IPLengthOffset+1]);
    }
    ucEscapedFlag &= 0x7E; // clear escape character flag
    guiRxFramePtr = 0; // get ready for next packet
    gpucFrame[guiRxFramePtr++] = ucByte; // insert character in
    buffer
    uiRxChkSum = 0xFFFF; // start new checksum
    }
    else if (ucByte == 0x7D)
    { // if tilde character set escape flag
    ucEscapedFlag |= 1;
    }
    else
    {
    if ( ucEscapedFlag & 1 )
    { // if escape flag
    ucByte ^= 0x20; // recover next character
    ucEscapedFlag &= 0xFE; // clear Rx escape flag
    }
    if ( guiRxFramePtr == 1 && ucByte != 0xff )
    {
    gpucFrame[guiRxFramePtr++] = 0xff; // uncompress PPP header
    }
    if ( guiRxFramePtr == 2 && ucByte != 3)
    {
    gpucFrame[guiRxFramePtr++] = 3;
    }
    if ( guiRxFramePtr == 3 && ( ucByte & 1) )
    {
    gpucFrame[guiRxFramePtr++] = 0;
    }
    gpucFrame[guiRxFramePtr++] = ucByte; // insert character in
    buffer
    if (guiRxFramePtr > PPP_RX_FRAME_MAX)
    {
    guiRxFramePtr = PPP_RX_FRAME_MAX; // Inc pointer up to end
    of buffer
    }
    uiRxChkSum = CalcChkSum(ucByte^uiRxChkSum) ^ (uiRxChkSum/256);
    // calculate CRC checksum
    }

    Would this not be a safe implementation regardless of the negotiated ACCM?
    We are escaping all characters on send/receive.
    Further, the carrier is negotiating an ACCM of 0x00000000 all the way
    through session negotiation which seems to violate using the default
    0xFFFFFFFF that you mentioned, even though that seems to work through DUN
    but not our code.

    As mentioned before, I have tried both 0x00000000 and 0xFFFFFFFF ACCM
    negotiations without success, but I did not change the processing logic
    above thinking that the ACCM wouldn't really matter given the *safe?*
    escaping we are doing.

    I finally rendered a good debug dump to pdf...one for the DUN Success and
    the other for the Micro Failure...I will fire them off to your @sun.com
    email.

    I really appreciate you taking the time to look over this.
    Cheers.

    "James Carlson" wrote in message
    news:xoavlljn74mi.fsf@sun.com...
    > "John Doehead" writes:
    > > > - If the ACCM requested by the peer is 0x000a0000, then it's
    > > > fairly likely that the peer has one of the well-known
    > > > implementation bugs. Adapting from your side to also
    > > > request 0x000a0000 is the only good solution to the
    > > > problem, even though it's not required by the standards.

    > > Funny you should say that...the code base I worked from used that very
    > > ACCM...it worked on the other two carriers, but not on this...this must
    > > imply that the other two did not escape any characters? What should I

    look
    > > for to determine if the code base we used had this 'implementation bug'?

    >
    > The bug (as best it's known) is that some implementations seem not to
    > understand that ACCM (like nearly all PPP options) is negotiated
    > independently in each direction.
    >
    > For example, let's suppose we have this sequence:
    >
    > Peer A Peer B
    > LCP Configure-Request ->
    > ACCM = 00011000
    > <- LCP Configure-Request
    > ACCM = 00000002
    > LCP Configure-Ack ->
    > ACCM = 00000002
    > <- LCP Configure-Ack
    > ACCM = 00011000
    >
    > In this case, in accepting 00000002 from the other side, Peer A has
    > agreed to escape at least the value '01' hex (as 7D 21) when it sends
    > data to Peer B. It may -- at its option, and without notifying Peer B
    > -- decide to escape other characters.
    >
    > Similarly, Peer B has agreed to escape '0C' and '10' hex when it
    > transmits data.
    >
    > > > - If the data path between you and the peer is unable to
    > > > handle one or more characters in the range 00 through 1F
    > > > hex, and the corresponding bit is set to zero in the ACCM
    > > > (disabling escaping), then the link is misconfigured.

    > > We remap/escape any characters < 0x20, but the async map was set to
    > > 0x000A0000. I am a little confused since this seems to be the wrong map

    for
    > > those characters. Also, this sequence concerns me due to your point

    above -
    > > what exactly is the implementation bug result in? Does this not then

    imply
    > > that the 2 previous carriers we had success with are not encoding any
    > > characters?

    >
    > That ACCM means that the peer wants you to escape at least 11 and 13
    > hex -- also known as ^Q and ^S, ASCII DC1 and DC3, or XON and XOFF.
    >
    > The result is _sometimes_ fairly easy to see with a line analyzer --
    > one side starts sending values that the other side specifically said
    > need to be escaped. At other times, it can be difficult because the
    > problem is deeper in an implementation (one peer said it would accept
    > a particular value without escaping, and yet it actually doesn't).
    > Those cases need good debug tools.
    >
    > If you are writing your own PPP and you don't have a line analyzer,
    > you're living on the hairy edge. I recommend looking into getting
    > one, such as SerialView from Klos. It'll save you a lot of time
    > looking at the wrong things.
    >
    > > > them to you, though I still may if I choose." And the
    > > > actual ACCM on the link must be kept at the default of
    > > > FFFFFFFF until LCP goes all the way to Opened state, though
    > > > you *may* have to deal with bug-ridden peers that fail to
    > > > manage the transition correctly.

    > > I have tried setting the ACCM to both 0xFFFFFFFF and 0x00000000 to no

    avail.
    >
    > Without seeing the data on the wire, it's tough to make a guess about
    > what might be going on.
    >
    > --
    > James Carlson, IP Systems Group
    > 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




+ Reply to Thread
Page 1 of 2 1 2 LastLast