asyncmap negotations - PPP

This is a discussion on asyncmap negotations - PPP ; Greetings I have a problem with the asyncmap negotations. The client is a 3 wire analog modem and must use xonxoff and asyncmap 0xa0000. The server uses a full serial cable and up to now has worked well with asyncmap ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: asyncmap negotations

  1. asyncmap negotations

    Greetings

    I have a problem with the asyncmap negotations. The client is a 3 wire
    analog modem and must use xonxoff and asyncmap 0xa0000. The server uses
    a full serial cable and up to now has worked well with asyncmap 0. But
    the 3 wire modem will not talk to the server unless the asyncmap is
    changed to 0xa0000 as well. I am under the impression that async map is
    negotiated between the client and server. And in my mind the resulting
    async should surely include both server and clients required escape
    chars. This does not seem to be happening.

    The logs below have the client async set to 0xa0000 and the server to
    0. Once the connection is established no data is received by the client
    from the server. The server is using portslave, the client pppd.

    -------------The client logs------------
    Apr 6 10:16:13 uClinux pppd[1467]: Serial connection established.
    Apr 6 10:16:13 uClinux pppd[1467]: using channel 17
    Apr 6 10:16:13 uClinux pppd[1467]: Using interface ppp0
    Apr 6 10:16:13 uClinux pppd[1467]: Connect: ppp0 <--> /dev/ttyS1
    Apr 6 10:16:14 uClinux pppd[1467]: sent [LCP ConfReq id=0x1 0xa0000> ]
    Apr 6 10:16:14 uClinux pppd[1467]: rcvd [LCP ConfReq id=0x1 0x0> ]
    Apr 6 10:16:14 uClinux pppd[1467]: sent [LCP ConfAck id=0x1 0x0> ]
    Apr 6 10:16:17 uClinux pppd[1467]: sent [LCP ConfReq id=0x1 0xa0000> ]
    Apr 6 10:16:17 uClinux pppd[1467]: rcvd [LCP ConfAck id=0x1 0xa0000> ]
    Apr 6 10:16:17 uClinux pppd[1467]: sent [LCP EchoReq id=0x0
    magic=0xe57ff176]
    Apr 6 10:16:17 uClinux pppd[1467]: sent [PAP AuthReq id=0x1
    user="someuser" password=]
    Apr 6 10:16:17 uClinux pppd[1467]: rcvd [LCP EchoRep id=0x0
    magic=0x481ccf7a]
    Apr 6 10:16:17 uClinux pppd[1467]: rcvd [PAP AuthAck id=0x1 ""]
    Apr 6 10:16:17 uClinux pppd[1467]: kernel does not support PPP
    filtering
    Apr 6 10:16:17 uClinux pppd[1467]: sent [IPCP ConfReq id=0x1 0.0.0.0> ]
    Apr 6 10:16:17 uClinux pppd[1467]: sent [CCP ConfReq id=0x1 15> ]
    Apr 6 10:16:17 uClinux pppd[1467]: rcvd [IPCP ConfReq id=0x1 VJ 0f 01> ]
    Apr 6 10:16:17 uClinux pppd[1467]: sent [IPCP ConfAck id=0x1 VJ 0f 01> ]
    Apr 6 10:16:17 uClinux pppd[1467]: rcvd [LCP ProtRej id=0x2 80 fd 01
    01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
    Apr 6 10:16:17 uClinux pppd[1467]: rcvd [IPCP ConfNak id=0x1 a.b.c.49>]
    Apr 6 10:16:17 uClinux pppd[1467]: sent [IPCP ConfReq id=0x2 a.b.c.49> ]
    Apr 6 10:16:17 uClinux pppd[1467]: rcvd [IPCP ConfAck id=0x2 a.b.c.49> ]
    Apr 6 10:16:17 uClinux pppd[1467]: not replacing existing default
    route to eth0 [192.168.100.254]
    Apr 6 10:16:17 uClinux pppd[1467]: local IP address a.b.c.49
    Apr 6 10:16:17 uClinux pppd[1467]: remote IP address a.b.c.11

    -----------The Server logs------------
    Apr 6 10:20:36 nas2 port[S0]: Connected - waiting for login
    Apr 6 10:20:37 nas2 port[S0]: PPP frames detected - switching to PPP
    mode
    Apr 6 10:20:37 nas2 pppd[5713]: Plugin /usr/lib/libpsr.so loaded.
    Apr 6 10:20:37 nas2 port[S0]: pppd 2.4.3 started by AutoPPP, uid 0
    Apr 6 10:20:37 nas2 port[S0]: using channel 26
    Apr 6 10:20:37 nas2 port[S0]: Using interface ppp0
    Apr 6 10:20:37 nas2 port[S0]: Connect: ppp0 <--> /dev/ttyS2
    Apr 6 10:20:37 nas2 port[S0]: sent [LCP ConfReq id=0x1
    ]
    Apr 6 10:20:37 nas2 port[S0]: rcvd [LCP ConfAck id=0x1
    ]
    Apr 6 10:20:40 nas2 port[S0]: rcvd [LCP ConfReq id=0x1 0xa0000> ]
    Apr 6 10:20:40 nas2 port[S0]: sent [LCP ConfAck id=0x1 0xa0000> ]
    Apr 6 10:20:40 nas2 port[S0]: rcvd [LCP EchoReq id=0x0
    magic=0xe57ff176]
    Apr 6 10:20:40 nas2 port[S0]: sent [LCP EchoRep id=0x0
    magic=0x481ccf7a]
    Apr 6 10:20:40 nas2 port[S0]: rcvd [PAP AuthReq id=0x1 user="someuser"
    password=]
    Apr 6 10:20:40 nas2 port[S0]: user someuser logged in
    Apr 6 10:20:40 nas2 port[S0]: sent [PAP AuthAck id=0x1 ""]
    Apr 6 10:20:40 nas2 port[S0]: PAP peer authentication succeeded for
    someuser
    Apr 6 10:20:40 nas2 port[S0]: sent [IPCP ConfReq id=0x1 0f 01> ]
    Apr 6 10:20:40 nas2 port[S0]: rcvd [IPCP ConfReq id=0x1
    ]
    Apr 6 10:20:40 nas2 port[S0]: sent [IPCP ConfNak id=0x1 a.b.c.49>]
    Apr 6 10:20:40 nas2 port[S0]: rcvd [CCP ConfReq id=0x1
    ]
    Apr 6 10:20:40 nas2 port[S0]: Unsupported protocol 'Compression
    Control Protocol' (0x80fd) received
    Apr 6 10:20:40 nas2 port[S0]: sent [LCP ProtRej id=0x2 80 fd 01 01 00
    0f 1a 04 78 00 18 04 78 00 15 03 2f]
    Apr 6 10:20:40 nas2 port[S0]: rcvd [IPCP ConfAck id=0x1 0f 01> ]
    Apr 6 10:20:40 nas2 port[S0]: rcvd [IPCP ConfReq id=0x2 a.b.c.49> ]
    Apr 6 10:20:40 nas2 port[S0]: sent [IPCP ConfAck id=0x2 a.b.c.49> ]
    Apr 6 10:20:40 nas2 port[S0]: Cannot determine ethernet address for
    proxy ARP
    Apr 6 10:20:40 nas2 port[S0]: local IP address a.b.c.11
    Apr 6 10:20:40 nas2 port[S0]: remote IP address a.b.c.49
    Apr 6 10:20:40 nas2 port[S0]: Starting filters: 1.

    I do not want to permamently change the server to asyncmap 0xa0000. Can
    anyone suggest a solution?

    Regards


  2. Re: asyncmap negotations

    In article <1144312431.836442.263320@g10g2000cwb.googlegroups. com>,
    warren wrote:
    >Greetings
    >
    >I have a problem with the asyncmap negotations. The client is a 3 wire
    >analog modem and must use xonxoff and asyncmap 0xa0000. The server uses
    >a full serial cable and up to now has worked well with asyncmap 0. But
    >the 3 wire modem will not talk to the server unless the asyncmap is
    >changed to 0xa0000 as well. I am under the impression that async map is
    >negotiated between the client and server. And in my mind the resulting
    >async should surely include both server and clients required escape
    >chars. This does not seem to be happening.
    >
    >The logs below have the client async set to 0xa0000 and the server to
    >0. Once the connection is established no data is received by the client
    >from the server. The server is using portslave, the client pppd.


    The fact that you get beyond LCP negotiations usually means that ACCM
    processing is working fine. These two systems successfully negotiated
    IPCP and got IP addresses for both ends of the link. It would appear
    more likely to be a routing (or filtering?) problem unless one of these
    implementations of PPP is broken?

    >-------------The client logs------------
    > : : :
    > : : :
    >Apr 6 10:16:17 uClinux pppd[1467]: not replacing existing default
    >route to eth0 [192.168.100.254]
    >Apr 6 10:16:17 uClinux pppd[1467]: local IP address a.b.c.49
    >Apr 6 10:16:17 uClinux pppd[1467]: remote IP address a.b.c.11
    >
    >-----------The Server logs------------
    > : : :
    > : : :
    >Apr 6 10:20:40 nas2 port[S0]: local IP address a.b.c.11
    >Apr 6 10:20:40 nas2 port[S0]: remote IP address a.b.c.49
    >Apr 6 10:20:40 nas2 port[S0]: Starting filters: 1.
    >
    >I do not want to permamently change the server to asyncmap 0xa0000. Can
    >anyone suggest a solution?


    Does changing JUST the ACCM on the server to 0xa0000 really make this
    connection work? I'd be surprised, but stranger things have happened.

    And if it does, what would be the harm of leaving it that way?

    Can you get a raw dump of bytes between the two systems up to when the
    communications stop? That may help show if an XOFF is actually getting into
    the stream and the possible cause of the trouble?

    Patrick
    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==================== http://www.loving-long-island.com/ ====================

  3. Re: asyncmap negotations

    "warren" writes:
    > The logs below have the client async set to 0xa0000 and the server to
    > 0. Once the connection is established no data is received by the client
    > from the server. The server is using portslave, the client pppd.


    There's a feature in Sun's variant of pppd that renegotiates the ACCM
    in the opposite direction when this happens to avoid exactly this
    problem.

    Until I can get around to porting that back (sigh), you might use just
    "default-asyncmap" to force ACCM negotiation off and escaping of
    everything.

    > I do not want to permamently change the server to asyncmap 0xa0000. Can
    > anyone suggest a solution?


    Why not change the server? It's not as if adding two escaped
    characters is a noticable amount of overhead.

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