シリアル-LANアダプタ(その2) PPPに寄り道した記録

寄り道の記録

　X68000PROにはNeptune-Xは装着していない。その状態でネットワークアクセスするならPPPしかない。幸いにしてPPPクライアントはある。サーバがあればいい…ということで手をつけ始めたPPP。もちろん実用目的なら80cm下でサーバと化しているPHILOS44C(RedHatLinux)とクロスケーブルで結んでしまえばいいだけの話。そこを敢えて文献にのみ頼って自分のコードで実装するってのは向学心と自己満足のためである、と述べておきましょう。
　ですがあまり考えなしに手をつけるのも考え物で、結局途中で挫折してしまいました。それでもソースを残しているのはいつか気が向いたら手をつけてやろうと考えているからなのですが、果たしてどうなるやら。ということで、ここはその時の記録を別ページに分離したものです。PPPだけではなくて悩み続けているシリアルポートの不安定性の対策も(これまた未解決だが)書いていますのでね。

PPP

　PPPを実装するためには、まずモデムとして振舞うようにしなければなりません。必要最低限のATコマンドを解釈し、OKとかCONNECTとか返すようにするわけです。本物のモデムだと行の先頭はAしか入力できないとか、空行では改行しないとかいろいろあるのでそれも真似るのが本当なんでしょうが、考えるうちに面倒になってしまいました。もう単純に1行エディット可能なコンソールを作って、先頭から"AT"となければエラー、あればその後を解釈するというようにしたのです。とりあえずZと&Fとなにもなしを受けつけられるようにすればモデムらしくなります。まさかPPPソフトが空行チェックなんてするわけないでしょうしね。
　このATコマンドを受けつけ、解釈するタスクを優先度4にして、優先度1にあったモデムポート用のシリアル入力タスクを削除し、起動するように設定していざ実行…あれ?反応ないですね。それではタスクにシリアルから受信した文字が来ているか確かめるためにメッセージとその文字コードを表示するようにすると…あれ、反応がある。OKとかERRORとかの文字列の定義がよくなかった(配列にエンドコード"0"の分を確保してなかった)ので一時は妙なエコーバックがありましたが、それを直すと一応モデムらしく振舞うようになりました。で、デバッグ用のメッセージを取ると…あれ、動かない。そもそもpingには返事するよね、とモデム動作確認用のターミナルを動かしていたWin95のDOSプロンプトからpingを実行…おお、タイムアウトだ。どうなってんだ、こりゃ。

　以前のプログラムでもLinuxからのpingに応答してもWin98には応答しないということがありました。その時はチェックサムがおかしかったのが原因で、そのルーチンを修正すれば直ったのではありますが、それをそのまま使っている今回のプログラムで同じ事が起こるとは考えにくいものがあります。けれどもとりあえずtcpdumpにて確認。表示されるのが全体ではないのでヘッダを手計算にて検算、合っているようです。当然全体のバイト数もあってます。
　だいぶ悩んでから、もしかして、tcpdumpでは表示できない(してなかったというのが正しいか)MACアドレスがおかしいのかも、と気づきました。実は、MACアドレスの登録されてないIPアドレスへパケットを送らないといけないとき、上記のようにARP要求を出すのではなく、ブロードキャストアドレス(FF:FF:FF:FF:FF:FF)を指定するように変えていたのです。ブロードキャストでも受けてしまえば、あとはIPアドレスで処理してくれるというアドバイスを聞いた経験からそうしていたのですが、どうもWinはブロードキャストを撥ねているような雰囲気があります。
　それではということでどんなアドレスに送ろうとしてるのかチェックしようとイーサネットヘッダをダンプするルーチンを仕込むと、確かに、ブロードキャストアドレスに送ろうとしています。ということは、ARPテーブルが変なんでしょうか?これも前のプログラムから持ってきてるんですがねぇ…。
　今度はARPテーブルに登録する情報を、登録時に表示させてみます。すると…あれ、応答をちゃんと読み取ります。むむむ?ではそのメッセージ出力を削ってみると…やはりタイムアウト。どうなってるんぢゃ?

