RS-232C通信 > PPPプロトコル(RFC 1662) > 0x20でXORを取る

この中で、PPPプロトコル(RFC 1662)が紹介されている。

In particular, PPP does the following:

  • Both the start and end flag bytes are 0x7E (they shouldn't really be different, if you think about it)
  • The escape byte is 0x7D
  • Whenever a flag or escape byte appears in the message, it is escaped by 0x7D and the byte itself is XOR-ed with 0x20. So, for example 0x7E becomes 0x7D 0x5E. Similarly 0x7D becomes 0x7D 0x5D. The receiver unsuffs the escape byte and XORs the next byte with 0x20 again to get the original [6].


0x7E(start and end flags bytes)や0x7D(escape byte)とかぶらないようにしているのだろうか。

例として、通信経路上で0x7D(escape byte)が別のコードに文字化けした場合、その次のコードが0x7D(データ)である場合を考える。その場合、escape byteと勘違いして「次のコード」を処理しようとする。0x20でXORしていれば、0x7D(データ)は0x5Dになっているため、「次のコード」を処理しようとはしない、という考えだろうか。


4.2. Transparency

On reception, prior to FCS computation, each octet with value less than hexadecimal 0x20 is checked. If it is flagged in the receiving ACCM, it is simply removed (it may have been inserted by intervening data communications equipment). Each Control Escape octet is also removed, and the following octet is exclusive-or'd with hexadecimal 0x20, unless it is the Flag Sequence (which aborts a frame).


0x20    0x21    0x22    0x23    0x24    0x25    0x26    0x27    0x28    0x29    0x2a    0x2b    0x2c    0x2d    0x2e    0x2f    0x30    0x31    0x32    0x33    0x34    0x35    0x36    0x37    0x38    0x39    0x3a    0x3b    0x3c    0x3d    0x3e    0x3f

! " # $ (中略) 9 : ; < = > ? 


Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.