Failure to Connect, Windows PPP w/CHAP - PPP

This is a discussion on Failure to Connect, Windows PPP w/CHAP - PPP ; I am working on an embedded system which is attempting to support a direct serial ppp connection with a computer running windows xp. I setup a "communications cable between two computers" attached to COM1 and an outgoing network connection which ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Failure to Connect, Windows PPP w/CHAP

  1. Failure to Connect, Windows PPP w/CHAP

    I am working on an embedded system which is attempting to support a
    direct serial ppp connection with a computer running windows xp. I
    setup a "communications cable between two computers" attached to COM1
    and an outgoing network connection which is setup with TCP/IP protocol.
    Inside the security settings for the outgoing connection on windows I
    have enabled CHAP.

    I attempt to connect using windows to the embedded system and the
    following PPP event sequence occurs:
    Windows Tx: LCP: Configure Request
    Embedded Tx: LCP: Configure Request
    Embedded Tx: LCP: Configure Ack
    Windows Tx: LCP: Configure Ack
    Windows Tx: LCP: Identification Packet
    Windows Tx: LCP: Identification Packet
    Embedded Tx: CHAP: Configure Request
    Embedded Tx: LCP: Protocol Reject
    Windows Tx: CHAP: Configure Ack
    Embedded Tx: LCP: Protocol Reject
    Embedded Tx: CHAP: Configure Nack
    Embedded Tx: IPCP: Configure Request
    Embedded Tx: IPCP: Configure Request
    Embedded Tx: IPCP: Configure Request...(repeats the IPCP Conf Req)

    Am I doing something out of order or missing something for windows. I
    was expecting windows to transmit a configure request for CHAP also.
    At this poing in the connection windows just sits there waiting for
    something. I am assumming that both sides need to configure CHAP, is
    this valid?


  2. Re: Failure to Connect, Windows PPP w/CHAP

    In article <1118871223.744595.147760@g47g2000cwa.googlegroups. com>,
    Scooter wrote:
    >I am working on an embedded system which is attempting to support a
    >direct serial ppp connection with a computer running windows xp. I
    >setup a "communications cable between two computers" attached to COM1
    >and an outgoing network connection which is setup with TCP/IP protocol.
    > Inside the security settings for the outgoing connection on windows I
    >have enabled CHAP.
    >
    >I attempt to connect using windows to the embedded system and the
    >following PPP event sequence occurs:
    >Windows Tx: LCP: Configure Request
    >Embedded Tx: LCP: Configure Request
    >Embedded Tx: LCP: Configure Ack
    >Windows Tx: LCP: Configure Ack
    >Windows Tx: LCP: Identification Packet
    >Windows Tx: LCP: Identification Packet
    >Embedded Tx: CHAP: Configure Request
    >Embedded Tx: LCP: Protocol Reject
    >Windows Tx: CHAP: Configure Ack
    >Embedded Tx: LCP: Protocol Reject
    >Embedded Tx: CHAP: Configure Nack
    >Embedded Tx: IPCP: Configure Request
    >Embedded Tx: IPCP: Configure Request
    >Embedded Tx: IPCP: Configure Request...(repeats the IPCP Conf Req)
    >
    >Am I doing something out of order or missing something for windows. I
    >was expecting windows to transmit a configure request for CHAP also.


    First of all, I'm guessing your "decoding" of the PPP packets is slightly
    in error. CHAP does not have a Configure-Request, it has a CHAP Challenge
    for code 1. Also, codes 2 and 3 are not Configure-Ack and Configure-Nak,
    but are instead CHAP Response and CHAP Success respectively. From the
    looks of it, the authentication phase probably worked just fine.

    Secondly, the Windows machine is not going to send out a CHAP Challenge
    as that would imply that the Windows machine would be authenticating your
    embedded system - that's not a typical setup.

    >At this point in the connection windows just sits there waiting for
    >something.


    Check how you configured and implemented ACCM. Also see if you told
    Windows you would be authenticating yourself to Windows?

    >I am assumming that both sides need to configure CHAP, is this valid?


    No. It's not necessary for both sides to use CHAP unless it's been
    negotiated by both sides in LCP. Can you show the complete packets
    so we can see what got negotiated?

    =========== For PPP Protocol Analysis, check out PacketView Pro! ===========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==== I don't think infinity is as big as it seems - P.Klos, 20-Mar-2005 ====

  3. Re: Failure to Connect, Windows PPP w/CHAP

    The LCP configure request sent by windows has the ACCM set to four
    bytes of zero. The LCP configure request sent by the embedded system
    doesn't include the ACCM. All that it has inside it is the MRU and
    Authentication Protocol settings. Do I need to include the ACCM inside
    my configure request also?

    Here is the actual packet data taken from a serial port sniffer. The
    program sniffing the data has already removed the HDLC framing
    information and remapped any mapped characters. Right now I believe
    the only characters being mapped are the 0x7e and 0x7d characters. If
    needed I can post the entire frames.

    Windows TX: LCP Configure Request
    ff 03 c0 21 01 00 00 17 02 06 00 00 00 00 05 06 15 75 16 6a 07 02 08 02
    0d 03 06 11 14

    Embedded TX: LCP Configure Request
    ff 03 c0 21 01 00 00 0d 01 04 05 dc 03 05 c2 23 05 92 1d

    Embedded TX: LCP Configure Ack
    ff 03 c0 21 02 00 00 17 02 06 00 00 00 00 05 06 15 75 16 6a 07 02 08 02
    0d 03 06 5b 86

    Windows TX: LCP Configure Ack
    ff 03 c0 21 02 00 00 0d 01 04 05 dc 03 05 c2 23 05 65 13

    Windows TX: LCP Identification
    ff 03 c0 21 0c 01 00 12 15 75 16 6a 4d 53 52 41 53 56 35 2e 31 30 3b 5d

    Windows TX: LCP Identification
    ff 03 c0 21 0c 02 00 15 15 75 16 6a 4d 53 52 41 53 2d 31 2d 44 32 34 31
    36 f8 c1

    Embedded TX: CHAP Challenge
    ff 03 c2 23 01 0b 00 36 29 23 be 84 e1 6c d6 ae 52 90 49 f1 f1 bb e9 eb
    b3 a6 dbff 03 c2 23 01 0b 00 36 29 23 be 84 e1 6c d6 ae 52 90 49 f1 f1
    bb e9 eb b3 a6 db 3c 87 0c 3e 99 24 5e 0d 1c 06 b7 47 de b3 12 4d c8 43
    bb 8b a6 1f 03 50 41 53 53 57 4f 52 44 20 4e

    Embedded TX: LCP Reject ( I think this reject is for the LCP ID packets
    earlier )
    ff 03 c0 21 08 01 00 16 0c 01 00 12 15 75 16 6a 4d 53 52 41 53 56 35 2e
    31 30 00 9e

    Windows TX: CHAP Response
    ff 03 c2 23 02 0b 00 1d 10 1e cb cc 6a 88 5a 8f 2b 26 55 80 7e 7d 8d 55
    80 50 41 53 53 57 4f 52 44 91 ca

    Embedded TX: LCP Reject ( for the second LCP ID packet received earlier
    )
    ff 03 c0 21 08 02 00 19 0c 02 00 15 15 75 16 6a 4d 53 52 41 53 2d 31 2d
    44 32 34 31 36 e3 47

    Embedded TX: CHAP Success
    ff 03 c2 23 03 0b 00 04 03 e1

    Embedded TX: IPCP Configure Request
    ff 03 80 21 01 02 00 0a 03 06 80 00 00 01 f3 c2

    Embedded TX: IPCP Configure Request
    ff 03 80 21 01 02 00 0a 03 06 80 00 00 01 f3 c2


  4. Re: Failure to Connect, Windows PPP w/CHAP

    In article news:d8q9sd$11mc$1@pyrite.mv.net, Patrick Klos wrote:
    > In article <1118871223.744595.147760@g47g2000cwa.googlegroups. com>,
    > Scooter wrote:

    [...]
    > No. It's not necessary for both sides to use CHAP unless it's been
    > negotiated by both sides in LCP. Can you show the complete packets
    > so we can see what got negotiated?
    >

    You can configure trace logging on the Windows end, both to see the
    complete packets, and to see how it behaves on receiving them. e.g.
    C:\temp>netsh
    netsh>ras
    netsh ras>sh tr
    [...]
    RASIPCP disabled
    RASEAP disabled
    RASDLG disabled
    RASCHAP disabled
    RASCCP disabled
    RASBACP disabled
    RASAUTH disabled
    RASAPI32 disabled
    PPP disabled
    [...]

    and for each of the ones you want to enable, use "set tracing XXXX
    enabled", or use * for all.
    --
    Alan J. McFarlane
    http://www.alanjmcf.me.uk/
    Please follow-up in the newsgroup for the benefit of all.


  5. Re: Failure to Connect, Windows PPP w/CHAP

    Should the trace results print inside the cmd window or do they get
    stored to a log somewhere? I enabled the trace results for PPP only.


  6. Re: Failure to Connect, Windows PPP w/CHAP

    In article news:1118934498.077701.218550@g47g2000cwa.googlegr oups.com,
    Scooter wrote:
    > Should the trace results print inside the cmd window or do they get
    > stored to a log somewhere? I enabled the trace results for PPP only.
    >

    Woops, I did mean to explain where it went. It appears as a set of log
    files in the "%windir%\tracing" directory.
    --
    Alan J. McFarlane
    http://www.alanjmcf.me.uk/
    Please follow-up in the newsgroup for the benefit of all.


  7. Re: Failure to Connect, Windows PPP w/CHAP

    "Scooter" writes:
    > The LCP configure request sent by windows has the ACCM set to four
    > bytes of zero. The LCP configure request sent by the embedded system
    > doesn't include the ACCM. All that it has inside it is the MRU and
    > Authentication Protocol settings. Do I need to include the ACCM inside
    > my configure request also?


    That implies that traffic from the Windows system to the embedded
    system should have all of the control characters in the range 00 to 1F
    (hex) escaped, but that traffic in the other direction needn't be
    escaped.

    In general, it's wise to make sure that the ACCM is negotiated the
    same way in both directions because there are just far too many
    systems that are bug-ridden and can't handle an asymmetric ACCM
    properly. It's certainly not _illegal_, but I wouldn't say it's a
    good idea.

    > Windows TX: LCP Configure Request
    > ff 03 c0 21 01 00 00 17 02 06 00 00 00 00 05 06 15 75 16 6a 07 02 08 02
    > 0d 03 06 11 14
    >
    > Embedded TX: LCP Configure Request
    > ff 03 c0 21 01 00 00 0d 01 04 05 dc 03 05 c2 23 05 92 1d


    What? Why is the embedded system asking for an MRU of 1500? That's
    the PPP default. Negotiating for the default doesn't make sense.

    > Embedded TX: LCP Configure Ack
    > ff 03 c0 21 02 00 00 17 02 06 00 00 00 00 05 06 15 75 16 6a 07 02 08 02
    > 0d 03 06 5b 86


    You've just acked everything -- *including* the Microsoft proprietary
    callback option.

    Is that what you meant to do?

    > Embedded TX: CHAP Challenge
    > ff 03 c2 23 01 0b 00 36 29 23 be 84 e1 6c d6 ae 52 90 49 f1 f1 bb e9 eb
    > b3 a6 dbff 03 c2 23 01 0b 00 36 29 23 be 84 e1 6c d6 ae 52 90 49 f1 f1
    > bb e9 eb b3 a6 db 3c 87 0c 3e 99 24 5e 0d 1c 06 b7 47 de b3 12 4d c8 43
    > bb 8b a6 1f 03 50 41 53 53 57 4f 52 44 20 4e


    I see two packets there. I'll just assume that it's a cut-n-paste
    error of some sort.

    > Embedded TX: LCP Reject ( I think this reject is for the LCP ID packets
    > earlier )
    > ff 03 c0 21 08 01 00 16 0c 01 00 12 15 75 16 6a 4d 53 52 41 53 56 35 2e
    > 31 30 00 9e


    That should be ok.

    > Embedded TX: CHAP Success
    > ff 03 c2 23 03 0b 00 04 03 e1
    >
    > Embedded TX: IPCP Configure Request
    > ff 03 80 21 01 02 00 0a 03 06 80 00 00 01 f3 c2


    I think the Windows side is waiting for you to do CBCP, since you
    promised to do that during LCP.

    --
    James Carlson, KISS Network
    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

  8. Re: Failure to Connect, Windows PPP w/CHAP

    Here is the results that windows printed:

    [120] 13:36:45:524: PPPEMSG_Start recvd, d=,
    hPort=6,callback=0,mask=20208,IfType=-1
    [1824] 13:36:45:544: Line up event occurred on port 6
    [1824] 13:36:45:544: Local identification = MSRAS-1-D2416
    [1824] 13:36:45:544: PortName: COM1
    [1824] 13:36:45:544: Starting PPP on link with
    IfType=0xffffffff,IPIf=0xffffffff,IPXIf=0xffffffff
    [1824] 13:36:45:544: RasGetBuffer returned 8fe89f0 for SendBuf
    [1824] 13:36:45:544: FsmInit called for protocol = c021, port = 6
    [1824] 13:36:45:544: ConfigInfo = 20208
    [1824] 13:36:45:544: APs available = 8
    [1824] 13:36:45:544: FsmReset called for protocol = c021, port = 6
    [1824] 13:36:45:564: Inserting port in bucket # 6
    [1824] 13:36:45:564: Inserting bundle in bucket # 7
    [1824] 13:36:45:564: FsmOpen event received for protocol c021 on port 6
    [1824] 13:36:45:564: FsmThisLayerStarted called for protocol = c021,
    port = 6
    [1824] 13:36:45:564: FsmUp event received for protocol c021 on port 6
    [1824] 13:36:45:564: [1824] 13:36:45:564: 0x19, Id = 0x0, Port = 6
    [1824] 13:36:45:564: |.!............$j|
    [1824] 13:36:45:564: <51 7F 07 02 08 02 0D 03 06 00 00 00 00 00 00 00
    |Q..............|
    [1824] 13:36:45:564:
    [1824] 13:36:45:564: InsertInTimerQ called
    portid=104,Id=0,Protocol=c021,EventType=0,fAuth=0
    [1824] 13:36:45:564: InsertInTimerQ called
    portid=104,Id=0,Protocol=0,EventType=3,fAuth=0
    [1556] 13:36:45:865: Packet received (15 bytes) for hPort 6
    [1824] 13:36:45:865: >PPP packet received at 06/16/2005 18:36:45:865
    [1824] 13:36:45:865: >Protocol = LCP, Type = Configure-Req, Length =
    0xf, Id = 0x0, Port = 6
    [1824] 13:36:45:865: >C0 21 01 00 00 0D 01 04 05 DC 03 05 C2 23 05 00
    |.!...........#..|
    [1824] 13:36:45:865:
    [1824] 13:36:45:865: [1824] 13:36:45:865: 0xf, Id = 0x0, Port = 6
    [1824] 13:36:45:865: |.!...........#..|
    [1824] 13:36:45:865:
    [1556] 13:36:45:905: Packet received (25 bytes) for hPort 6
    [1824] 13:36:45:905: >PPP packet received at 06/16/2005 18:36:45:905
    [1824] 13:36:45:905: >Protocol = LCP, Type = Configure-Ack, Length =
    0x19, Id = 0x0, Port = 6
    [1824] 13:36:45:905: >C0 21 02 00 00 17 02 06 00 00 00 00 05 06 24 6A
    |.!............$j|
    [1824] 13:36:45:905: >51 7F 07 02 08 02 0D 03 06 00 00 00 00 00 00 00
    |Q..............|
    [1824] 13:36:45:905:
    [1824] 13:36:45:905: RemoveFromTimerQ called
    portid=104,Id=0,Protocol=c021,EventType=0,fAuth=0
    [1824] 13:36:45:905: FsmThisLayerUp called for protocol = c021, port =
    6
    [1824] 13:36:45:905: LCP Local Options-------------
    [1824] 13:36:45:905:
    MRU=1500,ACCM=0,Auth=0,MagicNumber=610947455,PFC=O N,ACFC=ON
    [1824] 13:36:45:905: Recv Framing =
    PPP,SSHF=OFF,MRRU=1500,LinkDiscrim=0,BAP=OFF
    [1824] 13:36:45:905: LCP Remote Options-------------
    [1824] 13:36:45:905:
    MRU=1500,ACCM=-1,Auth=c223,MagicNumber=0,PFC=OFF,ACFC=OFF
    [1824] 13:36:45:905: Send Framing =
    PPP,SSHF=OFF,MRRU=1500,LinkDiscrim=0
    [1824] 13:36:45:905: LCP Configured successfully
    [1824] 13:36:45:905: [1824] 13:36:45:905: 0x14, Id = 0x1, Port = 6
    [1824] 13:36:45:905: |.!....$jQMSRASV|
    [1824] 13:36:45:905: <35 2E 31 30 00 00 00 00 00 00 00 00 00 00 00 00
    |5.10............|
    [1824] 13:36:45:905:
    [1824] 13:36:45:905: [1824] 13:36:45:905: 0x17, Id = 0x2, Port = 6
    [1824] 13:36:45:905: |.!....$jQMSRAS-|
    [1824] 13:36:45:905: <31 2D 44 32 34 31 36 00 00 00 00 00 00 00 00 00
    |1-D2416.........|
    [1824] 13:36:45:905:
    [1824] 13:36:45:905: Authenticating phase started
    [1824] 13:36:45:915: Calling APWork in APStart
    [1556] 13:36:46:365: Packet received (56 bytes) for hPort 6
    [1824] 13:36:46:365: >PPP packet received at 06/16/2005 18:36:46:365
    [1824] 13:36:46:365: >Protocol = CHAP, Type = Protocol specific, Length
    = 0x38, Id = 0xb, Port = 6
    [1824] 13:36:46:365: >C2 23 01 0B 00 36 29 23 BE 84 E1 6C D6 AE 52 90
    |.#...6)#...l..R.|
    [1824] 13:36:46:365: >49 F1 F1 BB E9 EB B3 A6 DB 3C 87 0C 3E 99 24 5E
    |I........<..>.$^|
    [1824] 13:36:46:365: >0D 1C 06 B7 47 DE B3 12 4D C8 43 BB 8B A6 1F 03
    |....G...M.C.....|
    [1824] 13:36:46:365: >50 41 53 53 57 4F 52 44 00 00 00 00 00 00 00 00
    |PASSWORD........|
    [1824] 13:36:46:365:
    [1824] 13:36:46:365: [1824] 13:36:46:365: = 0x1f, Id = 0xb, Port = 6
    [1824] 13:36:46:365: |.#........j.Z.+&|
    [1824] 13:36:46:365: <55 80 7E 7D 8D 55 80 50 41 53 53 57 4F 52 44 00
    |U.~}.U.PASSWORD.|
    [1824] 13:36:46:365:
    [1824] 13:36:46:365: InsertInTimerQ called
    portid=104,Id=11,Protocol=c223,EventType=0,fAuth=0
    [1556] 13:36:46:405: Packet received (24 bytes) for hPort 6
    [1824] 13:36:46:405: >PPP packet received at 06/16/2005 18:36:46:405
    [1824] 13:36:46:405: >Protocol = LCP, Type = Protocol-Reject, Length =
    0x18, Id = 0x1, Port = 6
    [1824] 13:36:46:405: >C0 21 08 01 00 16 0C 01 00 12 24 6A 51 7F 4D 53
    |.!........$jQMS|
    [1824] 13:36:46:405: >52 41 53 56 35 2E 31 30 00 00 00 00 00 00 00 00
    |RASV5.10........|
    [1824] 13:36:46:405:
    [1824] 13:36:46:405: PPP Protocol Reject, Protocol = c01
    [1556] 13:36:46:435: Packet received (27 bytes) for hPort 6
    [1824] 13:36:46:435: >PPP packet received at 06/16/2005 18:36:46:435
    [1824] 13:36:46:435: >Protocol = LCP, Type = Protocol-Reject, Length =
    0x1b, Id = 0x2, Port = 6
    [1824] 13:36:46:435: >C0 21 08 02 00 19 0C 02 00 15 24 6A 51 7F 4D 53
    |.!........$jQMS|
    [1824] 13:36:46:435: >52 41 53 2D 31 2D 44 32 34 31 36 00 00 00 00 00
    |RAS-1-D2416.....|
    [1824] 13:36:46:435:
    [1824] 13:36:46:435: PPP Protocol Reject, Protocol = c02
    [1556] 13:36:46:786: Packet received (6 bytes) for hPort 6
    [1824] 13:36:46:786: >PPP packet received at 06/16/2005 18:36:46:786
    [1824] 13:36:46:786: >Protocol = CHAP, Type = Protocol specific, Length
    = 0x6, Id = 0xb, Port = 6
    [1824] 13:36:46:786: >C2 23 03 0B 00 04 00 00 00 00 00 00 00 00 00 00
    |.#..............|
    [1824] 13:36:46:786:
    [1824] 13:36:46:786: RemoveFromTimerQ called
    portid=104,Id=11,Protocol=c223,EventType=0,fAuth=0
    [1824] 13:36:46:786: FsmThisLayerUp called for protocol = c223, port =
    6
    [1824] 13:36:46:786: NotifyCaller(hPort=6, dwMsgId=17)
    [1824] 13:36:46:786: Callback phase started
    [1824] 13:36:46:786: CallbackPriv in CB = 0
    [1556] 13:36:46:796: Packet received (12 bytes) for hPort 6
    [1824] 13:36:46:796: >PPP packet received at 06/16/2005 18:36:46:796
    [1824] 13:36:46:796: >Protocol = IPCP, Type = Configure-Req, Length =
    0xc, Id = 0x2, Port = 6
    [1824] 13:36:46:796: >80 21 01 02 00 0A 03 06 80 00 00 01 00 00 00 00
    |.!..............|
    [1824] 13:36:46:796:
    [1824] 13:36:46:796: Non-LCP packet received when LCP is not opened
    [1824] 13:36:46:796: Packet being silently discarded
    [1556] 13:36:51:423: Packet received (12 bytes) for hPort 6
    [1824] 13:36:51:423: >PPP packet received at 06/16/2005 18:36:51:423
    [1824] 13:36:51:423: >Protocol = IPCP, Type = Configure-Req, Length =
    0xc, Id = 0x2, Port = 6
    [1824] 13:36:51:423: >80 21 01 02 00 0A 03 06 80 00 00 01 00 00 00 00
    |.!..............|
    [1824] 13:36:51:423:
    [1824] 13:36:51:423: Non-LCP packet received when LCP is not opened
    [1824] 13:36:51:423: Packet being silently discarded
    [1556] 13:36:56:069: Packet received (12 bytes) for hPort 6
    [1824] 13:36:56:069: >PPP packet received at 06/16/2005 18:36:56:069
    [1824] 13:36:56:069: >Protocol = IPCP, Type = Configure-Req, Length =
    0xc, Id = 0x2, Port = 6
    [1824] 13:36:56:069: >80 21 01 02 00 0A 03 06 80 00 00 01 00 00 00 00
    |.!..............|
    [1824] 13:36:56:069:
    [1824] 13:36:56:069: Non-LCP packet received when LCP is not opened
    [1824] 13:36:56:069: Packet being silently discarded
    [1556] 13:37:00:716: Packet received (12 bytes) for hPort 6
    [1824] 13:37:00:716: >PPP packet received at 06/16/2005 18:37:00:716
    [1824] 13:37:00:716: >Protocol = IPCP, Type = Configure-Req, Length =
    0xc, Id = 0x2, Port = 6
    [1824] 13:37:00:716: >80 21 01 02 00 0A 03 06 80 00 00 01 00 00 00 00
    |.!..............|
    [1824] 13:37:00:716:
    [1824] 13:37:00:716: Non-LCP packet received when LCP is not opened
    [1824] 13:37:00:716: Packet being silently discarded
    [1556] 13:37:05:363: Packet received (12 bytes) for hPort 6
    [1824] 13:37:05:363: >PPP packet received at 06/16/2005 18:37:05:363
    [1824] 13:37:05:363: >Protocol = IPCP, Type = Configure-Req, Length =
    0xc, Id = 0x2, Port = 6
    [1824] 13:37:05:363: >80 21 01 02 00 0A 03 06 80 00 00 01 00 00 00 00
    |.!..............|
    [1824] 13:37:05:363:
    [1824] 13:37:05:363: Non-LCP packet received when LCP is not opened
    [1824] 13:37:05:363: Packet being silently discarded
    [120] 13:37:12:693: PppStop

    [120] 13:37:12:693: PPPEMSG_Stop recvd

    [1824] 13:37:12:693: FsmClose event received for protocol c021 on port
    6
    [1824] 13:37:12:693: RemoveFromTimerQ called
    portid=104,Id=0,Protocol=c021,EventType=0,fAuth=0
    [1824] 13:37:12:693: FsmThisLayerDown called for protocol = c021, port
    = 6
    [1824] 13:37:12:693: RemoveFromTimerQ called
    portid=104,Id=11,Protocol=c223,EventType=0,fAuth=0
    [1824] 13:37:12:693: [1824] 13:37:12:693: 0x12, Id = 0x3, Port = 6
    [1824] 13:37:12:693: |.!....$jQ.<.t..|
    [1824] 13:37:12:693: <00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    |................|
    [1824] 13:37:12:693:
    [1824] 13:37:12:693: InsertInTimerQ called
    portid=104,Id=3,Protocol=c021,EventType=0,fAuth=0
    [1824] 13:37:16:579: Recv timeout event received for
    portid=104,Id=3,Protocol=c021,fAuth=0
    [1824] 13:37:16:579: [1824] 13:37:16:579: 0x12, Id = 0x4, Port = 6
    [1824] 13:37:16:579: |.!....$jQ.<.t..|
    [1824] 13:37:16:579: <00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    |................|
    [1824] 13:37:16:579:
    [1824] 13:37:16:579: InsertInTimerQ called
    portid=104,Id=4,Protocol=c021,EventType=0,fAuth=0
    [1824] 13:37:20:585: Recv timeout event received for
    portid=104,Id=4,Protocol=c021,fAuth=0
    [1824] 13:37:20:585: Terminate retry exceeded
    [1824] 13:37:20:585: FsmThisLayerFinished called for protocol = c021,
    port = 6
    [1824] 13:37:20:585: NotifyCaller(hPort=6, dwMsgId=10)
    [1556] 13:37:22:658: PPPEMSG_LineDown recvd, hPort=6

    [1824] 13:37:22:658: Line down event occurred on port 6
    [1824] 13:37:23:048: FsmDown event received for protocol c021 on port 6
    [1824] 13:37:23:048: RemoveFromTimerQ called
    portid=104,Id=4,Protocol=c021,EventType=0,fAuth=0
    [1824] 13:37:23:048: FsmReset called for protocol = c021, port = 6
    [1824] 13:37:23:048: RemoveFromTimerQ called
    portid=104,Id=0,Protocol=0,EventType=3,fAuth=0
    [1824] 13:37:23:048: RemoveFromTimerQ called
    portid=104,Id=0,Protocol=0,EventType=7,fAuth=0
    [1824] 13:37:23:048: RemoveFromTimerQ called
    portid=104,Id=0,Protocol=0,EventType=2,fAuth=0
    [1824] 13:37:23:048: RemoveFromTimerQ called
    portid=104,Id=0,Protocol=0,EventType=1,fAuth=0
    [1824] 13:37:23:048: LcpEnd
    [1824] 13:37:23:048: Post line down event occurred on port 6
    [1824] 13:37:23:048: NotifyCaller(hPort=6, dwMsgId=23)


  9. Re: Failure to Connect, Windows PPP w/CHAP

    "Scooter" writes:
    > Here is the results that windows printed:


    Did you read my previous posting? This shows the same problem.

    > [1824] 13:36:46:786: Callback phase started
    > [1824] 13:36:46:786: CallbackPriv in CB = 0


    You've agreed to use Microsoft's proprietary callback scheme. Windows
    is now waiting for you to do that.

    > [1556] 13:36:46:796: Packet received (12 bytes) for hPort 6
    > [1824] 13:36:46:796: >PPP packet received at 06/16/2005 18:36:46:796
    > [1824] 13:36:46:796: >Protocol = IPCP, Type = Configure-Req, Length =
    > 0xc, Id = 0x2, Port = 6
    > [1824] 13:36:46:796: >80 21 01 02 00 0A 03 06 80 00 00 01 00 00 00 00
    > |.!..............|
    > [1824] 13:36:46:796:
    > [1824] 13:36:46:796: Non-LCP packet received when LCP is not opened
    > [1824] 13:36:46:796: Packet being silently discarded


    Your requests to set up IP are ignored. The Windows system is waiting
    for you to negotiate CBCP, because that's what you agreed to during
    LCP.

    Why did you ack the CBCP option if you weren't prepared to do
    callback?

    --
    James Carlson, KISS Network
    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: Failure to Connect, Windows PPP w/CHAP

    Sorry about the windows post James, I didn't notice your post until
    after I posted it. I didn't know what CBCP was until you explained it.
    I attempted to reject the option but now windows is discarding my
    reject packet because it believes it to be misformed.

    [1080] 16:03:54:411: [1080] 16:03:54:411: 0x19, Id = 0x0, Port = 6
    [1080] 16:03:54:411: |.!............l.|
    [1080] 16:03:54:411: <09 F9 07 02 08 02 0D 03 06 00 00 00 00 00 00 00
    |................|
    [1080] 16:03:54:411:
    [1080] 16:03:54:411: InsertInTimerQ called
    portid=18,Id=0,Protocol=c021,EventType=0,fAuth=0
    [1080] 16:03:54:411: InsertInTimerQ called
    portid=18,Id=0,Protocol=0,EventType=3,fAuth=0
    [400] 16:03:54:871: Packet received (15 bytes) for hPort 6
    [1080] 16:03:54:871: >PPP packet received at 06/16/2005 21:03:54:871
    [1080] 16:03:54:871: >Protocol = LCP, Type = Configure-Req, Length =
    0xf, Id = 0x0, Port = 6
    [1080] 16:03:54:871: >C0 21 01 00 00 0D 01 04 05 DC 03 05 C2 23 05 00
    |.!...........#..|
    [1080] 16:03:54:871:
    [1080] 16:03:54:871: [1080] 16:03:54:871: 0xf, Id = 0x0, Port = 6
    [1080] 16:03:54:871: |.!...........#..|
    [1080] 16:03:54:871:
    [400] 16:03:54:881: Packet received (9 bytes) for hPort 6
    [1080] 16:03:54:881: >PPP packet received at 06/16/2005 21:03:54:881
    [1080] 16:03:54:881: >Protocol = LCP, Type = Configure-Reject, Length =
    0x9, Id = 0x0, Port = 6
    [1080] 16:03:54:881: >C0 21 04 00 00 03 0D 03 06 00 00 00 00 00 00 00
    |.!..............|
    [1080] 16:03:54:881:
    [1080] 16:03:54:881: Silently discarding badly formed packet


  11. Re: Failure to Connect, Windows PPP w/CHAP

    In article <1118957145.778832.207960@g43g2000cwa.googlegroups. com>,
    Scooter wrote:

    (is that a real email address? I've sent you several emails, but
    can't tell if you've received them??)

    >Sorry about the windows post James, I didn't notice your post until
    >after I posted it. I didn't know what CBCP was until you explained it.
    > I attempted to reject the option but now windows is discarding my
    >reject packet because it believes it to be misformed.
    >
    >[400] 16:03:54:881: Packet received (9 bytes) for hPort 6
    >[1080] 16:03:54:881: >PPP packet received at 06/16/2005 21:03:54:881
    >[1080] 16:03:54:881: >Protocol = LCP, Type = Configure-Reject, Length =
    >0x9, Id = 0x0, Port = 6
    >[1080] 16:03:54:881: >C0 21 04 00 00 03 0D 03 06 00 00 00 00 00 00 00
    >|.!..............|
    >[1080] 16:03:54:881:
    >[1080] 16:03:54:881: Silently discarding badly formed packet


    You have an incorrect length field in the header. The length should be
    7, not 3:

    C0 21 04 00 00 03 0D 03 06
    ||
    vv
    C0 21 04 00 00 07 0D 03 06

    Try that.

    Patrick
    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==== I don't think infinity is as big as it seems - P.Klos, 20-Mar-2005 ====

  12. Re: Failure to Connect, Windows PPP w/CHAP

    "Scooter" writes:
    > Sorry about the windows post James, I didn't notice your post until
    > after I posted it. I didn't know what CBCP was until you explained it.
    > I attempted to reject the option but now windows is discarding my
    > reject packet because it believes it to be misformed.


    You're not trying to rewrite PPP from scratch, are you? It's not
    complex as protocols go, but getting it _right_ is quite hard. You'd
    do much better by taking one of the existing open source
    implementations and adapting or paring it down to the environment
    you're using, than trying to reinvent this particular wheel.

    There are enough broken PPP implementations in the world to make this
    a challenging task, even if you manage to get everything right per the
    RFCs.

    > [400] 16:03:54:881: Packet received (9 bytes) for hPort 6
    > [1080] 16:03:54:881: >PPP packet received at 06/16/2005 21:03:54:881
    > [1080] 16:03:54:881: >Protocol = LCP, Type = Configure-Reject, Length =
    > 0x9, Id = 0x0, Port = 6
    > [1080] 16:03:54:881: >C0 21 04 00 00 03 0D 03 06 00 00 00 00 00 00 00
    > |.!..............|
    > [1080] 16:03:54:881:
    > [1080] 16:03:54:881: Silently discarding badly formed packet


    As Patrick Klos pointed out, the packet is indeed malformed; the
    length value needs to account for the four octet LCP Code, Id, and
    Length fields. See RFC 1661.

    --
    James Carlson, KISS Network
    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: Failure to Connect, Windows PPP w/CHAP

    The code was purchased with our embedded OS and then modified by a
    contract employee that no longer is on the project. He modified the
    code to use PPP over the NTCIP T2 layer and in the process broke the
    PPP over IP layer.

    Looks like you guys were right, my LCP reject packet had the wrong
    length. I was able to establish a connection with the PC!

    Why isn't the length calculated similar to ASN.1 BER? It seems kind of
    confusing to include the length inside the length calculation.


  14. Re: Failure to Connect, Windows PPP w/CHAP

    "Scooter" writes:
    > Why isn't the length calculated similar to ASN.1 BER? It seems kind of
    > confusing to include the length inside the length calculation.


    Because it was written by sane people. ;-}

    I believe the idea is that small numbers (particularly zero) tend to
    indicate coding errors. Thus, avoiding them where possible is a good
    idea. This means starting enumerated values with 1 (or some number
    other than 0), and including the header itself in the computed length
    are Good Ideas.

    See also IPv4's Initial Header Length and Total Length fields, UDP's
    Length field, and many other protocols.

    The "loss" is that you can't have a packet quite as big -- by about 4
    bytes in this case. The effect of this loss is _much_ smaller than
    the safety it buys, since coding errors are unfortunately just so
    common.

    All that said, not everyone agrees with the goodness of avoiding the
    value 0 so carefully, so some lengths in the TCP/IP world don't
    include the size of the header. In particular, see IPv6.

    --
    James Carlson, KISS Network
    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: Failure to Connect, Windows PPP w/CHAP

    Thank you all very much for the helping decipher my problem.


+ Reply to Thread