　ATコマンドタスクなどの関係を調べるうちに、なんだかむちゃくちゃになってきました。ヘッダのダンプが1回(ARP応答)だけしか出なかったり、pingの分まで出る時は2回目のpingで暴走、どうもパケットの送出もまともにやってない様子。Linuxのpingにも応答しなくなりました。
　そこで、タスクのスイッチを確かめるべくディスパッチ部にまたメッセージ出力を仕込みます。今度はどのタスクからどのタスクへ遷移したのかも表示させることにします。
　すると、なんだかデバッグ用のメッセージ出力のところで無意味なディスパッチが無数に起こっているのがわかりました。しかも最後には暴走してしまいます。ダンプ出力とスイッチ情報の出力を同じポートにしてるのがまずいんでしょうかねぇ。ということで、ダンプ出力をモデムポートへ振り替えると、落ち着いて出力されるようになりました。

　ここでダンプ出力あり、スイッチ情報表示の状態でpingを動かしてみると、正しく返答されます。それを確認してからダンプ出力を削ってみると、返答がおかしくなるようです。なんでかな…とタスクの遷移を眺めていたら、なんと先述の「最後のパケットが出力されない」現象が現れました。そういえば、ATコマンド周りを実装中に数千回pingを連続で流していたのですが、その間にも無関係のパケットはいくつもあったのに問題なく応答されていました。どうも無関係のパケットが必ず悪さするわけではないようです。
　そこでもっと詳しく遷移を追ってみると、ちょっと妙な、といってもまぁ納得はしてるんですが、そんな動きを見つけました。今は物理層に近いほど高い優先度をつけて各タスクを動かしているんですが、特に送信時、上位プロトコル→下位プロトコルの転送で転送時にディスパッチが起こり(下位の方が優先度上のため)、下位のタスクでの仕事がなくなってから上位に戻って受信待ちに移行するので、タスクの遷移が上位→下位→上位などと往復しているのです。受信側は素直に流れています。そのようにタスクを並べたのだから仕方ないのですが、もしかしてこれが悪いのでしょうか。
　考えてもよくわからないので、試しにタスクの優先度をいじってみることにします。基準はICMP要求が入ってからICMP応答が出るまでの流れの順。ARPはIPと同レベルとします。これはこれまで設定していた優先度を決める前に考えていたのとほぼ同じだったりします。とりあえず、こんな感じ。

優先度 タスクの内容
1 NE2000受信,シリアルポート受信
2 イーサネット受信
3 IP受信,ARP受信
4 TCP受信,UDP受信,ICMP受信/送信
5 IP送信,ARP送信
6 イーサネット送信
7 NE2000送信,シリアルポート送信

　そうして実行してみると、あっさりpingの応答がありました。ううむ、とすると、今までは優先度が逆だったので、ARPテーブルに登録する前に送信しようとしていたということなんでしょうかね?それにしても、優先度が上のタスクが全部仕事がなくなっても下のタスクが動かないことがあるということになるような気がして、なんだか気持ち良くありません。それとも、これが「優先度逆転現象」というやつなんでしょうか?うーん、今のままでいいのかなぁ…。

気を取りなおして、再びPPP

　…と思ったのですが、どうも調子よくありません。タスクの遷移を表示するようにしていると調子いいんですが、モデムポートを扱うタスクを走らせてタスク遷移表示を切ると動かなかったりします。割り込みに関わってるような気もしますが、納得いきません。試しに、デバッグポート＞NE2000＞モデムポートの順になっている割り込み優先順位をスタートアップルーチンをいじってデバッグポート＞モデムポート＞NE2000の順にしてみると調子はいいようです。でもなんだか理屈に合わないような、関係ないような。

