Provided by: manpages-ja_0.5.0.0.20221215+dfsg-1_all
名前
ping — ICMP ECHO_REQUEST パケットをネットワーク上のホストに送る
書式
ping [-LRdfnqrv] [-c count] [-i wait] [-l preload] [-p pattern] [-s packetsize] [-t ttl] [-w waittime] [-I interface address]
説明
ping は ICMP の ECHO_REQUEST データグラムを用いて、指定したホストやゲートウェイからの ICMP ECHO_RESPONSE を引き出す。 ECHO_REQUEST データグラム (``pings'') は IP と ICMP ヘッダを持 ち、それに “struct timeval” が続き、そして、パケットの残りを埋めるために任意個の ``pad'' バ イトがある。 オプションは以下の通り: その他のオプションは: -c count count 個のパケットを送った (そしてその応答を受け取った) 後、停止する。 パケットが送 られた後、 ping は応答を受け取るまで 10 秒間待ち、終了する。 -d 使用するソケットに SO_DEBUG オプションを設定する。 -f flood ping (ping の洪水)。パケットが戻ってくるとすぐ、 もしくは、1 秒間に 100 回 の、いずれか多い回数だけパケットを送る。 ECHO_REQUEST が送られるたびにピリオド ``.'' が表示され、 ECHO_REPLY を受け取るごとに、バックスペースが表示される (訳注: すなわち ``.'' が消去される)。 これにより、どのくらいのパケットが取りこぼされるかを、 すばや く表示することができる。スーパーユーザーだけがこのオプションを使える。 これは、ネッ トワークに非常に負荷をかけるので、注意して使うべきである。 -i wait 個々のパケットの間に wait 秒待つ。 デフォルトでは、個々のパケットの間に 1 秒待つ。こ のオプションは -f オプションとは同時に指定できない。 -l preload 指定した preload の値だけ ECHO_REQUEST パケットを出来るだけ速く送信し、通常の動作に 戻る。 スーパーユーザーだけがこのオプションを使用できる。 -n 数値出力のみ。 ホストのアドレスから、ホスト名の検索を試みない。 -p pattern 送出するパケットを埋めるための 16 個までの ``pad'' バイトを指定できる。 これはネット ワークでの、データに依存した問題の診断に有用である。 たとえば “-p ff” は全て 1 で埋 められたパケットを送る。 -q 静かな出力。 開始と終了時の要約以外は、何も表示しない。 -R 経路を記録。 ECHO_REQUEST パケットに RECORD_ROUTE オプションを設定し、返ってきたパ ケットの経路バッファ (route buffer) を表示する。 IP ヘッダは 9 つの経路分の大きさし かないことに注意せよ。 また、多くのホストはこのオプションを無視するか、破棄してしま う。 -r 通常のルーティングを無視し、接続されたネットワークのホストに直接送る。 もし、ホスト が直に接続されたネットワークになければ、エラーが返る。 経路情報を持たないインタ フェースを通して、 ローカルなホストへと ping するのに使われる。(例えば、インタフェー スが routed(8) に落された場合)。 -s packetsize 何バイトのデータが送られるかを指定する。デフォルトは 56 で、 ICMP ヘッダの 8 バイト を加えて、 64 バイトの ICMP データになる。 スーパーユーザーだけがこのオプションを使 用できる。 -v 詳細な出力。 受け取った ECHO_RESPONSE 以外の ICMP パケットを表示する。 -w waittime どのような場合でも関係なく、 ping を waittime 秒後に終了させる。 以下のオプションに関する記述は、 ping のソース、ならびに FreeBSD の man ページを参考に 日本 語訳に際して追加された。 -I interface 与えられたインタフェースから、マルチキャストパケットを送る。 -L マルチキャストパケットのループバックを抑制する。 -t ttl マルチキャストパケットの IP 寿命時間 (Time To Live) を設定する。 問題の切り分けのために ping を用いる場合、そのネットワークインタフェースが up かつ running である ことを確認するために、まずローカルホスト上で実行するべきである。 その後により遠くのホ ストやゲートウェイに “ping” する。 往復時間 (round-trip time) と消失パケットの統計が計算され る。 重複した応答メッセージを受け取った場合、 それらはパケットの損失の計算には使われないが、 それにもかかわらずそうしたパケットの往復時間は、 その最小値・平均値・最大値の計算に用いられ る。 指定した数のパケットが送られた (そしてその応答を受け取った) か、プログラムが SIGINT で 終了させられた場合は、簡単な要約が表示される。 もし ping が全く応答パケットを受け取らなかった場合には、終了コード 1 で終了する。 エラーがあ ればコード 2 で終了する。それ以外の場合はコード 0 で終了する。 これにより、終了コードで、あ るホストが動いているかどうかを判断すること ができる。 このプログラムはネットワークのテスト・計測・管理についての使用を意図している。 このプログラ ムがネットワークに強いる負荷を考えれば、 ping をトラブルのないときや自動スクリプトから実行す ることは奨められない。
ICMP パケットの詳細
オプションなしの IP ヘッダは 20 バイトである。 ICMP ECHO_REQUEST パケットは、さらなる 8 バイ トの ICMP ヘッダとそれに続く任意の量のデータからなる。 packetsize が与えられた時には、それは 付加的なデータ部分のサイズ (デフォルトは 56) を示す。 よって ICMP ECHO_REPLY パケットの IP パケット内で受け取るデータの量は、 要求されたデータ領域より 8 バイト (ICMP ヘッダの分) 多 い。 もしデータ領域が 8 バイトよりも大きければ、 ping はその領域の先頭 8 バイトを、往復時間を計算 するのに使うタイムスタンプを 含めるために使用する。 もし 8 バイトよりも少なければ、往復時間 は得られない。
重複パケットと障害パケット
ping は、重複パケットと障害パケットについて報告する。 重複パケットは (ユニキャストアドレスに 対しては) 起きるはずはないが、 不適切なリンク層での再送によって引き起こされるように思われ る。 重複は様々な状況で起こる可能性がある。低いレベルの重複の存在は 必ずしも警告にはならない かもしれないが、よい兆候ではない。 障害を受けたパケットは、明らかに深刻な警告であり、多くの場合 ping パケットの経路上 (ネット ワーク内、もしくはそのホスト内) のどこかに 壊れたハードウェアがあることを示す。
異なるデータパターンの試行
(インター) ネットワーク層は、決してデータ部分に含まれるデータによって パケットの扱いを変えた りしない。 不幸にも、データに依存した問題がネットワークへと侵入し、 長い時間発見されないまま となってしまう可能性が知られている。 問題のあるパケットの特定のパターンは多くの場合、 全てが 0 または全てが 1 のようなもの、 あるいは右端以外が殆んど 0 のような、 十分な ``遷移 (transitions)'' を持たないものである。 コマンドラインで (例えば) 全て 0 というデータパターン を指定することは、 必ずしも十分ではない。 なぜならば、その関心のあるのはデータリンク層におけ るパターンであり、 あなたが入力したものと、コントローラーが送信するものとの関係は 複雑だから である。 これは、もしあなたがデータ依存性の問題を抱えているなら、 それを発見するためには 何回ものテス トをしなければならないかもしれないことを意味する。 もし運が良ければ、ネットワークを通して送 ることのできないファイルか、 同じような長さのファイルより、転送にずっと時間のかかるファイル を 発見することができるかもしれない。 そうしたら、そのファイルを調べ繰り返し現われるパターン を ping の -p オプションを使ってテストできる。
TTL の詳細
IP パケットの TTL という値は、パケットが破棄される前に通過することができる IP ルータの最大値 を示す。 現在の慣例から、インターネットの各ルータは TTL フィールドを正確に 1 減らすことを期 待できる。 TCP/IP 規格は、 TCP パケットの TTL フィールドは 60 に設定されるべきであるとしているが、多く のシステムは もっと小さな値を使用している (4.3 BSD は 30、4.2 は 15)。 このフィールドの設定可能な最大値は 255 で、殆んどの Unix システムは ICMP ECHO_REQUEST の TTL フィールドを 255 に設定している。 これは、あるホストでは ``ping'' が通るのに、 telnet(1) や ftp(1) ではそのホストに届かない理由 (の一つ) である。 ping の通常の操作では、受け取ったパケットの ttl の値が表示される。 リモートのシステムが ping パケットを受け取った時、その応答における TTL フィールドには以下の 3 つのうちの 1 つを取るこ とができる。 • 変更しない; これは 4.3BSD-Tahoe リリース以前の BSD Unix システムが行っていたものである。 この場合、受け取ったパケットの TTL の値は、255 から往復経路上のルータの数を引いたものに なる。 • 255 にセットする; これは現在の BSD Unix が行っているものである。 (訳注: Linux もこれにあ たる)。 この場合、受け取るパケットの TTL の値は、リモートシステム から ping を行ったホス トへの経路上のルータの数を、255 から引いたものである。 • その他の値にセットする。いくつかのマシンは、例えば 30 または 60 のような TCP パケットの 値と同じものを ICMP パケットに用いる。また全く異なる値を用いるマシンもあるかも知れない。
バグ
多くのホストとゲートウェイは RECORD_ROUTE オプションを無視する。 RECORD_ROUTE を完全に有効にするには、IP ヘッダの最大長は短過ぎる。 しかし、これについてでき ることは多くない。 flood ping は一般的には推奨されないし、ブロードキャストアドレスへの flood ping は、きちんと 条件を整えた場合においてのみ使用されるべきである。 日本語訳に際し、いくつかのオプションに関する記述を加えたが、正しいかど うか分からない。
関連項目
netstat(1), ifconfig(8)
履歴
ping コマンドは 4.3BSD から登場した。