問題点を理解すれば、もう最初の半分を解決したことになります。
もしこの手段を使いたいなら、まずこれがどのように機能するかを考えてみる必要 があります。そうすれば、何かおかしくなった場合に、どこに見当をつけたらよいか がわかります。
問題点を理解するはじめのステップは、関連した考え方に名前をつけて区別すること です。
それではまず、「ローカル」という言葉は、相手に接続を仕掛けるマシンを意味し、 プログラムやファイルもそのマシン上にあることとします。反対に、「リモート」 という言葉は、接続の相手側を意味します。
最終目標は、ローカルの IP エミュレータ入出力を、それに対応するリモートの IP エミュレータに渡すことです。
IP エミュレータ間のやりとりを行う経路は、直接接続されているデバイス(pppd の 場合)か「現在使用している tty」のどちらかになります。 telnet セッションは前者ではなく、後者に当てはまるのですが、扱いづらい面が あります。 というのも、コマンド・ラインからローカルのエミュレータを実行すると、 「現在使用している tty」は、リモート・セッションではなく、コマンド・ラインを 使っているユーザに接続されてしまうからです。もちろん新たにセッション(ローカル もしくはリモートで)を新規の端末から立ち上げる必要がありますが、両側の IP エミュレータの起動と起動後の接続を同期させなければなりません。あるセッション の不要な出力を、もう一つのセッションのコマンドとして実行してしまうことだけは、 避けなければいけません。そうしないと、繰り返し不要なコマンドが実行されてしまい ます。
最も簡単な方法は、ローカルの IP エミュレータがカーネルのネットワーク 機能である pppd に IPパケットのデータを渡す方法です。しかし pppd は結構まぬけ で、 /dev もしくは、現在使用している tty からしかデータを受け取れません。 受け取るのは tty からで、パイプ経由ではだめなのです(これはいわゆる仕様という やつでしょう)。 つまり、リモートの pppd で telnet セッションの tty を使用する分にはよいと しても、ローカルの pppd では、接続すべき telnet セッションを pppd が横取りして しまうので、具合が悪いことになります。 そのようなわけで、ある種のラッパーが必要になってきます。
telnet は たいていの場合、パイプをうまく利用できます。ただ、やはり現在 使用している tty デバイスの制御を行うため、動作に支障が生じてしまいます。 また telnet を tty を利用せずに使用すると、データのやりとりが競合状態になって しまいますので、「遅い」コンピュータを使っていると、接続ができなくなるかも しれません(fwprc 0.1 は、Pentium/MMX 233 では問題なく動作しましたが、 6x86-P200+ では 6 回中 1 度だけ動き、486DX2/66 では全く動作しませんでした)
[注: すっきりとしたパイプの対を使わないで、「同じ」仮想ファイルを使ってファ イルを読み書きするという "tty" デバイスの原理を発明した馬鹿野郎 (たぶんそいつは MULTICS 使いだと思うけど、それを真似したバカな UNIX な 人もいるはず)を見つけたらシメてやる! !]