最終目標はMochaPPPです。
ネットワークに接続できるＰＣにＨＯＴＳＹＮＣケーブルでＰａｌｍをつないで、Ｐａｌｍからネットワークに接続できるようにするＰＣ用ソフトです。
ＰＣ側で必要な処理はPalmからのＰＰＰパケットの分解。そしてそのパケットをＰＣが接続しているネットワークへ送り出さなければなりません。逆にネットワークからＰａｌｍへのパケットをＰＰＰパケットに包みなおすことも必要です。
まずＰＰＰアクセスのラッパクラスを製作することにします。
この時点での疑問は
です。
ＰＰＰについてのＲＦＣを読むと、パケットの詳細などがかかれているもののピンと来ません。そこで実際にＰａｌｍから送信されるパケットを見てみることにしました。
| ~ }#ﾀ!}!F} }.}"}&} } } } }'}"}(}"bO~~ }#ﾀ!}!G} }.}"}&} }
} } }'}"}(}"ﾏJ~~ }#ﾀ!}! H} }.}"}&} } } } }'}"}(}"・~~ }#ﾀ!}!I} }.}"}&} } } } }'}"}(}"Iz~~ }#ﾀ!}!J} }.}"} &} } } } }'}"}(}"ｾt~~ }#ﾀ!}!K} }.}"}&} } } } }'}"}(}"}3q~~ }#ﾀ!}!L} }.}"}&} } } } }'}"}(}"Pi~~ }#ﾀ!}!M} }.}"}&} } } } }'}"}(}"l~ |
予想通り人間には読めないものの、先頭の「~」が0x7eでありフラグシーケンスと確認できたのでＯＫ。
つづいて、COMポートから受信した文字を表示するコマンドを製作し、上記と同じものを記録してみました。
ff 7e ff 7d 23 c0 21 7d 21 39 7d 20 7d 2e 7d 22 7d 26 7d 20 7d 20 7d 20 7d 20 7d 27 7d 22 7d 28 7d 22 68 f6 7e 7e ff 7d 23 c0 21 7d 21 3a 7d 20 7d 2e 7d 22 7d 26 7d 20 7d 20 7d 20 7d 20 7d 27 7d 22 7d 28 7d 22 9f f8 7e 7e ff 7d 23 c0 21 7d 21 3b 7d 20 7d 2e 7d 22 7d 26 7d 20 7d 20 7d 20 7d 20 7d 27 7d 22 7d 28 7d 22 32 fd 7e 7e ff 7d 23 c0 21 7d 21 3c 7d 20 7d 2e 7d 22 7d 26 7d 20 7d 20 7d 20 7d 20 7d 27 7d 22 7d 28 7d 22 71 e5 7e 7e ff 7d 23 c0 21 7d 21 3d 7d 20 7d 2e 7d 22 7d 26 7d 20 7d 20 7d 20 7d 20 7d 27 7d 22 7d 28 7d 22 dc e0 7e 7e ff 7d 23 c0 21 7d 21 3e 7d 20 7d 2e 7d 22 7d 26 7d 20 7d 20 7d 20 7d 20 7d 27 7d 22 7d 28 7d 22 2b ee 7e 7e ff 7d 23 c0 21 7d 21 3f 7d 20 7d 2e |
先頭の0xffはよくわかりませんが、7e〜7eのパケットのまとまりが確認できました。
ＲＦＣを読むとこれはＬＣＰのようです。リンクを確立しようとしてるわけですね。確かにＰａｌｍのディスプレイ上には「接続状況 ログオン」と表示されています。よく似たパケットが繰り返されているのはリトライしているわけですね。
リンク制御プロトコルで通信設定要求し、PFCとACFCを要求しているようです。これに対してＡＣＫのパケットを返せば次のステップに進めそうです。
（つづく）
ＲＦＣ１６６１を元にすべきのようです。
PalmのＨＯＴＳＹＮＣケーブルはＰＣのＣＯＭポートに接続するので、ＨＤＬＣ-likeのＲＦＣ１６６２も参照する必要があるようです。
while(i++ < 256 /* getch() != 'q' */ ){
DWORD dwRLength;
unsigned char bfRecv[256];
dwRLength = 0;
ReadFile(hCom, bfRecv, 1, &dwRLength, NULL);
if(dwRLength >0)
printf("%2x ",bfRecv[0]);
} /* while */
|
２００１．０４．０１
ＰＰＰはまぁだいたいわかった（うそ）ので、今度はＰＣ上で行うパケット変換処理について考えてみます。
ＰＰＰではＩＰＣＰ（ＲＦＣ１３３２）でＩＰパケットを透過的に扱えるようです。ここで疑問にぶつかります。WINDOWSでＩＰパケットを直接扱えるのでしょうか？今まではなんとなくＷｉｎｓｏｃｋを使ってＳｏｃｋｅｔプログラミングで行けるだろうと思っていました。しかしながらＷｉｎｓｏｃｋはＴＣＰ／ＩＰまたはＵＤＰ／ＩＰプロトコルを利用するためのＡＰＩです。ＩＰアドレスはＩＰＣＰで取得する仕組みがあります。ではポート番号はＩＰパケットに含まれるのでしょうか？なんとなく、ＩＰパケットに包まれたＴＣＰまたはＵＤＰパケットの中に書かれているような気がします。作ろうとしているソフトでは、例えばＰａｌｍからのパケットを
というようなことをせにゃならんのでしょうか。うむ。がんばればできそうな気もします。逆にＰａｌｍへのパケットも処理はできそうですね。
でもこれで本当にいいんでしょうか？なんやえらい遠回りのような気がします。もしＰＣ上でＩＰパケットを直接扱えるならば、ＩＰＣＰ<-->IP変換だけでいいはずなんですが…
あと、ＰＰＰってＴＡＰＩ（ＲＡＳ 誤記訂正２００１．０４．０２）でさらっと処理できないんでしょうか？できたらいいなぁ…
参照文献
ＳｏｆｔｗａｒｅＤｅｓｉｇｎ１９９９．１１ 特集
Ｉｎｔｅｒｆａｃｅ２０００．１０ 付録
２００１．０４．０２
ＲＡＳでＰａｌｍをつなぎます。ミス発見。ＴＡＰＩと書いたのはＲＡＳのつもりでした。
実はＮＴのＲＡＳがＰＰＰであることはわかっていたので、ヌルモデムケーブル接続でチャレンジしてみたことはあるんです。でもＮＴ側が全く無反応でした。無反応というのは、リモートアクセス管理のダイアログが無反応だったのです。
今日別の件でＰＰＰを調べているときにＰａｌｍ to RASというのが目にとまりました。これを読む限り、ＰａｌｍＯＳ３．３以降では
NT4でも95でも追加ソフトなしでつながるやんけ〜。
（注：ＮＴ４ではＲＡＳで、９５ではケーブル接続です。）
という結論です。ログインスクリプトに問題があり、まだうまくログインできていませんが、もうちょっとできそうな気がします。ダイアルネットワークモニタもピーピー反応していますし…
ここ数日の努力はなんだったのでしょうか？MochaPPPの利点がわかりません。RASではできないことがあるんでしょうか？ＷＩＮＤＯＷＳにもＩＰルーティングの機能/設定があるので、ＯＫのような気がします。
もしかすると、ＰａｌｍＯＳ３．３よりも前の「シリアル接続ＰＣ−ＰＣ」ができないＰａｌｍでMochaPPPが必要だっただけでは？という気もしてきました。
いきなりやる気がなくなってきました。ＭｏｃｈａＰＰＰの利点がわからないとこのまま進む気が起こりそうにありません。ふぅ。
２００１．０４．０３
NTのＲＡＳにうまくつながりません。ログはNT側で採ることができます。（Ａｒｔｉｃｌｅ ＩＤ：Ｑ１１５９２９） Ｐａｌｍ側のログではＮＴ側の応答が悪いように思えるのですが、ＮＴ側のログを見ると認証まで行っているのにＰａｌｍ側が勝手にやり直しているように見えます。
そこで、comp.os.ms-windows.programmer.win32で見つけたportmonをつかってPalmとMochaPPPの間でおこなわれるやりとりを記録してみました。
この２つを比較すればＲＡＳにうまくＰａｌｍをつなぐ設定がわかるかもしれません。（だんだん趣旨がずれていっているような…）
Received(Palm m100 --> MochaPPP) 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 70 34 7E Protocol 0xc021:LCP code 01:Configure-Request Identifier 01 Length 0x000e:14 octet Type 2,Length 6:ACCM 0x00 0x00 0x00 0x00 Type 7,Length 2:PFC Type 8,Length 2:ACFC Sent 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E FF 03 C0 21 02 01 00 0E 02 06 00 00 00 00 07 02 08 02 4E B7 Protocol 0xc021:LCP code 02:Configure-Ack Identifier 01 Length 0x000e:14 octet Type 2,Length 6:ACCM 0x00 0x00 0x00 0x00 Type 7,Length 2:PFC Type 8,Length 2:ACFC Received 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E FF 7D 23 C0 21 7D 22 7D 2B 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 7C 91 7E Protocol 0xc021:LCP code 02:Configure-Ack Identifier 0x0b Length 0x000e:14 octet Type 2,Length 6:ACCM 0x00 0x00 0x00 0x00 Type 7,Length 2:PFC Type 8,Length 2:ACFC Received 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E 80 21 01 01 00 1C 03 06 C0 A8 00 09 02 06 00 2D 03 01 81 06 00 00 00 00 83 06 00 00 00 00 B9 1A 7E Protocol 0x8021:ICPC code 01:Configure-Request Identifier 01 Length 0x001c:28 octet Type 3,Length 6:IP-Adress 0xc0 0xa8 0x00 0x09 Type 2,Length 6:IP-Compression-P 0x002d 0x03 0x01 Type 129,Length 6:IP Primary DNS 0x00 0x00 0x00 0x00 Type 131,Length 6:IP Secondary DNS 0x00 0x00 0x00 0x00 Sent 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E 80 21 03 01 00 16 03 06 C0 A8 00 09 81 06 C0 A8 00 02 83 06 Protocol 0x8021:ICPC code 03:Configure-Ack Identifier 01 Length 0x0016:24 octet Type 3,Length 6:IP-Adress 0xc0 0xa8 0x00 0x09 Type 129,Length 6:IP Primary 0xc0 0xa8 0x00 0x09 Received 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E 80 21 01 02 00 16 03 06 C0 A8 00 09 02 06 00 2D 03 01 81 06 C0 A8 00 02 FE B4 7E Protocol 0x8021:ICPC code 01:Configure-Request Identifier 02 Length 0x0016:24 octet Type 3,Length 6:IP-Adress 0xc0 0xa8 0x00 0x09 Type 2,Length 6:IP-Compression-P 0x002d 0x03 0x01 Type 129,Length 6:IP Primary 0xc0 0xa8 0x00 0x09 （以下略） Sent 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E 80 21 02 02 00 16 03 06 C0 A8 00 09 02 06 00 2D 03 01 81 06 Received 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E 80 21 02 02 00 0A 03 06 C0 A8 00 02 DD B5 7E Received 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E 80 21 05 03 00 04 EF 5E 7E Received 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E FF 7D 23 C0 21 7D 25 7D 22 7D 20 7D 24 59 28 7E Sent 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E C0 21 06 02 00 04 2F 23 7E Sent 00-01-02-03-04-05-06-07-08-09-0a-0b-0c-0d-0e-0f- 7E C0 21 01 0C 00 0E 02 06 00 00 |