　一応ATコマンドは「AT」と「ATZ」と「AT&F」を実装して、Win95のTeraTermProでは調子よく応答するようです。まぁ実装したといっても内部のモデムの動きという意味で初期化する部分はいまのところないですから、これらのコマンドに対してOKを返すだけ。
　ダイヤルコマンドを実装する前に、PPPの通信相手となるシステムとの基本的な通信ができているか確認します。そのシステムとは、「超漢字」。漢字や記号など13万種の文字をなんの区別もなく取り扱えるという、今人名漢字で悩まされている自治体などから問い合わせが集まっているという、BTRON仕様OSです。なぜこれを選ぶのかというと、このシステムに付属する「ダイヤルアップ接続」小物の機能である「接続ログ表示」では、単にモデムとの文字のやり取りだけでなく、PPPモードに入ると比較的詳くパケットの内容(おそらくLCPの要求や応答の内容)が表示されるのです。接続がうまくいかないとき、どういうフェーズで切れたのかを調べるためだろうと思いますが、ほとんどデバッグ情報ですよね。単にダンプを見るより、こういうメッセージがあったほうが調べやすかろうというものです。
　で、今超漢字を入れてあるパソコンは二つある(どちらもノート型)のですが、そのうちのひとつがFreeBSD・Win95とのマルチブートになっていてこれまでもpingやtcpdumpを動かすのに使っていたということもあって、デバッグ時だけとはいえ超漢字専用にするわけにはいきません。そこでもうひとつの、超漢字専用機を使うわけですが、どういうわけか19200bpsを超えるボーレートに設定できません。しかたないので、アダプタ側を19200bpsに変更。そう言えば、できるだけ自由にボーレートを変えられる機構を用意しておかないといかんですなぁ。
　シリアルケーブルをつないだあと、「通信記録箱」を開いて反応を確認。「atz」と入力して、ちゃんと「OK」と返ってきます。で、「at」と入力して…あれ、「OK」と表示されたものの改行しない…しかももう何も入力できない?!。リセットしてもう一度プログラムを流し込んで…やっぱり同じ。atに続いて何かコマンドがあると問題ないのに、単独で入力するとハングアップ。コマンドのあるなしが影響するなら、whileのループで一度はチェックしている(コマンドがなければすぐループを抜ける)のをコマンドがなければループに入らないようにしてしまえ、と変えてみると一応ちゃんと動くようになったみたいです。

　では、ダイヤルコマンドを実装しましょう。ダイヤルコマンドは今後TELNETなどでも使用するもので、扱いとしてはATコマンドモードからそれぞれの専門モードに移行するコマンドということになります。せっかくなのでPを使いましょうかね。ダイヤル先はないので「ATDP」と先頭にあれば番号はなんであってもPPPモードに移ることにします。
　モードを移っても入出力するシリアルポートは同じなので、同じ割り込み処理ルーチンを使うことになりますが、ではその中身はどうしましょう。処理ルーチンといってもシリアルポートから入力した文字をsnd_dtqでそれを受け取るタスクに送りこんでるだけなのですが、PPPモードとATコマンドモードでは処理するタスクが違うので、それに対応したsnd_dtqを使わないといけません。モードを表わすグローバル変数を定義してswitchで分けるところですが、よく考えるとsnd_dtqにはデータを送る対象のデータキューIDを指定するのですから、それを定数でなくて変数にして指定すれば可変になりますよね。そこで、CONNECTを応答として返す直前にその変数をPPP向けに変更することにしました。割り込み処理ルーチンが軽くなると応答性が良くなるものです。
　さて、そのCONNECT出力を追加したところで通信記録箱でチェック。atでもatzでもフリーズしないのを確かめて、atdpと入力…あれ、「CONN」って…途中で出力が止まってるじゃないですか。うーむ。

　ここのシリアルポート出力タスクはこのようになっています。

while(1){
　　size=rcv_mbf(M_DEB_S, s);
　　for(i=0;i<size;i++){
　　　　outp( UART_CH0_DATA, s[i] );
　　　　for(j=0;j<100;j++);
　　　　ena_int(INT8);
　　　　slp_tsk();
　　}
　　dis_int(INT8);
}

