Discussion:
asyncmap negotations
(too old to reply)
warren
2006-04-06 08:33:51 UTC
Permalink
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 <asyncmap
0xa0000> <magic 0xe57ff176> <pcomp> <accomp>]
Apr 6 10:16:14 uClinux pppd[1467]: rcvd [LCP ConfReq id=0x1 <asyncmap
0x0> <auth pap> <magic 0x481ccf7a> <pcomp> <accomp>]
Apr 6 10:16:14 uClinux pppd[1467]: sent [LCP ConfAck id=0x1 <asyncmap
0x0> <auth pap> <magic 0x481ccf7a> <pcomp> <accomp>]
Apr 6 10:16:17 uClinux pppd[1467]: sent [LCP ConfReq id=0x1 <asyncmap
0xa0000> <magic 0xe57ff176> <pcomp> <accomp>]
Apr 6 10:16:17 uClinux pppd[1467]: rcvd [LCP ConfAck id=0x1 <asyncmap
0xa0000> <magic 0xe57ff176> <pcomp> <accomp>]
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=<hidden>]
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 <addr
0.0.0.0> <compress VJ 0f 01>]
Apr 6 10:16:17 uClinux pppd[1467]: sent [CCP ConfReq id=0x1 <deflate
15> <deflate(old#) 15> <bsd v1 15>]
Apr 6 10:16:17 uClinux pppd[1467]: rcvd [IPCP ConfReq id=0x1 <compress
VJ 0f 01> <addr a.b.c.11>]
Apr 6 10:16:17 uClinux pppd[1467]: sent [IPCP ConfAck id=0x1 <compress
VJ 0f 01> <addr a.b.c.11>]
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 <addr
a.b.c.49>]
Apr 6 10:16:17 uClinux pppd[1467]: sent [IPCP ConfReq id=0x2 <addr
a.b.c.49> <compress VJ 0f 01>]
Apr 6 10:16:17 uClinux pppd[1467]: rcvd [IPCP ConfAck id=0x2 <addr
a.b.c.49> <compress VJ 0f 01>]
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 <asyncmap 0x0>
<auth pap> <magic 0x481ccf7a> <pcomp> <accomp>]
Apr 6 10:20:37 nas2 port[S0]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0>
<auth pap> <magic 0x481ccf7a> <pcomp> <accomp>]
Apr 6 10:20:40 nas2 port[S0]: rcvd [LCP ConfReq id=0x1 <asyncmap
0xa0000> <magic 0xe57ff176> <pcomp> <accomp>]
Apr 6 10:20:40 nas2 port[S0]: sent [LCP ConfAck id=0x1 <asyncmap
0xa0000> <magic 0xe57ff176> <pcomp> <accomp>]
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=<hidden>]
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 <compress VJ
0f 01> <addr a.b.c.11>]
Apr 6 10:20:40 nas2 port[S0]: rcvd [IPCP ConfReq id=0x1 <addr 0.0.0.0>
<compress VJ 0f 01>]
Apr 6 10:20:40 nas2 port[S0]: sent [IPCP ConfNak id=0x1 <addr
a.b.c.49>]
Apr 6 10:20:40 nas2 port[S0]: rcvd [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15> <bsd v1 15>]
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 <compress VJ
0f 01> <addr a.b.c.11>]
Apr 6 10:20:40 nas2 port[S0]: rcvd [IPCP ConfReq id=0x2 <addr
a.b.c.49> <compress VJ 0f 01>]
Apr 6 10:20:40 nas2 port[S0]: sent [IPCP ConfAck id=0x2 <addr
a.b.c.49> <compress VJ 0f 01>]
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
Patrick Klos
2006-04-06 12:40:37 UTC
Permalink
Post by warren
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?
Post by warren
-------------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: ***@klos.com
Klos Technologies, Inc. Web: http://www.klos.com/
==================== http://www.loving-long-island.com/ ====================
James Carlson
2006-04-06 13:18:38 UTC
Permalink
Post by warren
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.
Post by warren
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.com>
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
Loading...