DOKK / manpages / debian 12 / manpages-ja / ping.8.ja
PING(8) System Manager's Manual PING(8)

名前

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'' バイトがある。 オプションは以下の通り: その他のオプションは:

count
count 個のパケットを送った (そしてその応答を受け取った) 後、停止する。 パケットが送られた後、 ping は応答を受け取るまで 10 秒間待ち、終了する。
使用するソケットに SO_DEBUG オプションを設定する。
flood ping (ping の洪水)。パケットが戻ってくるとすぐ、 もしくは、1 秒間に 100 回の、いずれか多い回数だけパケットを送る。 ECHO_REQUEST が送られるたびにピリオド ``.'' が表示され、 ECHO_REPLY を受け取るごとに、バックスペースが表示される (訳注: すなわち ``.'' が消去される)。 これにより、どのくらいのパケットが取りこぼされるかを、 すばやく表示することができる。スーパーユーザーだけがこのオプションを使える。
これは、ネットワークに非常に負荷をかけるので、注意して使うべきである。
wait
個々のパケットの間に wait 秒待つ。 デフォルトでは、個々のパケットの間に 1 秒待つ。このオプションは -f オプションとは同時に指定できない。
preload
指定した preload の値だけ ECHO_REQUEST パケットを出来るだけ速く送信し、通常の動作に戻る。 スーパーユーザーだけがこのオプションを使用できる。
数値出力のみ。 ホストのアドレスから、ホスト名の検索を試みない。
pattern
送出するパケットを埋めるための 16 個までの ``pad'' バイトを指定できる。 これはネットワークでの、データに依存した問題の診断に有用である。 たとえば “-p ff” は全て 1 で埋められたパケットを送る。
静かな出力。 開始と終了時の要約以外は、何も表示しない。
経路を記録。 ECHO_REQUEST パケットに RECORD_ROUTE オプションを設定し、返ってきたパケットの経路バッファ (route buffer) を表示する。 IP ヘッダは 9 つの経路分の大きさしかないことに注意せよ。 また、多くのホストはこのオプションを無視するか、破棄してしまう。
通常のルーティングを無視し、接続されたネットワークのホストに直接送る。 もし、ホストが直に接続されたネットワークになければ、エラーが返る。 経路情報を持たないインタフェースを通して、 ローカルなホストへと ping するのに使われる。(例えば、インタフェースが routed(8) に落された場合)。
packetsize
何バイトのデータが送られるかを指定する。デフォルトは 56 で、 ICMP ヘッダの 8 バイトを加えて、 64 バイトの ICMP データになる。 スーパーユーザーだけがこのオプションを使用できる。
詳細な出力。 受け取った ECHO_RESPONSE 以外の ICMP パケットを表示する。
waittime
どのような場合でも関係なく、 ping を waittime 秒後に終了させる。

以下のオプションに関する記述は、 ping のソース、ならびに FreeBSD の man ページを参考に 日本語訳に際して追加された。

interface
与えられたインタフェースから、マルチキャストパケットを送る。
マルチキャストパケットのループバックを抑制する。
ttl
マルチキャストパケットの IP 寿命時間 (Time To Live) を設定する。

問題の切り分けのために ping を用いる場合、そのネットワークインタフェースが up かつ running である ことを確認するために、まずローカルホスト上で実行するべきである。 その後により遠くのホストやゲートウェイに “ping” する。 往復時間 (round-trip time) と消失パケットの統計が計算される。 重複した応答メッセージを受け取った場合、 それらはパケットの損失の計算には使われないが、 それにもかかわらずそうしたパケットの往復時間は、 その最小値・平均値・最大値の計算に用いられる。 指定した数のパケットが送られた (そしてその応答を受け取った) か、プログラムが SIGINT で終了させられた場合は、簡単な要約が表示される。

もし ping が全く応答パケットを受け取らなかった場合には、終了コード 1 で終了する。 エラーがあればコード 2 で終了する。それ以外の場合はコード 0 で終了する。 これにより、終了コードで、あるホストが動いているかどうかを判断すること ができる。

このプログラムはネットワークのテスト・計測・管理についての使用を意図している。 このプログラムがネットワークに強いる負荷を考えれば、 ping をトラブルのないときや自動スクリプトから実行することは奨められない。

オプションなしの 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 オプションを使ってテストできる。

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 から登場した。

August 30, 1996 Linux NetKit (0.17)