以前μITRON部のみを作った時に一緒に用意したテストタスクなのですが、よく考えるとその時も原因不明のハングアップがありました。その時は出力データをポートに書き込んでから割り込みを許可(割り込みコントローラの設定)するまで時間待ちすることでクリアしました。上記のjでカウントしている空forループです。数値はいいかげんで、入れてみたらうまくいったという程度のものです。症状が似ているということで、このループが足りないのかと思って150にしてみたところ、ちゃんと動くようにはなりました。とすると、なにかガードタイムみたいなものがあって、それ以内ではレジスタ操作後の割り込み許可操作ができないのでしょうか。
　それにしても、無意味なループを仕込んでいる事自体気持ち悪いですし、ボーレートを19200bpsに落したのが原因でループ回数を増やさないといけなくなったとしたら、適当な式でもってボーレートに反比例したループ回数を算出しないといけません。なんかスマートじゃない、リアルタイムOSのプログラムらしくないです。ということで、うんうん唸って次のように変更しました。

while(1){
　　size=rcv_mbf(M_DEB_S, s);
　　outp( UART_CH0_DATA, s[0] );
　　ena_int(INT8);
　　slp_tsk();
　　for(i=1;i<size;i++){
　　　　outp( UART_CH0_DATA, s[i] );
　　　　slp_tsk();
　　}
　　dis_int(INT8);
}

最後に割り込みを不許可にしているのは次の文字列の送信まで余計なことしないように。いらないような気もしますが、これがないと次の送信の先頭の文字が化けます。不必要な割り込みをもらわないために一度割り込みを不許可にしているということは、次の送信でまた許可しないといけないわけです。許可は最初の文字を送信した後としてループを単純に考えたのが前の例でした。つまり一文字送信しようとするたびに不許可無しでも許可させていたわけですね。で、考えてみれば最初だけ許可して終われば不許可にするという手もあるわけで、先頭の文字だけ特別扱いしてループの外に出したのが下の例ということになるのです。これで問題は解決しているみたいです。やれやれ。

本当に今度こそPPP(;_;)

　"ATDP"コマンドに対して"CONNECT"を返すように実装して、いざPPP処理部。といっても必要最小限にしようと考えているので、超漢字がどのような設定とか送ってくるかをいちいち確かめてそれに対する応答を実装することにします。でも最初の問題は、PPPとしてどんな文字列を送ってくるかということ。設定とかいう前に、PPPのフレームについて調べなければなりません。
　PPPというプロトコルは別にRS232Cでなくても実装できるわけで、I/Fの特性に合わせてそれぞれの実装方法というのがあるみたいです。まぁ用いられるのがシリアル回線が主だということでそれ用の解説があればいいんですが、なんでもものの本によれば「HDLCライク」なフレーム構造になっているとか。むむ、HDLC。
　HDLCというのは確かIBMが開発したプロトコルだったと思うんですが、その前身であるSDLCがZ80SIOに搭載されているように、それなりに歴史があります。私も通信屋のはしくれとしてある程度の知識は持ち合わせてるつもりでしたがよく考えるとほとんどないわ、こりゃ。てなわけで、ちょっとだけ復習。HDLCのフレームというのは、基本的に0x7Eで始まって0x7Eで終わるようになっています。先頭の0x7Eの直後にはアドレス、次に制御バイトが続き、その後データの中身が続いて、最後にFCS(フレームチェックシーケンス)があって、0x7Eで〆ます。ざっとこんな感じ。

7E,アドレス,制御,データ…データ,FCS,7E

