Async-Control-Character-Map (ACCM) ...
Jens Kristensen
Hi All ...
I'm Jens Kristensen from Denmark. Please excuse my english ...
I'm writing a PPP-module for my Borland Pascal 7.0 program, and I have a
question about ACCM.
I thought I knew how it works, but then I read in an RFC that there can be a
reciever and sender ACCM in both end of the link = 4 different ACCM's. As
far as I can see Sender and Reciever should just have the same ACCM and it
would work fine.
Why can there be 4 diffent maps ?
Why is it nesessary ?
As far as I know, there is one one ACCM-configure-request send while
negotiating the PPP-link. How does it configure 4 then ?
I DON'T GET IT !!!
Pleeeeaassse enlighten me .... ("enlighten" must be spelled wrong :-))
Jens Kristensen
Denmark
John RM
Jens Kristensen wrote in message <65psri$db9$1...@dalen.get2net.dk>...
>Why can there be 4 diffent maps ?
>Why is it nesessary ?
Octet stuffing character escaping usually is NOT necessay these days.
However, implementation of the ACCM is a required part of the RFC. You'll
find though that a lot of implementations don't do ACCM literally as
specified in the RFC. <sigh>
>As far as I know, there is one one ACCM-configure-request send while
>negotiating the PPP-link. How does it configure 4 then ?
I believe the four possible mappings referred to are:
receive negotiated: 0x00 to 0x1F
receive implicit: 0x20 to 0xFF
transmit negotiated: 0x00 to 0x1F
transmit implicit: 0x20 to 0xFF
The ACCM that is negotiated during LCP via the ACCM configuration option
only covers bytes in the range 0x00 to 0x1F. It is frequently negotiated to
0x00000000 i.e. none of the control characters are escaped. The escaping of
characters from 0x20 to 0xFF is not negotiated. However some characters such
as 0x7E still need to be escaped.
The receive ACCM does NOT have to match the transmit ACCM. In most cases it
will, but there is nothing that I recall in the RFC that requires this. If
the peer wants you to escape some of the control characters that you send to
it, it certainly can ask you to do this and expect that you will do it.
A typical non-standard implementation hack (Win95 has it. The Linux code did
too, unless this has been changed) is to set the transmit ACCM to the
default of 0xFFFFFFFF but the receive ACCM to 0x00000000 in any state other
than LCP Open. All the control characters in packets sent to the remote peer
are escaped. However, characters will be recognized in packets received
whether they are escaped or not escaped. (If the receive ACCM was
0xFFFFFFFF then all characters in the range 0x00 to 0x20 that were NOT
escaped are supposed to discarded).
This is non-standard and NOT a correct (literal) implementation. However,
code that behaves that way is out there and we have to live with it. It's
unlikely that MicroSoft is going to change their implementation to get in
line with the RFC at this date. :-(
-john martz, Ithaca, NY