NAK'ing a CHAP request. - PPP

This is a discussion on NAK'ing a CHAP request. - PPP ; "John Doehead" writes: > Re the ACCM, the ported code has the following logic: > Sending (pbyData is input array): > if (pbyData[uiCount] > pbyData[uiCount] == 0x7D || > pbyData[uiCount] == 0x7E) > { > chTmp = 0x7D; > USART_Transmit(USART0, ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: NAK'ing a CHAP request.

  1. Re: NAK'ing a CHAP request.

    "John Doehead" writes:
    > 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);
    > }


    It looks like it doesn't bother supporting ACCM.

    > if (ucByte == 0x7E)
    > { // start or end of a packet
    > if (guiRxFramePtr && (uiRxChkSum==0xF0B8))
    > {
    > gpucFrame[guiRxFramePtr++] = ucByte; // insert character
    > in buffer


    That part makes no sense. The final 7E is no part of the received
    datagram. The driver should be discarding it.

    > pbyData = gpucFrame;
    > pbyData += PPPProtocolType;


    Huh? I can't quite make that part out.

    > *puiDataLen = (unsigned int)(gpucFrame[IPLengthOffset]) *
    > 0x100 + (gpucFrame[IPLengthOffset+1]);


    Yoiks! Assuming it's always IP? Really?

    > ucEscapedFlag &= 0x7E; // clear escape character flag


    That's broken. The 7D 7E sequence means "abort this frame." See RFC
    1662, page 8:

    On reception, prior to FCS computation, each octet with value less
    than hexadecimal 0x20 is checked. If it is flagged in the receiving
    ACCM, it is simply removed (it may have been inserted by intervening
    data communications equipment). Each Control Escape octet is also
    removed, and the following octet is exclusive-or'd with hexadecimal
    0x20, unless it is the Flag Sequence (which aborts a frame).

    > guiRxFramePtr = 0; // get ready for next packet
    > gpucFrame[guiRxFramePtr++] = ucByte; // insert character in
    > buffer


    Again, 7E in the buffer? That's not right.

    > else if (ucByte == 0x7D)
    > { // if tilde character set escape flag
    > ucEscapedFlag |= 1;


    That's mildly broken. The sequence 7D 7D is illegal, but should
    (normally) result in having 5D inserted in the buffer. (Or aborting
    the frame.) Just discarding it seems wrong.

    > if ( guiRxFramePtr == 1 && ucByte != 0xff )
    > {
    > gpucFrame[guiRxFramePtr++] = 0xff; // uncompress PPP header
    > }
    > if ( guiRxFramePtr == 2 && ucByte != 3)
    > {
    > gpucFrame[guiRxFramePtr++] = 3;
    > }


    I guess that's an attempt at ACFC expansion, but it seems a touch
    strange. Not sure why it's done in the middle of reception, rather
    than afterwards.

    > if ( guiRxFramePtr == 3 && ( ucByte & 1) )
    > {
    > gpucFrame[guiRxFramePtr++] = 0;
    > }


    OK, but that should really only be done if PFC is in effect. (It
    should work like this, though.)

    > Would this not be a safe implementation regardless of the negotiated ACCM?


    Almost. It's missing the ability to drop garbage characters (those
    that have a '1' set in the ACCM -- see that same quoted section of RFC
    1662).

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


    Violate? I don't understand.

    Before LCP negotiates ACCM (or if it doesn't negotiate it at all),
    the default ACCM is FFFFFFFF. This means you must escape all control
    characters, and drop any control characters you receive. After LCP
    goes to Opened state, the negotiated ACCM can be any value, and you
    must accept control characters where the corresponding bit is '0',
    drop them where it's '1', and (of course) always accept escapes.

    It sure sounds to me (and looks to me, from the code above) like you
    should be sending Configure-Reject for the ACCM, since you just don't
    support it.

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

  2. Re: NAK'ing a CHAP request.

    Well, you did it!

    I imposed the state constraint of sending out the LCP request before the NAK
    and all is well.
    I cannot impress upon you how timely this fix comes...nor thank you enough
    for guiding me through it.
    Further, I would like to thank you for your patience when it was obvious you
    were dealing with somebody who only learnt enough of PPP to get their job
    done...you could have just said, "It's all in the rfc's".

    Well, it's to the 'books' to actually take the time to understand the
    protocol better and rewrite our ported code...I heard mention of a really
    good PPP book that I am going to grab:

    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


    ....and for all you flamers that feel praise is a waste bandwidth - consider
    the thread length and assistance provided.

    Best regards, James, and thank you to all that replied.





    "James Carlson" wrote in message
    news:xoavd64z6q7q.fsf@sun.com...
    > "John Doehead" writes:
    > > 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);
    > > }

    >
    > It looks like it doesn't bother supporting ACCM.
    >
    > > if (ucByte == 0x7E)
    > > { // start or end of a packet
    > > if (guiRxFramePtr && (uiRxChkSum==0xF0B8))
    > > {
    > > gpucFrame[guiRxFramePtr++] = ucByte; // insert

    character
    > > in buffer

    >
    > That part makes no sense. The final 7E is no part of the received
    > datagram. The driver should be discarding it.
    >
    > > pbyData = gpucFrame;
    > > pbyData += PPPProtocolType;

    >
    > Huh? I can't quite make that part out.
    >
    > > *puiDataLen = (unsigned int)(gpucFrame[IPLengthOffset])

    *
    > > 0x100 + (gpucFrame[IPLengthOffset+1]);

    >
    > Yoiks! Assuming it's always IP? Really?
    >
    > > ucEscapedFlag &= 0x7E; // clear escape character flag

    >
    > That's broken. The 7D 7E sequence means "abort this frame." See RFC
    > 1662, page 8:
    >
    > On reception, prior to FCS computation, each octet with value less
    > than hexadecimal 0x20 is checked. If it is flagged in the receiving
    > ACCM, it is simply removed (it may have been inserted by intervening
    > data communications equipment). Each Control Escape octet is also
    > removed, and the following octet is exclusive-or'd with hexadecimal
    > 0x20, unless it is the Flag Sequence (which aborts a frame).
    >
    > > guiRxFramePtr = 0; // get ready for next packet
    > > gpucFrame[guiRxFramePtr++] = ucByte; // insert character

    in
    > > buffer

    >
    > Again, 7E in the buffer? That's not right.
    >
    > > else if (ucByte == 0x7D)
    > > { // if tilde character set escape flag
    > > ucEscapedFlag |= 1;

    >
    > That's mildly broken. The sequence 7D 7D is illegal, but should
    > (normally) result in having 5D inserted in the buffer. (Or aborting
    > the frame.) Just discarding it seems wrong.
    >
    > > if ( guiRxFramePtr == 1 && ucByte != 0xff )
    > > {
    > > gpucFrame[guiRxFramePtr++] = 0xff; // uncompress PPP

    header
    > > }
    > > if ( guiRxFramePtr == 2 && ucByte != 3)
    > > {
    > > gpucFrame[guiRxFramePtr++] = 3;
    > > }

    >
    > I guess that's an attempt at ACFC expansion, but it seems a touch
    > strange. Not sure why it's done in the middle of reception, rather
    > than afterwards.
    >
    > > if ( guiRxFramePtr == 3 && ( ucByte & 1) )
    > > {
    > > gpucFrame[guiRxFramePtr++] = 0;
    > > }

    >
    > OK, but that should really only be done if PFC is in effect. (It
    > should work like this, though.)
    >
    > > Would this not be a safe implementation regardless of the negotiated

    ACCM?
    >
    > Almost. It's missing the ability to drop garbage characters (those
    > that have a '1' set in the ACCM -- see that same quoted section of RFC
    > 1662).
    >
    > > 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.

    >
    > Violate? I don't understand.
    >
    > Before LCP negotiates ACCM (or if it doesn't negotiate it at all),
    > the default ACCM is FFFFFFFF. This means you must escape all control
    > characters, and drop any control characters you receive. After LCP
    > goes to Opened state, the negotiated ACCM can be any value, and you
    > must accept control characters where the corresponding bit is '0',
    > drop them where it's '1', and (of course) always accept escapes.
    >
    > It sure sounds to me (and looks to me, from the code above) like you
    > should be sending Configure-Reject for the ACCM, since you just don't
    > support it.
    >
    > --
    > 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.

    "John Doehead" writes:

    ]Well, you did it!

    ]I imposed the state constraint of sending out the LCP request before the NAK
    ]and all is well.
    ]I cannot impress upon you how timely this fix comes...nor thank you enough
    ]for guiding me through it.
    ]Further, I would like to thank you for your patience when it was obvious you
    ]were dealing with somebody who only learnt enough of PPP to get their job
    ]done...you could have just said, "It's all in the rfc's".

    Yes, James IS very impressive, both in his knowledge and in his
    willingness and ability to help.

    And please please do follow up on your determination to improve the
    code. Unfortunately many many of the ppp implimentations out there
    recently have been written by people in your boat, who got it to work,
    but the code turned out not to be very robust.
    It does not matter if the code does not support all the bells and
    whistles of ppp. Just as long as it supports what it does support well,
    and handles the rejection of what it does not support well (ie obeys the
    standards). I say this only because we keep reading in this group the
    problems people have with code written by people who do not follow this.
    Ie, choose a mininal subset of ppp to support, and do it well. Even if
    it is not the most efficient. Proper support of an inefficient subset of
    ppp is far better than bad support of a more efficient set.



    ]Well, it's to the 'books' to actually take the time to understand the
    ]protocol better and rewrite our ported code...I heard mention of a really
    ]good PPP book that I am going to grab:

    ]http://www.amazon.com/exec/obidos/tg/detail/-/0201700530/qid=1084912502/sr=8
    ]-2/ref=sr_8_xs_ap_i2_xgl14/103-0342719-0021420?v=glance&s=books&n=507846



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2