当然0x7Eは特別なバイトなので、これがデータ中に含まれる場合は特別な処理が施されます。確か、記憶では5ビット"1"が続くとそこに強制的に"0"が挿入されたような。つまり、7Eそのものを送ろうとするなら"01111110"が"011111010"となり、このバイトだけ1ビット長くなるのです(なにか他の規則とごっちゃにしてるような気が…)。また、FCSは単なるチェックサムでなくてCRC演算によるチェックバイト(2バイト)になっています。通信装置内ではCRC演算回路なんてどんなに複雑でも通信速度といっしょに流れますからね。比較的簡単な回路で強力にチェックできるし頑張れば化けた1ビットの復元もできます。
　で、PPPではHDLCではなく「HDLCライク」ということなので、少し様子が変わります。まずアドレスと制御は意味をなさないのですが削ることまではしないので固定値をあてます。データ中の特別なバイトには直前に0x7Dを挿入し、当該データのビット5を反転させます。シリアルポートでやりとりするので、Xon/Xoffなど使用したい場合はそれらも処理の対象とします。
　問題はFCSです。論理回路なら簡単でもプログラムにするとちょっと面倒。受信した文字列のFCSの正当性は無視するとしても、送信する文字列には正しいFCSが必要でしょう。なんとかならんかな…とか思ってたら、やっぱり同じこと考えるんですねぇ、ありましたよRFC1662に。8ビット並列のCRC演算ルーチンのようですね。これをそのまま頂くとしましょう。ああ、ありがたや。なお、設定次第で32ビットのFCSにできるらしいですが、拒否するようにしましょう(^_^;)。

　超漢字とアダプタをシリアルで接続し、「ダイヤルアップ接続小物」を起動しておき、接続ログを表示した上で接続開始。接続ログには

PPP-Tx: <01220> [S=01:9] LCP CONF-REQ [ID=00 L=00e]
　　　　　　　MAG=c4040000 PROT-COMP ADDR-COMP
PPP: <01240l> Modem Disconnected

と表示されました。"Disconnected"が出てくるのが異様に速いのが気になりますが、何か返事がないから切れたものと判断しているように見えます。受信した文字列をダンプしてみて、そこから判断するにこれは「設定要求、マジックナンバーC4040000、プロトコル圧縮、アドレス圧縮」という内容のようです。これに対して、アダプタは全部受け入れでACK、部分否定でNACK、または拒絶を返答します。試しに圧縮って面倒そうなので、これを否定する意味でNACKを返してみましょう。返答フレームを作成し、0x7Dで加工するルーチンもつけて挑戦…あれ、CONNECTさえ返らない。さっきのでうまくいくと思ったのに…。

　一時は割り込みを使用せずステータスを監視して送信可能ならレジスタに書きこむようにしようかと思いましたが、それではリアルタイムOSの特性が失われてしまいます。そこでライブラリ付属のソースからレジスタ書き込み(ステータスチェックつき)部を移植し、でも割り込みは生かすという方法をとってみましたが、思ったほどの効果はなし。なによりも、シリアル送信部とは直接関係ないところをいじっても動作に影響するのが納得いきません。
　ふと、このCPUが16ビットであることを思い出しました。データバスが16ビット、もちろん16ビットで命令のフェッチを行います。命令長もまちまちだし、これが奇数アドレスとか偶数アドレスとかから置かれると動作に違いはでないんでしょうか?
　もちろん命令の動作に違いはないですし68000のように偶数番地から置かないとアドレスエラーなんてことはないんですが、実行速度に違いのある命令がいくつかあるようです。見るとLD r,(HL)のような基本的な命令に違いが出るようです。すると、コンパイルした結果、命令実行速度に違いのある命令がどのように並ぶかで全体の処理時間も変わることになります。以前ダミーループでタイミングをとっていたぐらいですから、もしかしたら微妙な何かがあるのかもしれません。
　そこでとりあえず対策なしでコンパイルしたものが動かない場合、適当な場所にアセンブラ擬似命令でNOPを仕込むことにしました。何もしない1バイト命令を置けばその後の命令の奇偶が変わることになります。扱い的には68000でいうところの.even擬似命令のようなものですね。この対策で、最初動かなかったものが動くようになったりするようになりました。まだ入れる場所とかはよく理解してませんが、とりあえずごまかせそうです。

　さて、シリアルポートがだましだましでも動くようになってきたので(細かくはまだトラブルがあるのだが)、さっきの設定要求にNACKを送ってみます。最初はFCSの入れ方や計算の仕方を間違えて

PPP: protocol c021 packet discarded (state=ee)

などと言われてしまいましたが、そのうち正しくFCSが入るようになって、次のように表示されるようになりました。

