asyncmap and windows - PPP

This is a discussion on asyncmap and windows - PPP ; Greetings. I am trying to get a 3-wire modem to work with mgetty to answer inbound calls. The client is WinXP and uses a complete modem cable. XP dials and mgetty answers. The link is authenticated. I can ping the ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: asyncmap and windows

  1. asyncmap and windows

    Greetings.

    I am trying to get a 3-wire modem to work with mgetty to answer inbound
    calls. The client is WinXP and uses a complete modem cable. XP dials
    and mgetty answers. The link is authenticated. I can ping the mgetty
    system. The mgetty system also has a web server. The server delivers
    text correctly. Images are not delivered. An SSL connection does not
    work at all. All these work over a lan, only fail with the modem
    connection.

    As the server uses a 3-wire modem, asyncmap 0xa0000 and xonxoff is
    used. The mgetty ppp options are:

    auth -chap +pap 192.168.5.1:192.168.5.2 xonxoff asyncmap 0xa0000 57600
    debug

    I suspect the issue is to do with the asyncmap and the escaped chars. I
    posted a message a few weeks back where the 3-wire modem was the client
    and the communication problems occured unless the asyncmaps of both
    linux boxes matched. I was informed that linux did not re-negotiate
    asyncmap and the only solution was to have matching asyncmaps. The post
    can be found at:
    http://groups.google.co.za/group/com...1bf4dd74b0d93b

    I can not find an option in XP allowing for a manual asyncmap value. In
    fact I found the following bit of text at:
    http://www.microsoft.com/windows2000...ncepts_114.htm
    "Software flow control is used only for transmitting text. It cannot be
    used for binary file transfer because binary data may contain the
    special flow control characters."

    This implies there is no support for manually setting asyncmaps. And
    describes the problem: only text is correctly carried on the link.

    I am guessing that the server is escaping 2 chars which are not escaped
    on the client. These chars are not used in text and there text works
    fine, but are found in other files and therefore cause a problem. I
    feel that if I could get the client to escape these two chars perhaps
    things would work. I have tried all compression and flow-control
    options on the client (XP) without any change. Server side logs can be
    found at the end of the message.

    Is this the same issue as my previous post where the linux system does
    not do what is required for a successful asyncmap negotation? Is there
    a way to set the asyncmap manually on the XP side? Is there any
    solution? There must be a solution. Any help would be very much
    appreciated.

    Regards

    Log files from the mgetty 'server':
    <29>Nov 30 00:03:34 pppd[44]: pppd 2.3.8 started by (unknown), uid 0
    <31>Nov 30 00:03:34 pppd[44]: using channel 1
    <30>Nov 30 00:03:34 pppd[44]: Using interface ppp0
    <29>Nov 30 00:03:34 pppd[44]: pppd create pidfile
    <29>Nov 30 00:03:34 pppd[44]: Connect: ppp0 <--> /dev/ttyS1
    <28>Nov 30 00:03:34 pppd[44]: Will not do PAP for user
    <28>Nov 30 00:03:34 pppd[44]: Will not do CHAP for user
    <31>Nov 30 00:03:34 pppd[44]: sent [LCP ConfReq id=0x1 0xa0000> ]
    <31>Nov 30 00:03:34 pppd[44]: rcvd [LCP ConfAck id=0x1 0xa0000> ]
    <31>Nov 30 00:03:36 pppd[44]: rcvd [LCP ConfReq id=0x2
    < 0d 03 06>]
    <31>Nov 30 00:03:36 pppd[44]: lcp_reqci: rcvd unknown option 13
    <31>Nov 30 00:03:36 pppd[44]: lcp_reqci: returning CONFREJ.
    <31>Nov 30 00:03:36 pppd[44]: sent [LCP ConfRej id=0x2 < 0d 03 06>]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [LCP ConfReq id=0x3
    ]
    <31>Nov 30 00:03:37 pppd[44]: lcp_reqci: returning CONFACK.
    <31>Nov 30 00:03:37 pppd[44]: sent [LCP ConfAck id=0x3
    ]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [LCP code=0xc id=0x4 4b b4 67 66 4d
    53 52 41 53 56 35 2e 32 30]
    <31>Nov 30 00:03:37 pppd[44]: sent [LCP CodeRej id=0x2 0c 04 00 12 4b
    b4 67 66 4d 53 52 41 53 56 35 2e 32 30]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [LCP code=0xc id=0x5 4b b4 67 66 4d
    53 52 41 53 2d 30 2d 57 41 52 52 45 4e]
    <31>Nov 30 00:03:37 pppd[44]: sent [LCP CodeRej id=0x3 0c 05 00 16 4b
    b4 67 66 4d 53 52 41 53 2d 30 2d 57 41 52 52 45 4e]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [PAP AuthReq id=0x1f
    user="dialinuser" password="****"]
    <31>Nov 30 00:03:37 pppd[44]: sent [PAP AuthAck id=0x1f "Login ok"]
    <31>Nov 30 00:03:37 pppd[44]: sent [IPCP ConfReq id=0x1 192.168.5.1> ]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [CCP ConfReq id=0x6 < 12 06 00 00 00
    01>]
    <31>Nov 30 00:03:37 pppd[44]: sent [CCP ConfReq id=0x1]
    <31>Nov 30 00:03:37 pppd[44]: sent [CCP ConfRej id=0x6 < 12 06 00 00 00
    01>]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [IPCP ConfReq id=0x7 01> <31>Nov 30 00:03:37 pppd[44]: sent [IPCP ConfRej id=0x7 0.0.0.0> ]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [IPCP ConfAck id=0x1 192.168.5.1> ]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [CCP TermReq
    id=0x8"K\37777777664gf\000<\37777777715t\000\000\002\37777777734"]
    <31>Nov 30 00:03:37 pppd[44]: sent [CCP TermAck id=0x8]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [IPCP ConfReq id=0x9 01> ]
    <31>Nov 30 00:03:37 pppd[44]: sent [IPCP ConfNak id=0x9 192.168.5.2>]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [IPCP ConfReq id=0xa 01> ]
    <31>Nov 30 00:03:37 pppd[44]: sent [IPCP ConfAck id=0xa 01> ]
    <29>Nov 30 00:03:37 pppd[44]: local IP address 192.168.5.1
    <29>Nov 30 00:03:37 pppd[44]: remote IP address 192.168.5.2
    <31>Nov 30 00:03:40 pppd[44]: sent [CCP ConfReq id=0x1]
    <31>Nov 30 00:03:50 last message repeated 3 time(s)
    <


  2. Re: asyncmap and windows

    "warren" writes:

    >Greetings.


    >I am trying to get a 3-wire modem to work with mgetty to answer inbound


    Why?

    >calls. The client is WinXP and uses a complete modem cable. XP dials
    >and mgetty answers. The link is authenticated. I can ping the mgetty
    >system. The mgetty system also has a web server. The server delivers
    >text correctly. Images are not delivered. An SSL connection does not
    >work at all. All these work over a lan, only fail with the modem
    >connection.


    >As the server uses a 3-wire modem, asyncmap 0xa0000 and xonxoff is
    >used. The mgetty ppp options are:


    Use a 5 wire modem!


    >auth -chap +pap 192.168.5.1:192.168.5.2 xonxoff asyncmap 0xa0000 57600
    >debug


    >I suspect the issue is to do with the asyncmap and the escaped chars. I
    >posted a message a few weeks back where the 3-wire modem was the client
    >and the communication problems occured unless the asyncmaps of both
    >linux boxes matched. I was informed that linux did not re-negotiate
    >asyncmap and the only solution was to have matching asyncmaps. The post
    >can be found at:
    >http://groups.google.co.za/group/com...1bf4dd74b0d93b


    >I can not find an option in XP allowing for a manual asyncmap value. In
    >fact I found the following bit of text at:
    >http://www.microsoft.com/windows2000...ncepts_114.htm
    >"Software flow control is used only for transmitting text. It cannot be
    >used for binary file transfer because binary data may contain the
    >special flow control characters."


    Well, that sucks. If it cannot, it cannot. Certainly your negotiation
    below, the windows side does NOT escape xonxoff. It uses asyncmap 0.
    And if it cannot then you are screwed.
    Get something that will do hardware flow control.
    But I am certainly confused when you talk about "modems" Do you really have
    modems? why don't you get a modem that does hardware flow control?




    >This implies there is no support for manually setting asyncmaps. And
    >describes the problem: only text is correctly carried on the link.


    >I am guessing that the server is escaping 2 chars which are not escaped
    >on the client. These chars are not used in text and there text works
    >fine, but are found in other files and therefore cause a problem. I
    >feel that if I could get the client to escape these two chars perhaps
    >things would work. I have tried all compression and flow-control
    >options on the client (XP) without any change. Server side logs can be
    >found at the end of the message.


    >Is this the same issue as my previous post where the linux system does
    >not do what is required for a successful asyncmap negotation? Is there


    The linux side is fine. YOu need a certain capability. Windows refuses to
    give it to you . What has this to do with Linux?


    >a way to set the asyncmap manually on the XP side? Is there any
    >solution? There must be a solution. Any help would be very much


    Why must there be a solution? Rewrite the Windows operating system For a
    price, MS will sell you access to their source code. ( 10000 dollars or so)
    with a non-disclosure agreement. So that is a solution.

    Or buy a better modem.


    >appreciated.


    >Regards


    >Log files from the mgetty 'server':
    ><29>Nov 30 00:03:34 pppd[44]: pppd 2.3.8 started by (unknown), uid 0


    Nov 30? Has this post come from some sort of time warp?


    ><31>Nov 30 00:03:34 pppd[44]: using channel 1
    ><30>Nov 30 00:03:34 pppd[44]: Using interface ppp0
    ><29>Nov 30 00:03:34 pppd[44]: pppd create pidfile
    ><29>Nov 30 00:03:34 pppd[44]: Connect: ppp0 <--> /dev/ttyS1
    ><28>Nov 30 00:03:34 pppd[44]: Will not do PAP for user
    ><28>Nov 30 00:03:34 pppd[44]: Will not do CHAP for user


    What version of pppd do you have? These extra messages I do not recognize.

    ><31>Nov 30 00:03:34 pppd[44]: sent [LCP ConfReq id=0x1 >0xa0000> ]


    Linux says use 0xa0000 and the Windows side accepts.

    ><31>Nov 30 00:03:34 pppd[44]: rcvd [LCP ConfAck id=0x1 >0xa0000> ]
    ><31>Nov 30 00:03:36 pppd[44]: rcvd [LCP ConfReq id=0x2
    > < 0d 03 06>]
    ><31>Nov 30 00:03:36 pppd[44]: lcp_reqci: rcvd unknown option 13
    ><31>Nov 30 00:03:36 pppd[44]: lcp_reqci: returning CONFREJ.
    ><31>Nov 30 00:03:36 pppd[44]: sent [LCP ConfRej id=0x2 < 0d 03 06>]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [LCP ConfReq id=0x3
    > ]


    They ask for asyncmap 0
    There is no way for them to do flow control.

    ><31>Nov 30 00:03:37 pppd[44]: lcp_reqci: returning CONFACK.
    ><31>Nov 30 00:03:37 pppd[44]: sent [LCP ConfAck id=0x3
    > ]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [LCP code=0xc id=0x4 4b b4 67 66 4d
    >53 52 41 53 56 35 2e 32 30]
    ><31>Nov 30 00:03:37 pppd[44]: sent [LCP CodeRej id=0x2 0c 04 00 12 4b
    >b4 67 66 4d 53 52 41 53 56 35 2e 32 30]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [LCP code=0xc id=0x5 4b b4 67 66 4d
    >53 52 41 53 2d 30 2d 57 41 52 52 45 4e]
    ><31>Nov 30 00:03:37 pppd[44]: sent [LCP CodeRej id=0x3 0c 05 00 16 4b
    >b4 67 66 4d 53 52 41 53 2d 30 2d 57 41 52 52 45 4e]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [PAP AuthReq id=0x1f
    >user="dialinuser" password="****"]
    ><31>Nov 30 00:03:37 pppd[44]: sent [PAP AuthAck id=0x1f "Login ok"]
    ><31>Nov 30 00:03:37 pppd[44]: sent [IPCP ConfReq id=0x1 >192.168.5.1> ]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [CCP ConfReq id=0x6 < 12 06 00 00 00
    >01>]


    Put in noccp on the linux side.


    ><31>Nov 30 00:03:37 pppd[44]: sent [CCP ConfReq id=0x1]
    ><31>Nov 30 00:03:37 pppd[44]: sent [CCP ConfRej id=0x6 < 12 06 00 00 00
    >01>]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [IPCP ConfReq id=0x7 >01> ><31>Nov 30 00:03:37 pppd[44]: sent [IPCP ConfRej id=0x7 >0.0.0.0> ]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [IPCP ConfAck id=0x1 >192.168.5.1> ]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [CCP TermReq
    >id=0x8"K\37777777664gf\000<\37777777715t\000\000\002\37777777734"]
    ><31>Nov 30 00:03:37 pppd[44]: sent [CCP TermAck id=0x8]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [IPCP ConfReq id=0x9 >01> ]
    ><31>Nov 30 00:03:37 pppd[44]: sent [IPCP ConfNak id=0x9 >192.168.5.2>]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [IPCP ConfReq id=0xa >01> ]
    ><31>Nov 30 00:03:37 pppd[44]: sent [IPCP ConfAck id=0xa >01> ]
    ><29>Nov 30 00:03:37 pppd[44]: local IP address 192.168.5.1
    ><29>Nov 30 00:03:37 pppd[44]: remote IP address 192.168.5.2
    ><31>Nov 30 00:03:40 pppd[44]: sent [CCP ConfReq id=0x1]
    ><31>Nov 30 00:03:50 last message repeated 3 time(s)
    ><



  3. Re: asyncmap and windows

    The modem is attached to an embedded device. The device has 3 wire
    serial ports. Additional electronic components to offer the 5 wire
    solution is undesirable. The device is running uClinux. The version of
    pppd is reported as 2.3.8. I know this is not the newest but programs
    have to be ported to uclinux, which is why it is behind.

    To test the idea that windows would not work with an asyncmap of
    anything by 0, I changed the pppd config on a portslave box (full
    linux, not uclinux) to 0xa0000. The same XP client was used. Here are
    the logs from the portslave server (uses pppd version 2.4.1):

    May 9 10:41:33 nas1 port[S0]: Using interface ppp0
    May 9 10:41:33 nas1 port[S0]: Connect: ppp0 <--> /dev/ttyX0
    May 9 10:41:33 nas1 port[S0]: sent [LCP ConfReq id=0x1 0xa0000> ]
    May 9 10:41:33 nas1 port[S0]: rcvd [LCP ConfAck id=0x1 0xa0000> ]
    May 9 10:41:36 nas1 port[S0]: rcvd [LCP ConfReq id=0x2
    ]
    May 9 10:41:36 nas1 port[S0]: sent [LCP ConfRej id=0x2 CBCP>]
    May 9 10:41:36 nas1 port[S0]: sent [LCP ConfReq id=0x1 0xa0000> ]
    May 9 10:41:36 nas1 port[S0]: rcvd [LCP ConfReq id=0x3
    ]
    May 9 10:41:36 nas1 port[S0]: sent [LCP ConfAck id=0x3
    ]
    May 9 10:41:36 nas1 port[S0]: rcvd [LCP ConfAck id=0x1 0xa0000> ]
    May 9 10:41:36 nas1 port[S0]: rcvd [LCP code=0xc id=0x4 08 6e 0b f7 4d
    53 52 41 53 56 35 2e 32 30]
    May 9 10:41:36 nas1 port[S0]: sent [LCP CodeRej id=0x2 0c 04 00 12 08
    6e 0b f7 4d 53 52 41 53 56 35 2e 32 30]
    May 9 10:41:36 nas1 port[S0]: rcvd [LCP code=0xc id=0x5 08 6e 0b f7 4d
    53 52 41 53 2d 30 2d 57 41 52 52 45 4e]
    May 9 10:41:36 nas1 port[S0]: sent [LCP CodeRej id=0x3 0c 05 00 16 08
    6e 0b f7 4d 53 52 41 53 2d 30 2d 57 41 52 52 45 4e]
    May 9 10:41:36 nas1 port[S0]: rcvd [PAP AuthReq id=0x26
    user="someuser" password=]
    May 9 10:41:36 nas1 port[S0]: user someuser logged in

    My understanding of the LCP protocol is limited but the last line in
    the asnyc negotiation seems to show that asyncmap 0xa0000 was agreed
    upon.

    Here are (once again, for conveniance) the logs from the mgetty
    embedded device that is presenting the problem:
    <31>Nov 30 00:03:34 pppd[44]: sent [LCP ConfReq id=0x1 0xa0000> ]
    <31>Nov 30 00:03:34 pppd[44]: rcvd [LCP ConfAck id=0x1 0xa0000> ]
    <31>Nov 30 00:03:36 pppd[44]: rcvd [LCP ConfReq id=0x2
    < 0d 03 06>]
    <31>Nov 30 00:03:36 pppd[44]: lcp_reqci: rcvd unknown option 13 <31>Nov
    30 00:03:36 pppd[44]: lcp_reqci: returning CONFREJ.
    <31>Nov 30 00:03:36 pppd[44]: sent [LCP ConfRej id=0x2 < 0d 03 06>]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [LCP ConfReq id=0x3
    ]
    <31>Nov 30 00:03:37 pppd[44]: lcp_reqci: returning CONFACK.
    <31>Nov 30 00:03:37 pppd[44]: sent [LCP ConfAck id=0x3
    ]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [LCP code=0xc id=0x4 4b b4 67 66 4d
    53 52 41 53 56 35 2e 32 30]
    <31>Nov 30 00:03:37 pppd[44]: sent [LCP CodeRej id=0x2 0c 04 00 12 4b
    b4 67 66 4d 53 52 41 53 56 35 2e 32 30]
    <31>Nov 30 00:03:37 pppd[44]: rcvd [LCP code=0xc id=0x5 4b b4 67 66 4d
    53 52 41 53 2d 30 2d 57 41 52 52 45 4e]
    <31>Nov 30 00:03:37 pppd[44]: sent [LCP CodeRej id=0x3 0c 05 00 16 4b
    b4 67 66 4d 53 52 41 53 2d 30 2d 57 41 52 52 45 4e]

    Here the last asyncmap is 0.

    Am I reading this correctly, is the newer pppd managing to get windows
    to agree upon asyncmap of 0xa0000? If so would it mean that the newer
    pppd is required for this to work or could it be the kernel or
    something else?

    Thanks.


  4. Re: asyncmap and windows

    "warren" writes:

    >The modem is attached to an embedded device. The device has 3 wire
    >serial ports. Additional electronic components to offer the 5 wire
    >solution is undesirable. The device is running uClinux. The version of
    >pppd is reported as 2.3.8. I know this is not the newest but programs
    >have to be ported to uclinux, which is why it is behind.


    >To test the idea that windows would not work with an asyncmap of
    >anything by 0, I changed the pppd config on a portslave box (full
    >linux, not uclinux) to 0xa0000. The same XP client was used. Here are
    >the logs from the portslave server (uses pppd version 2.4.1):


    >May 9 10:41:33 nas1 port[S0]: Using interface ppp0
    >May 9 10:41:33 nas1 port[S0]: Connect: ppp0 <--> /dev/ttyX0
    >May 9 10:41:33 nas1 port[S0]: sent [LCP ConfReq id=0x1 >0xa0000> ]


    You ask for asyncmap a0000 (Ie, that they escape all characters xon/xoff)

    >May 9 10:41:33 nas1 port[S0]: rcvd [LCP ConfAck id=0x1 >0xa0000> ]


    They agree to escape all such characters to you.

    >May 9 10:41:36 nas1 port[S0]: rcvd [LCP ConfReq id=0x2
    > ]


    They ask for asyncmap a0000 for themselves (Ie, that you do not escape
    those characters.)


    >May 9 10:41:36 nas1 port[S0]: sent [LCP ConfRej id=0x2 >CBCP>]
    >May 9 10:41:36 nas1 port[S0]: sent [LCP ConfReq id=0x1 >0xa0000> ]
    >May 9 10:41:36 nas1 port[S0]: rcvd [LCP ConfReq id=0x3
    > ]


    They ask again.



    >May 9 10:41:36 nas1 port[S0]: sent [LCP ConfAck id=0x3
    > ]


    You agree.

    To tell your system that it must escape those characters, use the
    escape option to pppd

    Whether or not the Windows machine will honour those escapes and translate
    them correctly I do not know.


    man pppd



    >May 9 10:41:36 nas1 port[S0]: rcvd [LCP ConfAck id=0x1 >0xa0000> ]
    >May 9 10:41:36 nas1 port[S0]: rcvd [LCP code=0xc id=0x4 08 6e 0b f7 4d
    >53 52 41 53 56 35 2e 32 30]
    >May 9 10:41:36 nas1 port[S0]: sent [LCP CodeRej id=0x2 0c 04 00 12 08
    >6e 0b f7 4d 53 52 41 53 56 35 2e 32 30]
    >May 9 10:41:36 nas1 port[S0]: rcvd [LCP code=0xc id=0x5 08 6e 0b f7 4d
    >53 52 41 53 2d 30 2d 57 41 52 52 45 4e]
    >May 9 10:41:36 nas1 port[S0]: sent [LCP CodeRej id=0x3 0c 05 00 16 08
    >6e 0b f7 4d 53 52 41 53 2d 30 2d 57 41 52 52 45 4e]
    >May 9 10:41:36 nas1 port[S0]: rcvd [PAP AuthReq id=0x26
    >user="someuser" password=]
    >May 9 10:41:36 nas1 port[S0]: user someuser logged in


    >My understanding of the LCP protocol is limited but the last line in
    >the asnyc negotiation seems to show that asyncmap 0xa0000 was agreed
    >upon.


    Nope. They agreed to escape those characters to you. You agreed not to to
    them.
    They requested and you
    agreed that they could use asyncmap 0



    >Here are (once again, for conveniance) the logs from the mgetty
    >embedded device that is presenting the problem:


    The embedded device is NOT the problem. the problem is your windows
    machine. You need to persuade it to use a0000.


    ><31>Nov 30 00:03:34 pppd[44]: sent [LCP ConfReq id=0x1 >0xa0000> ]
    ><31>Nov 30 00:03:34 pppd[44]: rcvd [LCP ConfAck id=0x1 >0xa0000> ]
    ><31>Nov 30 00:03:36 pppd[44]: rcvd [LCP ConfReq id=0x2
    > < 0d 03 06>]
    ><31>Nov 30 00:03:36 pppd[44]: lcp_reqci: rcvd unknown option 13 <31>Nov
    >30 00:03:36 pppd[44]: lcp_reqci: returning CONFREJ.
    ><31>Nov 30 00:03:36 pppd[44]: sent [LCP ConfRej id=0x2 < 0d 03 06>]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [LCP ConfReq id=0x3
    > ]
    ><31>Nov 30 00:03:37 pppd[44]: lcp_reqci: returning CONFACK.
    ><31>Nov 30 00:03:37 pppd[44]: sent [LCP ConfAck id=0x3
    > ]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [LCP code=0xc id=0x4 4b b4 67 66 4d
    >53 52 41 53 56 35 2e 32 30]
    ><31>Nov 30 00:03:37 pppd[44]: sent [LCP CodeRej id=0x2 0c 04 00 12 4b
    >b4 67 66 4d 53 52 41 53 56 35 2e 32 30]
    ><31>Nov 30 00:03:37 pppd[44]: rcvd [LCP code=0xc id=0x5 4b b4 67 66 4d
    >53 52 41 53 2d 30 2d 57 41 52 52 45 4e]
    ><31>Nov 30 00:03:37 pppd[44]: sent [LCP CodeRej id=0x3 0c 05 00 16 4b
    >b4 67 66 4d 53 52 41 53 2d 30 2d 57 41 52 52 45 4e]


    >Here the last asyncmap is 0.


    >Am I reading this correctly, is the newer pppd managing to get windows
    >to agree upon asyncmap of 0xa0000? If so would it mean that the newer
    >pppd is required for this to work or could it be the kernel or
    >something else?






    >Thanks.



  5. Re: asyncmap and windows

    "warren" writes:
    > May 9 10:41:36 nas1 port[S0]: sent [LCP ConfAck id=0x3
    > ]
    > May 9 10:41:36 nas1 port[S0]: rcvd [LCP ConfAck id=0x1 > 0xa0000> ]

    [...]
    > My understanding of the LCP protocol is limited but the last line in
    > the asnyc negotiation seems to show that asyncmap 0xa0000 was agreed
    > upon.


    Not precisely, because LCP is symmetric. The above shows an ACCM of 0
    in the outbound direction (from you to the peer) and an ACCM of
    0xa0000 in the inbound direction.

    This means that you are not obligated to escape any of the characters
    in the range 00 to 1F hex when you transmit, but that the peer is
    obligated to escape _at least_ 11 and 13 when sending data back to
    you.

    Not every implementation gets this right, so the above configuration
    is (unfortunately) risky.

    > Here the last asyncmap is 0.


    The "last" one is irrelevant. The two directions are independent.

    > Am I reading this correctly, is the newer pppd managing to get windows
    > to agree upon asyncmap of 0xa0000? If so would it mean that the newer
    > pppd is required for this to work or could it be the kernel or
    > something else?


    No, you're misreading the logs.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

+ Reply to Thread