Linux PPP HOWTO <author>Al Longyear, <tt>longyear@netcom.com</tt> <date>April 1, 1995. <trans>小島 三弘(翻訳版:1995/05/31), <tt>kojima@komae.denken.or.jp</tt> <!-- どーも <tdate> の処理がうまくいかないようなので、、 --> <abstract> この文書は Linux の PPP についてしばしば尋ねられる質問(とその答え)をま とめたものです。他の HOWTO とは異なり、`伝統的な' Q&A 方式でまとめてい ます。 <sect>前書き <p> 誤りがあれば <tt>longyear@netcom.com</tt> まで連絡してください。 [日本語版に関しては <tt>kojima@komae.denken.or.jp</tt> までお願い します。] <p> これは一連の Linux HOWTO/FAQ 文書類の一つです。Linux の HOUWTO 集は <tt>sunsite.unc.edu:/pub/Linux/docs/HOWTO</tt> から(ここが HOWTO の公 式な公開場所です)、あるいは WWW を使って <url url="http://sunsite.unc.edu/mdw/linux.html" name="the Linux Documentation home page"> から入手できます。 <tt>comp.os.linux.answers</tt> に HOWTO が必ず投稿されるとは限りません。 HOWTO は概して大きいので、転送を拒否するサイトもいくつかあります。 <p> この文書の中では`リモート'という言葉を `モデムで接続する先のシステム' として使います。`リモート'は PPP のドキュメントの中では `ピア' とも呼 ばれています。また、この相手先は、ルーティングについての説明時には `gateway' とも呼ばれます。`gateway' の IP アドレスは <tt>ifconfig</tt> を使えば `P-t-P' アドレスとして示されます。 <p> Microsoft is a registered trademark of Microsoft Corporation. Morning Star is a registered trademark of Morning Star Technologies Incorporated. All other products mentioned are trademarks of their respective companies. <p> <sect>概論 <p> <sect1>PPP とは何でしょう？ <p> PPP すなわち Point-to-Point Protocol はインターネットの「公式」プロト コルです。PPP は、シリアル接続を使って IP フレーム(と、その他)を交換す るためのプロトコルです。PPP に関する最新の RFC は 1661 で、その他、多 数の関連する RFC が存在します。 <p> ある種の人々の想像に反して、PPP は、"Peer to Peer Processing" の略では ありません。もっとも、PPP 上に張られる TCP/IP のリンクはピア・ツー・ピ ア(一対一)の通信になっていますが。 <p> <sect1>私の大学(会社)は PPP の設定がされていません。PPP は使えるでしょうか？ <p> 一般論的に言うと、ダメです。「古典的な」 PPP のインプリメントでは、PPP を使うためには OS がサポートしている通信経路(routes)と利用しているネッ トワークデバイスを変更する必要がありました。つまり、リモートのコンピュー タのカーネルを PPP を使うために再構築する必要がある、ということです。 <p> これは一般ユーザーの仕事ではありません。もし、あなたの組織の管理者に PPP が「有益だ」と信じさせることができれば、使えるようになる可能性があ るでしょうが、もし出来なければ、多分 PPP を使うことはできません。 <p> しかし、"TIA"(The Internet Adapter) packeges を扱っている人たちにサポー トされているシステムを使っているなら、希望はあります。私自身は、このパッ ケージについてあまりよく知らないのですが、私の知るところによると、「次 のバージョン」で PPP をサポートする予定になっているそうです(私の情報は 古くなっているかも知れません。直接、彼らに聞いてみてください。TIA に関 する情報は <tt>ftp.marketplace.com</tt> の <tt>/pub/tia</tt> ディレク トリにあります)。 <p> もし使っているシステムが TIA にサポートされておらず、管理者たちに PPP の有効性を信じさせることも出来ない場合、`<tt>term</tt>' を使う必要があ ります。いくつかのサービスプロバイダは `<tt>term</tt>' を動かすことを 拒否しています。それには多くの理由がありますが、最大のものは `セキュリ ティ上の問題'です。 <p> Linux も TIA の移植もリストには上っています。 <p> <sect1>PPP はどこにあるの？ <p> PPP は 2 つの部分に分れています。最初の部分はカーネル内にあります。 1.1.13 以上のカーネルでは、PPP のドライバはネットワークシステムのドラ イバの中に組みこまれています。 <p> <bf> kernel に入っているドライバを <tt> pppd </tt>パッケージに入っているドライバと入 れかえてはいけません !!! </bf> <p> 残りの半分は `デーモン' プロセスである<tt> pppd </tt>です。PPP を使う には、このプロセスが<bf>必要</bf>になります。pppd のソースは <tt>sunsite.unc.edu</tt> の <tt>/pub/Linux/system/Networking/serial</tt> ディレクトリにある <tt>ppp-2.1.2b.tar.gz</tt> に入っています。 <p> 1.1.13 以前のカーネルでは、必要なドライバは pppd のコードの中に含まれ ていました。 <p> <sect1> PPP を入手しました。次はどうすればいいんでしょう？ <p> 「マニュアルを読みなさい」 <p> まず<tt> README </tt>ファイルを読み、次に <tt>README.linux </tt>ファイ ルを読みましょう。その他、関係するドキュメントは後述します。 <p> <sect1>PPP に関するその他の情報はどこにありますか？(ドキュメント、HOWTO などなど) <p> Linux にインプリメントされた PPP についてはさまざまな情報が存在します。 <itemize> <item> ソースパッケージの<tt>README</tt>ファイル <item> ソースパッケージの <tt>README.linux</tt> ファイル(和訳あり) <item> <tt>Net-2-HOWTO</tt> ドキュメント(和訳あり) <item> Network Administration Guide <item> <tt>pppd</tt> の man ページ <item> The ppp FAQ document (この文書自身です) </itemize> HOWTO ファイルは Linux HOWTO のいつもの場所におかれています。現在は、 <tt>sunsite.unc.edu</tt> の <tt>/pub/Linux/docs/HOWTO</tt> ディレクト リです。 <p> Network Administration Guide は sunsite の <tt>docs/linux-doc-project/nag</tt> ディレクトリにあります。これは O'Rielly and Associates から出版されていますので、もし専門的なドキュメ ントが必要ならば、手近の本屋で買うのがいいでしょう。 <p> `<tt>man</tt>' ページはソースパッケージに附属しています。<tt>man</tt> コマンドが見つけられるように、一般の man ページがあるディレクトリ <tt> /usr/man/man8</tt> に移動させましょう。あるいは、<tt>nroff</tt> と <tt>more</tt> を使って直接見ることも可能です。 [訳注：Linux では <tt>groff</tt> と less を使います。具体的には <tt>groff -man -Tascii pppd.man | less </tt> とすれば整形されたマニュ アルが読めます] <p> PPP faq は PPP プロトコル自身とその様々なインプリメントについて書いて あります。この文書は usenet の <tt>comp.protocols.ppp</tt> に投稿され、 <tt> rtfm.mit.edu</tt> の <tt>/usenet</tt> ディレクトリにアーカイブさ れています。現時点では 8 つのパートからに分れています。 <sect1>PPP についての質問はどこに投稿するべきでしょう？ <p> usenet において、PPP のインプリメントについて議論する第一の場は <tt>comp.protocols.ppp</tt> です。"pppd の使い方は？" とか "なぜ動かな いの？" といった一般的な質問はこのグループにしてください。 <p> "何故 pppd がコンパイルできないのでしょう？"といった類いの質問は、おそ らく linux に関係した問題なので comp.os.linux.networking グループに投 稿するのがいいでしょう。 <p> この質問に comp.os.linux.help は使わないでください。 [訳注：NetNews の改組により comp.os.linux.help は無くなり、 comp.os.linux.setup, comp.os.linux.misc 等になりました] <p> <sect1>PPP が動きません。助けて！！ <p> これはもっとも無意味な質問です。助けを求めていのだとは思いますが、<bf> これ以外の情報無しに</bf> 投稿するのは何の役にも立ちません。 こんな質問は私を含め、ほとんどの人が黙殺するだけでしょう。 <p> 「モデムがうまく接続されないエラー」に関する質問の項を読んでください。 それらはトラブルの原因ではなく、症状にしか過ぎません。これらのエラーメッ セージのみを付けて投稿するのも同様に無意味です。 <p> 質問の際に必要なものは、<tt>pppd</tt> を `<tt>debug</tt>' オプション付 きで動かした時のシステムログ(syslog)の出力です。加えて chat を使ってい るならば、chat に `<tt>-v</tt>' オプションを付けて、冗長なメッセージが 出力されるようにしてみてください。 <p> カーネルの起動時のメッセージも合せて送ってください。これを見ると、UART のタイプや PPP のバージョンなど、カーネルのハードウェアに関するさまざ まな情報がわかります。 <p> 質問の際には、問題に関係すると思われる全ての情報を含めてください。といっ ても、ハードディスクの設定やターミナルの種類、マウスの接続法やボタンの 状況などなど、は不要です。重要なものは、あなたが接続しようとしている先 のシステム、すなわち彼らが使っている ppp (あるいはターミナルサーバー) の種類、モデムの種類とスピード等、です。 <p> 注意深く出力を眺めてください。使っている電話番号やあなたのアカウント名、 パスワードは削除してください。それらは問題を分析するためには無用ですし、 それらを usenet に投稿することはセキュリティ上の問題があります。加えて、 カーネルや pppd からのものではない出力も削除しましょう。 <p> <bf>決っして</bf> pppd を `<tt>kdebug 7</tt>' オプションで動かした結果 を投稿しないでください！ <p> もし問題がデータのやりとりだ、と確定できれば、その後は相手とメールのや りとりでお願いします。Usenet は既にあまりに多くの人々があまりに多くの ことを発言する場になっています。 <!-- If the problem warrants examining the data stream, then you will be contacted by email and asked to mail the trace. Usenet already costs too much for too many people. --> <p> 情報はさまざまなレベルで出力されます。デバッグ情報はデバッグレベルにあ わせて出力されます。インフォメーション・メッセージは info レベルにあわ せて出力されます。エラーはエラーレベルにあわせて出力されます。 <tt>pppd</tt> プロセスの `<tt>local2</tt>' というグループが出力するメッ セージは全て含まれるようにレベルを設定してください。 訳注：以下は PPP-Readme.linux よりの引用です。 <quote> もし接続でいないようなら、pppd からの 'debug' 情報をチェックしてくださ い。このためには pppd を 'debug' オプション付きで起動して、 /etc/syslog.conf ファイルに local2.* /dev/console local2.* /usr/adm/ppplog と書いておく必要があります。 </quote> <p> もう一点、タイムスタンプは削除しないように。この情報は重要です。 <p> <sect1>PPP サーバーのそれぞれの回線ごとに同じローカルな IP アドレスを使えますか？ <p> はい、可能です。ローカルのアドレスはローカルシステムにとって重要なもの ではありません。必要なのはユニークな <tt>remote</tt> の IP アドレスで す。経路制御はリモートの IP アドレスにしたがい、ローカルの IP アドレス は関係ありません。 <p> <sect>その他のインプリメント <p> <sect1>Linux 以外の PPP のインプリメントを御存知ですか？ HP-UX や AIX 、、などなどの PPP が欲しいんですが。 <p> 上述の comp.protocol.ppp に投稿されている PPP FAQ をご覧ください。 <p> AIX では pppd のバージョン 2.2 が利用可能です。HP-UX は、私の知る限り では、Morining Star 製の商用パッケージしかありません。 <p> リストに無い機種の場合、<tt>comp.protocols.ppp</tt> に質問してください。 Linux のニュースグループには投稿しないように。 <p> (私に "... 用の PPP パッケージを御存知ですか？" と聞かないでください。 この種の質問は `適切な方法で' 処理されます <tt>;-)</tt>) <p> <sect1>`<tt>dp</tt>' と呼ばれるプログラムをごぞんじですか？ <p> ええ、知っています。<tt>dp</tt> パッケージは数ヶ月前の時点では開発が始 まったばかりの段階でした。なかなか気のきいたプログラムで `動的発呼(必 要に応じて自動的にダイアルすること)'が可能です。ただし、streams をサポー トしたシステムでのみ利用可能で、最初のターゲットは SunOS(Solaris) になっ ています。 <p> Linux は、現時点では streams をサポートしていません。 <p> これら以外にもさまざまな PPP パッケージがネットワーク上に存在していま す。`portable ppp' パッケージは TIA 製のコードによく似ています。単に `ppp' と呼ばれているパッケージもあります。KA9Q のパッケージにも PPP の コードが入っています。 <p> これら全ての中で pppd がもっとも Linux に適した機能と仕様をもっていま す。 <p> (もし他のパッケージについて詳しく知りたければ、 <tt>comp.protocols.ppp</tt> グループで質問すること！) [訳注：IIJ-PPP を Linux に移植しようというプロジェクトが進行中で す。IIJ-PPP はトンネルデバイスを用いてユーザーレベルのみで PPP を実現 しており、動的発行やフィルタリングなども可能になっています。現在βテス ト中でもうすぐ一般公開されるはずです] <p> <sect1>PPP プロトコルについて説明している RFC は？ <p> 現在の PPP の実装はさまざまな RFC に基づいています。PPP の主要な部分は RFC 1331 と 1332 に従って書かれていますが、これらの RFC は現在では古い ものとなってしまいました。RFC 1331 は 1548 に取って代られ、6 ヶ月後に は、今度は 1661 が取って代りました。 <p> ほとんどの PPP の実装は幸いなことに Linux の PPP コードと通信 することができます。 <p> 完全なリストは PPP faq にあります。 <p> [FAQ を引用しますと ]: <p> <quote> 1134 と 1171, 1172(また、その件に関しては 1055 も <tt>:-)</tt>も古いも のになりました。これらの資料は、古い PPP との通信をデバッグして、疑問 を感じた時に参照する以上の利用価値はないでしょう。例えば、なぜ古い実装 では <tt>IPCP</tt> オプション 2 を 4 の長さで使い圧縮タイプは <tt>0x0037</tt> なのか、を説明しています。 (ただし、まだこれらの実装は結構動いています - 十分注意してください) </quote> <p> Linux の PPP は、このような古い実装はサポートしていません。 <p> <sect>互換性 <p> <sect1>PPP は SLIP インターフェースと通信できるでしょうか？ <p> いいえ、SLIP は SLIP と通信し、PPP は PPP と通信します。 <p> SLIP と PPP の両方で使える製品を出しているベンダーもあります。もっとも、 その場合でも起動時にどちらのモードを使うか設定する必要があります。現時 点では、接続時に SLIP を使っているか PPP を使っているかを、プロトコル として見分ける方法はありません。 <p> <sect1>PPP と SLIP のどっちがいいだろう？ <p> <bf>それには多くの要因が絡んでいます</bf>。 この種の質問をする人々は恐らく <tt>Net-2-HOWTO</tt> を読んでいません。 <p> 技術的な問題に関する良質の議論が Morning Star 社の www サーバー <tt>www.morningstar.com</tt> にあります。 <p> <sect1>認証には CHAP と PAP のどちらがいいですか？ <p> もし可能ならば CHAP を使いましょう。それがダメなら PAP です。PAP でも 無いよりはましです。 [訳注：CHAP(Challenge Handshake Authentication Potocol), PAP(Password Authentication Protocol), ともに RFC1333] <p> <sect>認証関係のファイル <p> <sect1> <tt>/etc/ppp/pap-secrets</tt> には何を書くべきでしょう？何かサンプルはありませんか？ <p> PAP プロトコルはあなたのユーザー名とパスワードを使うように実装されてい ます。このファイルには、リモートシステムの名前、あなたのアカウント名、 パスワードを書いておく必要があります。もし abbot というマシンのユーザー が costello というマシンに PPP で接続したいとすると、 <tt>/etc/pap/pap-secrets</tt> はこんな風になります。 <p> <tscreen><verb> #remote account password IP address list * abbot firstbase </verb></tscreen> <p> <sect1> <tt>/etc/ppp/chap-secrets</tt> ファイルには何を書くんでしょう？サンプ ルはありますか？ What goes into the <tt>/etc/ppp/chap-secrets</tt> file? Do you have a sample? <p> ほとんどの人が勘違いする点は、CHAP は対になったシークレットファイルが必要 だ、ということです。接続にかかわるコンピュータの双方に設定ファイルが必 要です。 例えば、もし abbot が <tt>costello</tt> と接続したければ、 <tt>abbot</tt> のファイルはこうなります。 <p> <tscreen><verb> #local remote secret IP address list abbot costello firstbase costello abbot who </verb></tscreen> <p> 一方、costello のファイルはこうなります。 <p> <tscreen><verb> #local remote secret IP address list abbot costello firstbase costello abbot who </verb></tscreen> <p> <sect>コンパイル時の問題 <p> <sect1>カーネルのコンパイル時にエラーが出るのですが、、 <p> Linux の 1.2 では、ppp ドライバはネットワークデバイスの標準ドライバに 組みこまれています。そのため、カーネルごとに PPP をサポートするために 必要なソフトウェアを組みこまなければなりません。カーネル附属の ppp ド ライバを修正することは止めてください。このドライバはカーネル用にあらか じめ設定されています。 <p> 1.2 以前のカーネルで ppp を使おうとしている場合、まずカーネルをアップ グレードすることを考えてください。1.0 のカーネルでは ppp ドライバを使 うためにパッチが必要です。1.2 のカーネルでは ppp をある程度サポートし ていますが、パッチレベルごとに修正も必要です。 <p> <sect>pppd を使う際の問題 <p> <sect1>ルート以外では <tt>PPPD</tt> が動かないのですが。 <p> pppd プロセスはネットワークシステムを変更する必要がありますが、これは ルートの権限がないと出来ません。もし、ルート以外のユーザーが <tt>pppd</tt> を動かす場合、pppd プログラムをルートに suid しておく必 要があります。このためには、以下のようにします。 <tscreen><verb> chown root pppd chmod 4755 pppd </verb></tscreen> もし特定のグループにのみ pppd を使わせたいなら、<tt>pppd</tt> プロセス をそのグループの所有にし、その他の人にはを使わせないようにします。 <sect1> <tt>ppp-2.1.2b</tt> パッケージを使うと、4.6 のライブラリが必要だ、と言うのですが。 <p> 残念ながらそうです。その場合、バイナリは捨てて、自前で再コンパイルする 必要があります。もっとも、再コンパイルはごく簡単です。pppd ディレクト リに移動して、バイナリを削除し、`<tt>make</tt>' するだけです。chat プ ログラムも直したければ、chat のディレクトリに移動して同じように再コン パイルします。 <p> もちろん、PPP を再コンパイルするには C コンパイラと GNU make が必要で す。 <p> 私が <tt>ppp-2.1.2b</tt> パッケージをコンパイルした時の設定では 4.6 ラ イブラリを使うことになってしまっていました。 <-- It turns out that when I compiled the <tt>ppp-2.1.2b</tt> package, while I used the proper definitions, I used the 4.6 libraries. One of these days, Al may finally get his act together . . . . --> <p> あるいは <tt>Slackware</tt> 2.0.2(以上)のパッケージに附属のバイナリを 使うこともできます。<tt>Slackware</tt> の場合、<bf>ppp.tgz</bf> は `n' シリーズに入っています。 <p> コンパイルの際には <tt>ppp-2.1.2b</tt> のソースコードを使ってください。 このソースは `<tt>a</tt>' パッケージに合わせて修正してあります。 <p> <sect1><tt>unable to create pid file: no such file or directory</tt>というメッセージが出ます。 <p> <tt>/var/run</tt> というディレクトリを作る必要があります。Slackware の 古いバージョンでは、このディレクトリは <tt>/etc</tt> にシンボリックリ ンクされていました。 <p> このメッセージはエラーメッセージではなく、ワーニングです。このメッセー ジが出ても ppp は正常に動くはずです。しかし、<tt>ppp-off</tt> スクリプ トは <tt>ppp.pid</tt> を見て終了させるべきプロセスを判別するので、 <tt>/var/run</tt> ディレクトリを作るか、どこか適切なディレクトリへリン クを張っておくのがいいでしょう。 <p> posix のヘッダーを定義している <tt>paths.h</tt> では、pid ファイルの場 所を "<tt>_VAR_RUN</tt>" で定義しています。もし PPP やその他 pid を利 用するソフト全般で違うディレクトリを使いたければ、<tt>_VAR_RUN</tt> の 定義を変更してコンパイルし直すのがいいでしょう。 [訳注：HOWTO では <tt>_VAR_RUN</tt> となっていますが、手元のソースファ イル(1.2.7)を見たところ <tt>_PATH_VARRUN </tt> となっていました] <p> <sect1><tt>/etc/ppp/options: no such file or directory</tt>というメッセージが出力されます。 <p> <tt>/etc/ppp</tt> ディレクトリを作り、`<tt>options</tt>' というファイ ルをそのディレクトリに置いておく必要があります。このファイルは <tt>pppd</tt> プロセス(ルート)から読めないといけません。 <p> このファイルは空っぽでもいいので、`<tt>touch</tt>' コマンドで作ること も可能です。 <p> このファイルについての詳細は <tt>pppd</tt> の man ページ、 <tt>pppd.8</tt> をご覧ください。 <p> <sect1><tt>Could not determine local IP address</tt>というメッセージが出ます。 <p> このメッセージは Telebit 社の Netblazer を使っている場合によく見られま す。問題はターミナルサーバー自体ではなく、ターミナルサーバーに正しく IP アドレスを複数設定していないサイトにあります。 <p> Netblazer はあなたの IP アドレスを知らないし、あなたも与えられる IP ア ドレスがわかりません。両者の IP アドレスがわからないと接続できません。 <p> まず、紙を用意して両者の IP アドレスをメモします。まず Netblazer に使 うべき IP アドレスを教えないといけません。これには、ローカルとリモート の IP アドレスを pppd に渡すパラメータとして与えます。 <p> そのためには pppd にこんなフォーマットのオプションをつけます。 <p> local_ip:remote_ip <p> (すなわち、ローカルの IP アドレスを書いて、コロン(:)でくぎり、リモート の IP アドレスを書きます) <p> <sect1><tt>Could not determine remote IP address</tt> <p> 上記の質問を見てください。 <p> <sect1>マジックナンバーが拒否された、というメッセージが常に出て、接続できません。 <p> 2 つ のシステムが同じマジックナンバーを選ぶ確率は 400 万分の 1 以下で す。もし常にマジックナンバーがらみの失敗をするようならば、とてもまぐれ 当りの結果だとは思えません。 <p> このエラーが出るもっとも一般的な 2 つの原因は： <p> <itemize> <item> 起動しているはずのリモート側の ppp ソフトウェアが動いていない場合。リ モートシステムは正しく PPP を動かすように設定されていますか？ ppp のプ ロセスは正しい場所にありますか？あなたが動かせるような設定になっていま か？ <p> このエラーのよくある原因は、シェルがデータをエコーバックしていることです。 <p> <item> リモート側に接続してログインしようとするやいなや、モデムが接続 断になっている場合。ほとんどのモデムは、送ってこられたデータをエコーバッ クするようになっています。そのため、送ったデータがそのままモデムからロー カルにエコーバックされてしまいます。 <p> </itemize> どちらの場合でも、Linux システムがリモートへと送ったデータがそのままシ リアル回線に送りかえされています。これはいわゆる"<tt>loop</tt>"した状 態です。 <p> <sect1><tt>protocol reject for protocol fffb</tt> というメッセージが出ます。 <p> このエラーは Xyplex 製のターミナルサーバーを使っているときに起きるよう です。Xyplex 社によると、同社のターミナルサーバーソフトのバージョン 5.1 は、PPP との接続に多くの問題をかかえているそうです。少なくともバー ジョン 5.3 にバージョンアップしてください。 <p> もしバージョン 5.1 を使わざるを得ない場合、pppd に "<tt>vj-max-slots 3</tt>" というオプションを付けてスロット数を 3 に制限します。Xyplex の サーバーの問題点は、pppd がデフォルトで送る 16 個のスロットのリクエスト に答えるくせに 3 つ以上のスロットを処理できないところにあります。本来 ならば NAK フレームを返すべきなのですが、そうしません。 あるいは、"<tt>-vj</tt>" オプションを使って Van Jacobson ヘッダー圧 縮を使わないようにする手もあります。 <p> <sect1>PPP ソフトはつながりフレームもいくつか送っているようですが、それでもネットワークにつながったようには見えません。いったい何故？ <p> "<tt>debug</tt>" オプションを付けて出力されるシステムログを検討する必 要があります(いずれにしても、質問する際にはシステムログを検討する必要 があります)。データのやり取りを追跡して <tt>LCP</tt> リクエストを繰り かえし送っているけれど、その識別ナンバーが増えない、という場合はリモー トの PPP ソフトウェアとフレームのやり取りができていません。 <p> これには 3 つの原因が考えられます。 <itemize> <item> もう一方の端(リモート側)で ppp ソフトが動いていないこと。PPP フレームを、 多分 "こりゃ何じゃ？ #$%ˆ だって？"と言っている プログラムに送りつけているんでしょう。 <p> ppp プロトコルをやり取りし始める前に、リモート側で ppp ソフトが動いて いることを確認してください。普通の通信ソフトを使って、普通の方法で login してみてください。ppp フレームが送られてきていますか？ <p> ppp フレームは一目でわかります。それぞれは 16 文字で、複数の <tt>{</tt>を含んでいます。改行コードは無く、16 文字が断続的に送られて きます。 <item> 回線が "8 ビットクリーン" でないこと。PPP を使うには 8 ビッ トのデータでパリティ無し、ストップビット 1 の回線が必要です。 <p> pppd は自動的に回線を 8 ビット、パリティ無し、1 ストップビットに設定し ます。リモート側も同様の設定になっていないとフレームやパリティのエラー が起ることになります。 <p> PPP はキャラクターをエスケープして送ることもできますが、kermit のよう に複数のビットをエスケープすることはできません。PPP は 7 ビットしか通 さない回線では利用 <em>できません</em>。 <p> ppp.c ドライバ(カーネルに附属しています)には <bf>CHECK_CHARACTERS</bf> と呼ばれるオプションがあり、入力されるキャラクタをより厳密にチェックす ることが可能です。このオプションを指定すると、パリティが設定されている かどうかやリモートシステムが 7 ビットキャラクターを送りつづけているの かなどをチェックすることができます。 <item> リモートは <tt>PAP</tt> か <tt>CHAP</tt> の認証を求めており、ローカル ではその設定をしていない場合。この場合、リモート側は、正しい認証用のフ レームが送られるまで全てのフレームを捨ててしまいます。ローカルでは認証 を使う設定になっていないので、送られる <tt>IPCP</tt> フレームは全て捨 てられてしまいます。 <p> この場合、リモート側で認証を使わないように設定するか、ローカル側で正し く認証を発行するように各種のファイルを設定する必要があります。 <p> 受け取った LCP 設定フレームを調べてみてください。'auth' というタイプに なっていれば、リモートは認証機能を設定しています。 </itemize> <sect1>merit ネットワークに接続できません。 <p> merit ネットワークのユーザーに聞いたところによると、PAP が必要だそうで す。PAP の設定をしていますか？ <p> <sect>DIP <p> <sect1>DIP が PPP モードをサポートしていないのですが。 <p> 最新バージョンの dip-uri は `mode ppp' を指定して pppd プロセスを起動 するようにした場合、PPP をサポートします。pppd を正しく動かた めには多くのオプションが必要ですが、dip はこれらをプログラムへ渡すこと ができないため、オプションは全て /etc/ppp/options ファイルに設定する必 要があります。 <p> dip プログラムは slattach, ifconfig, route の助けを借りて SLIP リンク の確立をコントロールします。これらのプログラムは SLIP リンクには使いま が PPP リンクには役に立ちません。 <p> dip プログラムはリモートシステムに電話をかけて <tt>ppp</tt> ソフトを起 動するのに使えるかも知れません。この方法で使うには `<tt>connect</tt>' オプションを指定するのがいいでしょう。しかし、dip を使って接続するため にはいろいろなオプションが必要です。 <p> <sect>プロセスの終了法 <p> <sect1>PPP では `<tt>dip -k</tt>' は使えますか？ <p> いいえ、`<tt>dip -k</tt>' は使えません<p> chat のディレクトリの中に `<tt>ppp-off</tt>'というスクリプトがあり、こ のスクリプトが `<tt>dip -k</tt>' 同様に ppp 接続の終了に使えます。 <p> このスクリプトは以下の通りです(切り出して、適切な名前にセーブし、chmod を使って実行可能にしてください) <p> <code> #!/bin/sh DEVICE=ppp0 # # If the ppp0 pid file is present then the program is running. Stop it. if [ -r /var/run/$DEVICE.pid ]; then kill -INT `cat /var/run/$DEVICE.pid` # # If the kill did not work then there is no process running for this # pid. It may also mean that the lock file will be left. You may wish # to delete the lock file at the same time. if [ ! "$?" = "0" ]; then rm -f /var/run/$DEVICE.pid echo "ERROR: Removed stale pid file" exit 1 fi # # Success. Let pppd clean up its own junk. echo "PPP link to $DEVICE terminated." exit 0 fi # # The ppp process is not running for ppp0 echo "ERROR: PPP link is not active on $DEVICE" exit 1 </code> <sect1>PPP が終了した時にモデムが切れないんですが。 <p> これにはいくつかの理由が考えられます。 <itemize> <item> pppd に `<tt>modem</tt>' パラメーターを渡していますか？ このパラメータを指定することで <tt>pppd</tt> に制御しているものがモデ ムであると認識させ、モデムの状況を知らせる信号を解釈できるようになりま す。このパラメータについての詳細は <tt>pppd</tt> の man ページをご覧く ださい。 <item> モデムの設定が、DCD と DTR を理解するになっていますか？ Hayes 系のモデムでは "&C1" を送ることでこの設定になります。もし モデムの初期化に "ATZ" を送ってモデムをリセットしているなら、正しく DCD と DTR を認識できるようになっているかチェックしてください。 <p> DTR 信号はコンピュータから送られ、モデムに接続断を指令します。 Hayes 系のモデムでは、DTR を認識するためには "&D1" か "&D2" をいうコ マンドを送る必要があります。PPP の設定には "&:D2" の方が望ましいで しょう。多くのモデムでは、"工場出荷時の設定"のままでは DTR を認識しない 設定になっています。 <item>DCD 信号を通さないような安物のケーブルを使っていませんか？マッキ ントッシュ"クラッシック"ではこの信号を使わないため、"クラッシック"用の ケーブルはこの信号を通さないことで有名です。 <item> 外から電話を受けて接続する場合、pppd プロセスを正しくスクリプトから実 行していますか？ pppd は、それ自身ではなく、何らかのスクリプトから実行される必要があり ます。もし pppd を直接実行すると、pppd 自身がシェルとして振舞ってしま い、SIGHUP の信号を受けても自分自身で処理して、pppd を終了させることに はなりません。 <p> `シェル'として実行すべきスクリプトはこのようなものです。 <code> #!/bin/sh exec pppd -detach modem ... </code> </itemize> <sect>データ転送に関わる問題 <p> <sect1><bf>ftp</bf> を使って、ファイルを `put' しようとすると失敗します。`get' する時は大丈夫なんですが？ <p> フロー制御を使っていますか？ フロー制御を使うには、pppd に <tt>crtscts</tt>(RTS/CTS の場合)、あるいは <tt>xonxoff</tt>(XON/XOFF の場合)というオプションを付けます。フロー制御を使わなかった場合、多分 モデムのバッファーがあふれて、vj ヘッダー圧縮に悪影響を及ぼします。 <p> <sect1>フロー制御を XON/XOFF で行うには？ <p> CTS/RTS の方がいいフロー制御なんですが、CTS/RTS を使ったハー ドウェアフロー制御ができない場合などは XON/XOFF を使うしかありません。 このためには以下のようにします。 <itemize> <item> pppd に <tt>xonxoff</tt> オプションを付けます。こうすれば pppd がシリアルデバイスを XON/XOFF フロー制御を使うように設定して、2 つのキャ ラクタを tty ドライバにロードします。 <item> 次に、XON と XOFF を示すキャラクタを定義します。このキャラクタ は、pppd の <tt>asyncmap</tt> というオプションのパラメータとして渡しま す。こうすれば、リモートシステムもこれらのキャラクタを送りたいときには クオートするようになります。pppd のパラメータとして、普通は `<tt>asyncmap</tt> <bf>a0000</bf>' を指定します。 <item> もちろん、モデムにも XON/XOFF 制御を使うように設定することをお 忘れなく。私の使っている <tt>ZyXEL</tt> モデムでは `&R1&H4' と します。 </itemize> <sect1>モデムがいつも奇妙な速度で接続するようです。minicom を使っている時はちゃんと 14400 で接続するんですが、PPP を使うと 9600 や 7200、ひどい時には 2400 になります。どうすればうまくいくんでしょう？ <p> pppd プロセスを起動するコマンドに使いたい速度を記述します。もし速度の 記述がないと、pppd は接続した時のレートをそのまま使います。全てのプロ グラムが、終了時に各種のパラメータを復旧するわけではないので、pppd が 使う前にシリアルデバイスにおかしな設定が残っていることがあります。 <p> <sect1>proxyarp 機能がハードウェアアドレスを見つけられません。 <p> <tt>ppp-2.1.2b.tar.gz</tt> パッケージを使ってください。古い <tt>pppd</tt> は 1.1.8 カーネルで誤ってコンパイルされており、 <tt>Net-2</tt> の定義ではなく、<tt>Net-3</tt> の定義を使っていました。 <p> また、proxy-ARP を使う際の設定については、proxy-ARP の mini-HOWTO を参 照してください。 <p> <sect>経路制御とその他の問題 <sect1>リモートへの経路が見えなくなりました！3 分間ほどは見えてたんですが、その後なくなっちゃいました。助けて！ <p>これは PPP の問題ではありません。 <p> ヒント：<bf> <tt>routed</tt> を起動してはいけません！</bf> <p> <sect1>リモートサーバーには接続できるんですが、そこから先へは行けません。 <p>pppd に`<tt>defaultroute</tt>' パラメータを付け忘れてませんか？この パラメータを付けることで、あなたのコンピュータの経路制御システムにデフォ ルト値が指定され、(自分自身へのものを除く)全ての IP アドレス宛てのパケッ トが PPP デバイスへ送られるようになります。 <p> もし pppd を動かした時に経路制御のデフォルト値が設定されていたら、PPP はそれを変更しません。これは、デフォルトの経路はイーサネットにしている 人が間違って変更してしまわないための処置です。この理由で defaultroute パラメータが働かなった場合、システムログにメッセージが残ります。 <sect1>デフォルトの経路はあるんですが、それでも外へ出れません。今度は何でしょう？ <p>その場合、問題はローカルの Linux システムにはありません。多分リモー ト側の経路制御の問題でしょう。 <p> 恐らくリモートシステムが `<tt>IP forwarding</tt> するように設定されて いないのでしょう。RFC によると、このオプションはデフォルトでは設定<bf> しない</bf>べきだ、とされています。PPP を使うためには、このオプション を使うように設定する必要があります。Linux の場合、カーネルを config す る際に IP forwarding/gatewaying を使うかどうか聞かれますので、これを Y にします。 <p> あなたのシステムからリモートコンピュータに経路が必要なように、リモート コンピュータからもあなたのシステムへの経路(route back)が必要です。この ためには 4 つの方法があり、そのうちの 1 つを選ぶのですが、それぞれに利 点と制限があります。以下の 4 つの中からどれか一つだけを選ぶ必要があり ます。 [訳注：以下の方法については、訳者が理解できていないので、原文も付 けておきます。間違いなどを指摘していただければ幸いです。] <itemize> <item>ホストの経路定義(host route)を使う方法。ローカルからのアクセスに 使っているターミナルサーバーをゲートウェイとして、リモートシステムの各ホ ストそれぞれにあなたの Linux の IP アドレスを登録する方法です。この方 法はホストシステムが小さくて、ブリッジやルーター、ゲートウェイなどを使っ ていない単純な構成の時にのみ使えます。 Use a host route. At each host on the remote system, add a host route to your Linux IP address with the gateway being the terminal server that you use for your local access. This will work if you have a small number of host systems and a simple network without bridges, routers, gateways, etc. <item> ネットワークの経路定義(network route)を使う方法。リモートの IP アドレスを分割して、あなたの使っているローカルの Linux の IP アドレス とリモートのターミナルサーバーのアドレス、リモートのターミナルサーバー のイサーネットアドレスが同じ IP ドメインになるように設定します。この方 法は IP アドレスに余裕がある時にしか使えませんが、Class-B の IP ドメイ ンで、全てのリモートのアドレスを同じ IP ドメインに設定できる場合に有効 です。この場合、それぞれのゲートウェイとルーターにネットワークの経路定 義を設定して、外部のネットワークのアドレス宛ての全てのパケットがターミ ナルサーバーへ送られるようにします。この方法は、ホストは多数あるが、ルー ターは少ない場合に有効です。(<tt>sii.com</tt> では 300 のホストシステ ムをたった 3 つ のルーターで使っています) Use a network route. Subdivide the remote IP addresses so that your local Linux IP address and the remote terminal server address and the remote terminal server's ethernet address is on the same IP domain. This will work if you have the IP addresses to spare. It will work very well if you have a Class-B IP domain and can afford to put the all of the remote addresses on the same IP domain. Then add a network route on each of the gateways and routers so that any address of the remote network is sent to the terminal server. Most configurations have many hosts but few routers. (At <tt>sii.com</tt>, we have over 300 active host systems with only 3 routers.) <item> 全てのターミナルサーバーとゲートウェイで <tt>gated</tt> を使う 方法。こうすれば、ターミナルサーバーが、あなたの IP アドレス向けのパケッ トを受けとる、とブロードキャストします。各ホストはゲートウェイの一つへ デフォルトの経路を持っているはずなので、ゲートウェイは ICMP リダイレク トフレームを生成して、特定のホストがその経路制御に自動的に付けくわえま す。 Use <tt>gated</tt> on all of the gateways and on the terminal server. This will cause the terminal server to broadcast to the gateways that it can accept the frames for your IP address. Since the hosts will have a default route to one of the gateways, the gateways will generate the ICMP re-direct frame and the specific host will automatically add its host route. <item> ターミナルサーバーで代理 ARP を使う方法。この方法は、リモートの IP アドレスがネットワークカードの持っているドメインの一つのように、同 じ IP ドメインに入っている時にのみ有効です。 Use proxy ARP on the terminal server. This will only work if your remote IP address is in the same IP domain as one of the domains for the network cards. </itemize> これには明確な正解はありません。どれか一つを選んでください。 <p> <sect1>(/etc/hosts で定義した)ローカルの IP アドレスに ping できないんですが。 <p> (/etc/hosts に書いてあるような)自分のローカルアドレスへの経路は定義さ れていないので ping することはできません。これは普通の状態なので /etc/hosts に書いてある自分の IP アドレスへは ping しないでください <p> もし自分自身へ ping したい時は 127.0.0.1 のループバックアドレスを使い ます。 <p> リモートアドレスへは ping できるかも知れませんが、ある種のターミナルサー バーは、そのアドレスを 'いんちき(phony)' だとして許可しません。これら は環境に依存します。 <p> 概して、ローカルとリモートのアドレスの双方には ping しないようにしてくだ さい。ネームサーバーのアドレスのような、リモートネットワーク上の第 3 のアドレスを選んでください。 <p> <sect>他の PPP の実装との通信 <p> <sect1><tt>MSDOS</tt>用の <tt>Trumpet</tt> を使っていますが、接続できません。どうしてでしょう？ <p> <tt>Trumpet</tt> は VJ ヘッダー圧縮を受けつけません。 pppd に "<tt>-vj</tt>"オプションを指定してヘッダー圧縮をしないようにし てください。 <p> <sect1><tt>SunOS</tt> で <tt>dp-3.1.2</tt>を使っていますが、<tt>ping</tt> と <tt>nslookup</tt> しかできません。どうして？ <p> dp の <bf>3.1.2</bf> にはバグがあります。<bf>3.1.2a</bf> あるいは、そ れよりも新しいものを使ってください。dp のプライマリ・サイトは <tt>harbor.ecn.purdue.edu</tt> です。dp へのパッチを入手するまでは、vj ヘッダー圧縮を使わないようにしてください。 <p> <sect1>Windows NT('Daytona')と接続できません。 <p> Microsoft は Windows NT で標準的でない認証プロトコルを選びました。 そうするのは彼らの勝手で、彼らはそのプロトコルを <tt>IANA</tt> として 登録しました。もし、phone book のエントリで、`accept only Microsoft encryped authentication' がチェックされていれば、接続はできません。こ の設定は Daytona が別の Microsoft の PPP とのみ PPP の認証をやりとりで きるようにするものです。 <p> Linux はこの認証方式をサポートしていません。 <p> もし、Daytona システムの設定を変えられるなら、Daytona の Phone Book の 設定に入って、security settings に入り、'Accept any authenticaion including clear text' を指定して、認証なしの接続を許可するか、'Use clear text terminal login only' を指定して PAP 認証をするか、`Accept only encrypted authentication' を指定して CHAP 認証をするかします。 <p> 普通の PAP はパスワードを平文で送りますが、Microsoft の認証方式は パス ワードを彼ら独自の暗号化アルゴリズムを使って暗号化しています。パスワー ドを平文で送ると、彼らが Daytona で目指している C2 セキュリティのレベ ルを維持できなくなります。 <p> <sect>システムのログファイルに記録されるその他のメッセージ <p> <sect1><tt>Alarm</tt> <p> これは特に問題というわけではありません。接続時に時間切れになったか、プ ロトコルが確立する時点でタイマーが必要であることを意味しています。 <!-- This is not a problem. It means that a timer has expired and timers are a necessary part of the protocol establishment phase. --> <p> <sect1><tt>Unknown protocol (c025) received!</tt>. <p> リモートのシステムは接続品質(Link Quality)についてのレポートを交換しよ うとしています。このプロトコルは現時点では実装されていません。これはエ ラーではありません。単に、接続品質についてリモートのホストからレポート することを要求され、「今はまだ出来ないので、気にしないでください」と返 事しているだけです。 <p> Morning Star 製の PPP は常に LQR プロトコルを試そうとするため、このメッ セージがよく見られますが、これは問題ではありません。 <p> <sect1>接続が <tt>ioctl(TIOCSCTTY)</tt> エラーで切れてしまう。 <p> <tt>ppp-2.1.2b.tar.gz</tt> を使ってください。このバグは '<tt>a</tt>' の段階では見つかっていませんでした。 <p> <sect1>接続が"<tt>ioctl(TIOCGETD): I/O error</tt>" あるいは "<tt>ioctl(PPPIOCSINPSIG): I/O error</tt>" といって失敗します。これはどういう意味でしょう？ <p> カーネルを起動した時のメッセージを見てみてください。もし "<tt>PPP version 0.1.2</tt>" と出ていたら、古いバージョンの <tt>ppp.c</tt> ドラ イバを使っています。 <p> もし、"<tt>PPP version 0.2.7</tt>" と出ていれば新しいドライバを使って いますが、正しい ioctl の設定でコンパイルされていないようです。 "<tt>ppp.h</tt>" と言うファイルが一つしか存在しないことを確認してくだ さい。このファイルはカーネルの <tt>include/linux</tt> ディレクトリにあ るはずです。確認した上でカーネルと pppd プロセスをコンパイルしなおして ください。 <p> <p> <sect1>時々、"<tt>ioctl(PPPIOCGDEBUG): I/O error</tt>" や "<tt>ioctl(TIOCSETD): I/O error</tt>" 、 "<tt>ioctl(TIOCNXCL): I/O error</tt>" というエラーが起きます。どうして？ <p> リモートシステムが電話の接続を切っているようです。tty ドライバは接続が 切れると tty のやり方で接続を回復しようとしますが、<tt>pppd</tt> プロ セスもまた接続を回復しおうとします。このエラーは両者が接続を回復しよう とした結果生じます。 <p> <sect1><tt>ifconfig</tt> が PPP について奇妙な出力をするんですが？ <p> 通常、ifconfig の出力はこんな感じのものになります。 <p> <tscreen><verb> ppp0 Link encap UNSPEC HWaddr 00-00-00-00-00-00-00 ... inet addr 192.76.32.2 P-t-P 129.67.1.65 Mask 255.255.255.0 UP POINTOPOINT RUNNING MTU 1500 Metric 1 </verb></tscreen> この情報は表示にのみ使われています。もし、1.2 のカーネルを使っているなら、 <tt>sunacm.swan.ac.uk</tt> の <tt>/pub/Linux/networking/nettools</tt> にある新しい nettools を使ってください。 <p> <sect1><tt>/proc/net/dev</tt> ファイルが空のようなんですが？ <p> "<tt>ls -l /proc/net</tt>" としてサイズが 0 だ、と悩んでいるのではあり ませんか？もし、そうならば、サイズが 0 で正常です。ls の代りに <p> cat /proc/net/dev <p> としてみてください。こうすればファイルには何かが入ってることがわかるで しょう。ls で見るとサイズは 0 になりますが、それは 'proc' ファイルシス テムの特徴です。サイズは気にしないでください。 <p> `more' や `less'、`most' といったプログラムではファイルを直接見ること はできません。もしこれらのプログラムを使いたければ、 <p> cat /proc/net/dev | less <p> としてください。 <p> <sect>ネットワークの経路制御(routing)の問題(PPP を安価なブリッジとして使う方法) <p> <sect1><tt>Slattach</tt> や <tt>ifconfig</tt> が SLIP の時のように動かないんですが？ <p> PPP では <tt>slattach</tt> や <tt>ifconfig</tt> を使ってはいけません。 これらは SLIP 用です。<tt>pppd</tt> プロセスは、これらのプログラムが行 なっていた機能を必要な時に実行することができます。PPP では、 <tt>LCP</tt> と <tt>IPCP</tt>プロトコルを交換した後に、これらを行なう 必要があります。 <p> <tt>pppd</tt> を <tt>slattach</tt> や <tt>ifconfig</tt> と入れ替えるこ とはできません。PPP のためのほとんどのプロトコルは <tt>pppd</tt>が担当 しています。IP (と<tt>IPX</tt>が指定されていれば)を扱う部分のみがカー ネルに入っています <p> リモートシステムのホストへの経路は pppd によって自動的に追加されます。 この経路を付け加えない、というオプションはありあせん。もしリモートシス テムのホストへの経路が追加できない時、pppd プロセスは終了します。 <p> デフォルトの経路は`<tt>defaultroute</tt>'オプションによって加えられた り加えられなかったりします。もし既にデフォルトの経路が設定されていれば、 新たに変更されることはありません。 <p> もし、ネットワーク全体の経路を制御しなければならないなら、 <tt>/etc/ppp/ip-up</tt> スクリプトに route コマンドを付け加えてくださ い。このスクリプトのパラメータは、 <tscreen><verb> $0 - スクリプトの名前(/etc/ppp/ip-up あるいは /etc/ppp/ip-down) $1 - ネットワークデバイスの名前(例えば ppp0) $2 - tty デバイスの名前(/dev/cua0 など) $3 - tty デバイスのスピード(bps 単位、38400 など) $4 - ドットで区切られたローカル IP アドレスの 10 進表示 $5 - ドットで区切られたリモート IP アドレスの 10 進表示 </verb></tscreen> <sect1>ホストではなくネットワークに経路を通したいのですが。 <p> <tt>sunsite</tt> に <tt>devinfo.tar.gz</tt> と呼ばれるファイルがありま す。このファイルにはデバイスからデータを取りだしたり、ドットで区切った 形の IP アドレスに対していろいろな操作を行う小さなプログラムが集められ ています. <p> ドキュメントも man ページとしてファイルに含まれています。 <p> 例えば、全ての IP ドメインをリモートに通したい時は、 <tt>/etc/ppp/ip-up</tt> が役に立ちます。 <!-- For example, if you want to route the entire IP domain to the remote, the following may be used in <tt>/etc/ppp/ip-up</tt>. --> <p> もちろん、IP アドレスが変らなければ、route コマンドに適切なエントリを 付け加えるだけですみます。 <!-- Of course, if the values are not variable, then simply use the appropriate entry in the route command. --> <code> # Obtain the netmask for the ppp0 (or whatever) device NETMASK = `devinfo -d $1 -t mask` # Obtain the IP domain (without the host address by removing the extra bits) DOMAIN = `netmath -a $5 $NETMASK` # Do the network route now that the IP domain is known route -net add $DOMAIN gw $5 </code> <sect>その他の機能とプロトコル <p> <sect1>`<bf>動的発呼(demand dial)</bf>' はどうなっていますか？ <p> <bf>diald</bf> パッケージを使ってください。このプログラムも、sunsite の ppp の同じディレクトリ <tt>/pub/Linux/system/Network/serial</tt> に あります。 <p> <sect1>`<bf>フィルタリング</bf>' は？ <p> PPP のコードにフィルタリングを加える計画はありません。 <tt>ipfirewall</tt> を使ってください。このプログラムも <tt>sunsite</tt> にあります。ぜひデバッグに協力してください。このプロ グラムがフィルタリングに関する一般的な答えになるでしょう。 <p> 最新のカーネルにはフィルタリングのためのパッチが入っています(それでも IP フィルタリングには ipfirewall のプログラムが必要です。カーネルには ipfirewall を使うためのパッチがはいっているに過ぎません)。繰り返します が、フィルタリングはネットワークの問題であり、PPP にのみ関係するもので はありません。 <p> <sect1><tt>IPX</tt> はどうなっているの？ <p> <tt>IPX</tt> をサポートしようとする試みは進行中です。 <p> <sect1>NETBIOS については？ <p> netbios には PPP プロトコルがありません。より良い解決法は TCP/IP プロ トコルと `<tt>samba</tt>'プログラムを使うことです。 <p> マイクロソフトなどは Netbios 上の PPP プロトコルを使っていますが、これ は著作権で保護されたプログラムを追加したものであり、異なるベンダー間の 接続も保証されていません。 <p> Netbios のプロトコルについては誰かにおまかせまします。もしマイクロソフトの 従業員が彼らの PPP の仕様をパブリックドメインにして、PPP を Netbios に 実装したいなら、diff を私に送ってください。将来のリリースに取りこむこ とを約束します。 <p> <sect1>ISDN を使いたいんですが？ <p> ISDN については、現在開発が進行中の ISDN ドライバと共に開発が進んでい ます。ppp ドライバの現在のデザインは、データをブロック単位で受けとる にはあまりうまくありません。この点に関しては変更される予定です。Sonix インタフェースというドライバが現在開発中です。 <p> <sect1>同期 PPP(standard synchoronous PPP)については？ <p> 同期通信を使うためにはシリアルインタフェースに小さな変更が必要です。 ppp ドライバの再設計もいいでしょう。Kate Marika Alhola が同期ドライバ を彼女のハードウェア用に書こうとしています。詳しくは kate@digiw.fi に直接連絡してみてください。 <p> <sect>その他もろもろ <p> <sect1>PPP 互換のメールリーダーはありますか？ <p> ？？？もし、MSDOS 用の物が必要なら、このニュースグループは不適切です。 PPP はMUA(mail user agent)とは関係ありません。全ての MUA は PPP を利用 できます。 <p> <sect1>ニュースリーダーについては？ <p> 上と同じ。 <p> </article>