PPP-Tx: <01210> [S=01:9] LCP CONF-REQ [ID=00 L=00e]
　　　　　　　MAG=ba040000 PROT-COMP ADDR-COMP
PPP: <01230l> Modem Disconnected
PPP-Rx: <01250> [S=ee:9] LCP CONF-NAK [ID=00 L=00e]
　　　　　　　MAG=ba040000 PROT-COMP ADDR-COMP
PPP-Tx: <01250> [S=01:9] LCP CONF-REQ [ID=00 L=004]

PPP-Rx: <01280> [S=01:9] LCP CONF-ACK [ID=00 L=004]

PPP-Tx: <02380> [S=01:9] LCP CONF-REQ [ID=01 L=004]

PPP-Rx: <02410> [S=01:9] LCP CONF-ACK [ID=01 L=004]

NAKはちゃんと受信されているようですが、そのあと意味があるのかないのか、妙なやり取りが続いています。うむむ、圧縮をサポートしてないとイヤなのか…と思いきや、NAKには受け入れない設定だけ返せば良かったんですか。マジックナンバーまで受け入れないホストなんてないですから、動きが妙なんですな。

　そのあたりの変更とかするたびにシリアルポートの動きがおかしくなり、調整して騙しだまし動くようにしてきましたが、どうにも使いにくいのでまずはデバッグ用ダンプ出力をUDPで送り出すように変更することにしました。といってもその文字列を受け取る側はどうすればいいのかさっぱりわからなかったので、本を読んでソケットインターフェースを勉強。ちょっと迷いはしましたが、そんなに難しくないんですな。まぁ本にはTCPのことしかなかったので迷ったんですが。次に送り出す側は、単純にUDPヘッダとかを作ってIP出力タスクにデータを渡せばOK。まぁヘッダを作るところでIPアドレスを転送するつもりが静的宣言している他の変数の値まで書きこんでしまって、ポートが設定できなくて悩みましたけどね。で、試しに受信PPPの未実装コード表示をさせてみると、すんなり表示されました。ふふふ、これが将来的に汎用UDP送信タスクになるんだろうな。
　そうしてシリアルポートをひとつだけにしてしまえば安定するかとも思ったのですが、やはり何度目かの変更でどうしても動かなくなりました。割り込み駆動なんだからそんなにタイミングにクリティカルなはずないのに、どうしてなんだろう…もうPPPやめちゃおうか(どうせtelnetやftpでも悩むんだから同じなんだけど)…。
　と思いつつソースを眺めてたら、ひとつ原因らしきものが浮かんできました(いくつ浮かんで外れたことか…)。割り込み駆動されるタスクは、割り込みを待つポイントでslp_tsk()を実行します。slp_tsk()内の処理では、最初にキューイングされてないかチェックして、それがなければディスパッチします。割り込み処理部ではwup_tsk()を実行しますが、slp_tsk()でディスパッチしたタスクがあればそれを実行待ちにし、なければキューイングします。今はμITRON内部でもほとんどのところで割り込み許可になっていて、slp_tsk()も例外ではありません。もしキューイングチェックの直後で割り込みが入れば、まだディスパッチしてませんからwup_tsk()ではキューイングし、しかし割り込みから復帰してもキューイングチェックは終わってますのでディスパッチしてしまいます。さっき送信しようとしていた文字に対する割り込みはもう起こりましたから、次の割り込みはありません。おお、止まるじゃないか。
　それではと、slp_tsk()のほとんどを割り込み禁止にしました。先頭で禁止し、キューイングされていればそのまま戻ってしまうのでその直前で許可、ディスパッチ処理ではディスパッチ部の最後で許可しているので特に許可はしない、ということですね。これでコンパイルしてみると、ちゃんと動いているように見えます。ただ、これではシリアルが止まるとIP処理も止まるという現象の説明にはならないので、まだ予断は許さないのかもしれません…。

