PPPD が動かないのですが。 pppd プロセスはネットワークシステムを変更する必要がありますが、これは
ルートの権限がないと出来ません。もし、ルート以外のユーザーが
pppd を動かす場合、pppd プログラムをルートに suid しておく必
要があります。このためには、以下のようにします。
chown root pppd
chmod 4755 pppd
もし特定のグループにのみ pppd を使わせたいなら、pppd プロセス
をそのグループの所有にし、その他の人にはを使わせないようにします。
ppp-2.1.2b パッケージを使うと、4.6 のライブラリが必要だ、と言うのですが。 残念ながらそうです。その場合、バイナリは捨てて、自前で再コンパイルする
必要があります。もっとも、再コンパイルはごく簡単です。pppd ディレクト
リに移動して、バイナリを削除し、`make' するだけです。chat プ
ログラムも直したければ、chat のディレクトリに移動して同じように再コン
パイルします。
もちろん、PPP を再コンパイルするには C コンパイラと GNU make が必要で す。
私が ppp-2.1.2b パッケージをコンパイルした時の設定では 4.6 ラ
イブラリを使うことになってしまっていました。
<--
It turns out that when I compiled the ppp-2.1.2b package,
while I used the proper definitions, I used the 4.6 libraries. One of
these days, Al may finally get his act together . . . .
-->
あるいは Slackware 2.0.2(以上)のパッケージに附属のバイナリを
使うこともできます。Slackware の場合、ppp.tgz は `n'
シリーズに入っています。
コンパイルの際には ppp-2.1.2b のソースコードを使ってください。
このソースは `a' パッケージに合わせて修正してあります。
unable to create pid file: no such file or directoryというメッセージが出ます。 /var/run というディレクトリを作る必要があります。Slackware の
古いバージョンでは、このディレクトリは /etc にシンボリックリ
ンクされていました。
このメッセージはエラーメッセージではなく、ワーニングです。このメッセー
ジが出ても ppp は正常に動くはずです。しかし、ppp-off スクリプ
トは ppp.pid を見て終了させるべきプロセスを判別するので、
/var/run ディレクトリを作るか、どこか適切なディレクトリへリン
クを張っておくのがいいでしょう。
posix のヘッダーを定義している paths.h では、pid ファイルの場
所を "_VAR_RUN" で定義しています。もし PPP やその他 pid を利
用するソフト全般で違うディレクトリを使いたければ、_VAR_RUN の
定義を変更してコンパイルし直すのがいいでしょう。
[訳注：HOWTO では _VAR_RUN となっていますが、手元のソースファ
イル(1.2.7)を見たところ _PATH_VARRUN となっていました]
/etc/ppp/options: no such file or directoryというメッセージが出力されます。 /etc/ppp ディレクトリを作り、`options' というファイ
ルをそのディレクトリに置いておく必要があります。このファイルは
pppd プロセス(ルート)から読めないといけません。
このファイルは空っぽでもいいので、`touch' コマンドで作ること
も可能です。
このファイルについての詳細は pppd の man ページ、
pppd.8 をご覧ください。
Could not determine local IP addressというメッセージが出ます。 このメッセージは Telebit 社の Netblazer を使っている場合によく見られま す。問題はターミナルサーバー自体ではなく、ターミナルサーバーに正しく IP アドレスを複数設定していないサイトにあります。
Netblazer はあなたの IP アドレスを知らないし、あなたも与えられる IP ア ドレスがわかりません。両者の IP アドレスがわからないと接続できません。
まず、紙を用意して両者の IP アドレスをメモします。まず Netblazer に使 うべき IP アドレスを教えないといけません。これには、ローカルとリモート の IP アドレスを pppd に渡すパラメータとして与えます。
そのためには pppd にこんなフォーマットのオプションをつけます。
local_ip:remote_ip
(すなわち、ローカルの IP アドレスを書いて、コロン(:)でくぎり、リモート の IP アドレスを書きます)
Could not determine remote IP address 上記の質問を見てください。
2 つ のシステムが同じマジックナンバーを選ぶ確率は 400 万分の 1 以下で す。もし常にマジックナンバーがらみの失敗をするようならば、とてもまぐれ 当りの結果だとは思えません。
このエラーが出るもっとも一般的な 2 つの原因は：
このエラーのよくある原因は、シェルがデータをエコーバックしていることです。
loop"した状
態です。
protocol reject for protocol fffb というメッセージが出ます。 このエラーは Xyplex 製のターミナルサーバーを使っているときに起きるよう です。Xyplex 社によると、同社のターミナルサーバーソフトのバージョン 5.1 は、PPP との接続に多くの問題をかかえているそうです。少なくともバー ジョン 5.3 にバージョンアップしてください。
もしバージョン 5.1 を使わざるを得ない場合、pppd に "vj-max-slots
3" というオプションを付けてスロット数を 3 に制限します。Xyplex の
サーバーの問題点は、pppd がデフォルトで送る 16 個のスロットのリクエスト
に答えるくせに 3 つ以上のスロットを処理できないところにあります。本来
ならば NAK フレームを返すべきなのですが、そうしません。
あるいは、"-vj" オプションを使って Van Jacobson ヘッダー圧
縮を使わないようにする手もあります。
"debug" オプションを付けて出力されるシステムログを検討する必
要があります(いずれにしても、質問する際にはシステムログを検討する必要
があります)。データのやり取りを追跡して LCP リクエストを繰り
かえし送っているけれど、その識別ナンバーが増えない、という場合はリモー
トの PPP ソフトウェアとフレームのやり取りができていません。
これには 3 つの原因が考えられます。
ppp プロトコルをやり取りし始める前に、リモート側で ppp ソフトが動いて いることを確認してください。普通の通信ソフトを使って、普通の方法で login してみてください。ppp フレームが送られてきていますか？
ppp フレームは一目でわかります。それぞれは 16 文字で、複数の
{を含んでいます。改行コードは無く、16 文字が断続的に送られて
きます。
pppd は自動的に回線を 8 ビット、パリティ無し、1 ストップビットに設定し ます。リモート側も同様の設定になっていないとフレームやパリティのエラー が起ることになります。
PPP はキャラクターをエスケープして送ることもできますが、kermit のよう に複数のビットをエスケープすることはできません。PPP は 7 ビットしか通 さない回線では利用 できません。
ppp.c ドライバ(カーネルに附属しています)には CHECK_CHARACTERS と呼ばれるオプションがあり、入力されるキャラクタをより厳密にチェックす ることが可能です。このオプションを指定すると、パリティが設定されている かどうかやリモートシステムが 7 ビットキャラクターを送りつづけているの かなどをチェックすることができます。
PAP か CHAP の認証を求めており、ローカル
ではその設定をしていない場合。この場合、リモート側は、正しい認証用のフ
レームが送られるまで全てのフレームを捨ててしまいます。ローカルでは認証
を使う設定になっていないので、送られる IPCP フレームは全て捨
てられてしまいます。
この場合、リモート側で認証を使わないように設定するか、ローカル側で正し く認証を発行するように各種のファイルを設定する必要があります。
受け取った LCP 設定フレームを調べてみてください。'auth' というタイプに なっていれば、リモートは認証機能を設定しています。
merit ネットワークのユーザーに聞いたところによると、PAP が必要だそうで す。PAP の設定をしていますか？