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
をトラブルのないときや自動スクリプトから実行することは奨められない。
オプションなしの 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
から登場した。