　さて、今度はマジックナンバーは受け入れ、圧縮は否定…オペランドがないので拒否を送ってみることにします。全部否定するか全部受け入れるなら受けた文字列をコードだけ書換えて送り返せばいいのですが、一部否定だと新たに送信用の文字列が必要です。このあたりがちょっと面倒でしばらく考えてしまいましたが、設定を解析して否定・拒否なしなら送り返し、ありなら解析過程で返信用配列にその設定を書き込んでおくのでそれを否定または拒否のコードを入れて返信、ということにしました。それで実行してみた結果がこれ。

PPP-Tx: <01210> [S=01:9] LCP CONF-REQ [ID=00 L=00e]
　　　　　　　MAG=ba040000 PROT-COMP ADDR-COMP
PPP: <01230l> Modem Disconnected
PPP-Rx: <01250> [S=ee:9] LCP CONF-REJ [ID=00 L=008]
　　　　　　　PROT-COMP ADDR-COMP
PPP-Tx: <01250> [S=01:9] LCP CONF-REQ [ID=00 L=00a]
　　　　　　　MAG=e2040000
PPP-Rx: <01280> [S=01:9] LCP CONF-ACK [ID=00 L=00a]
　　　　　　　MAG=e2040000
PPP-Tx: <02390> [S=01:9] LCP CONF-REQ [ID=01 L=00a]
　　　　　　　MAG=56090000
PPP-Rx: <02420> [S=01:9] LCP CONF-ACK [ID=01 L=00a]
　　　　　　　MAG=56090000

<01250>で圧縮の拒否を受信しているようです。その次、もう一度マジックナンバーを設定していますので、これにはACKを返しているのですが、またマジックナンバーを設定しようとしています。もちろんその度にACK応答しているのですが、これが延々続くのです。なんでかな?本を見るとマジックナンバーをもらったらすかさず自分のマジックナンバーを渡しているので、それを待っているんですかね。では、マジックナンバー設定を受けたら自分のマジックナンバー設定を予約し、肯定応答ならその後マジックナンバーを渡すようにしましょう。マジックナンバーを何にするかが問題ですが、MACアドレスの下4バイトにでもしておけばまぁトラブルはないでしょうかね。すると、こんな感じになりました。

PPP-Tx: <01210> [S=01:9] LCP CONF-REQ [ID=00 L=00e]
　　　　　　　MAG=ba040000 PROT-COMP ADDR-COMP
PPP: <01230l> Modem Disconnected
PPP-Rx: <01250> [S=ee:9] LCP CONF-REJ [ID=00 L=008]
　　　　　　　PROT-COMP ADDR-COMP
PPP-Tx: <01250> [S=01:9] LCP CONF-REQ [ID=00 L=00a]
　　　　　　　MAG=e2040000
PPP-Rx: <01300> [S=01:9] LCP CONF-ACK [ID=00 L=00a]
　　　　　　　MAG=e2040000
PPP-Rx: <01300> [S=03:10] LCP CONF-REQ [ID=00 L=00a]
　　　　　　　MAG=f690a3e6
PPP-Tx: <01300> [S=0f:10] LCP CONF-ACK [ID=00 L=00a]
　　　　　　　MAG=f690a3e6
PPP-Tx: <01300> [S=1f:9] IPCP CONF-REQ [ID=01 L=016]
　　　　　　　IPADDR=0.0.0.0 IPCOMP=002d:07:01 DNSIP=0.0.0.0

確かにマジックナンバーを交換して、次のシーケンスに移っています。次はIPCP設定のようですね。IPアドレスとDNSアドレス、それと圧縮について設定を求めているようです。本にはDNSの設定は載ってないのですが、あるようですね。で、さっき圧縮を拒否したので忘れてくれるかと思っていたのですが、また圧縮の設定が入っています。IPCPにも肯定とか拒否とかあるようなのですが、いきなり本の記述が甘くなって詳しくわかりません。ここを乗り越えるとIPパケットのやりとりに入るのでもう一息なんですが…。

投げ出してます(-_-;)

　やっぱりRFC読めってことですかね。PPPくらいなら和訳されているものもあるので読めばいいんでしょうが、気合が…。

戻る