Q&A
2回目以降のpingにおける、(1)pingリクエスト、(2)pingリプライ、(3)ユニキャストARPリクエスト、(4)ユニキャストARPへのリプライ、の順序関係を教えてください。
＜環境＞ Raspberry Pi 3B+ Raspbian Stretch の環境で、あるWifi機器と接続しています。HWは内蔵WiFiです。ネットワークサービスとしてはデフォルトで搭載されている、dhcpcdを使っており、接続先のWiFi機器からDHCPにてIPをもらっています。WiFIもデフォルトのままでRaspbianのGUIでSSIDとWPA2のパスフレーズを設定しています。Wifi以外に有線イーサネットでネットワーク接続があり、有線側からログインして動作をチェックしています。
＜課題＞RaspberryPiからのユニキャストARP
このWiFI機器とRaspberryPiが不定期に通信するのですが、時々 相手側がARPに応答しないことがあります。
接続確認のために、10分に一回 このWifi機器あてにPINGを出しています。（cron起動）このWiFi機器自体は、数日単位ではPINGは問題なく動作していて、たまに動かなくなる（一度動かなくなるとずっと応答しなくなる：見てみるとARPリクエストに応じない）という状況です。WiFi機器については、他社のものでおいそれと内部動作を見るわけにもいきません。
このこと自体は、相手側機器の問題だと思うのですが、RaspberryPi側のARPの挙動が納得できないものなので、ご存じの方がおられたらお教えください。
ラズパイ上のWiresharkで見ると、
ラズパイの起動後初回のPINGについては ARPは通常どうりブロードキャストがPINGに先立って出ていますが、２回目以降のPINGについてはPINGの数秒後にユニキャストでARPが発信されています。
そもそもARPは、相手のMACアドレスを知りたいためにブロードキャストで流すものとの理解をしています。PINGをするときに事前にARPをしないのは、ARPテーブルができているからで、この後で送られる相手を指定したユニキャストARPを送る意味がわかりません。WireSharkではユニキャストであること以外は通常のARPパケットのようです。
WiFiの電波が途切れたりしてインターフェイスやDHCPアドレス再配布が起きたりすると再度、通常のブロードキャストARPが出るようですが、そうでない限り稼働中、ずっとユニキャストARPが、PINGの後から出ているようです。相手側のARPキャッシュを維持するためでしょうか？ 10分も放っておけば、通常RaspbianのARPテーブルはクリアされると思うので、まずブロードキャストでARPすると想定していましたが、そうではないようです。他の機器との通信のない状況で確認したところ、10分後にもPINGがいきなり出て（＝RaspberryPiは相手のMACアドレスを知っている）、その後にユニキャストが出ています。なお後に出るユニキャストARPは出ないこともあります。PINGが短時間に続くと出ないのですが、後に出るARPなんていうのは意味がないので出ないのが正しい動作だと思っていますが違うのでしょうか？
Raspbian もしくはDebianに搭載されているネットワークサービス、LinuxのARPの挙動に詳しい方、お教え願います。
またこのことが相手側機器がARP応答しなくなる何らかの原因になりえるでしょうか？ 例えば相手側が、ARPテーブルをクリアしてしまうような。WiFi機器のバグとしてしまえばそれまでなんですが、証拠を上げないと指摘しにくく、Raspbian のARPに問題はなく、当方の問題ではないことを示したいというのが、本質問の意図です。
（追加）
下記は WireShark の 画面コピー 1回目（正常に先にブロードキャストでARP)から1時間後に２回目のPINGを実施 その後 ３回目 ４回目も１時間後ですが、
２回目以降 ARPは先に出ず、PINGの後にユニキャストのARPリクエストが出ています。
１日空いてしまってすいません。２回目以降のPINGで WireSharkに出ているパケットの順序を記載します。
なお１回目から２回目のPINGまでは 600秒 時間が空いています。
1, PING request ラズパイ to WiFi機器
2, PING reply WiFi機器 to ラズパイ
この間 ５秒程度
3, ARP request ユニキャスト ラズパイ to WiFi機器 : これが？普通はブロードキャスト あとでやっているからブロードキャストにする意味もないとは思いますが、でも出す意味はあるのだろうか？ そういう実装なんだということで納得すればいいのでしょうか？
4, ARP reply ユニキャスト WiFi機器 to ラズパイ （これは通常どおり）
試しに１回目と２回目を１０分ではなく、１時間後としても結果は同じでした。長い間隔の後、いきなりPINGを出せるということはラズパイのARPテーブルは消されないのでしょうか？ なおこのテストでは、このWiFIネットワークには他のWiFI機器は接続されていませんので、他の機器のARPでテーブルが維持されることも考えられません。
回答ありがとうございます。ユニキャストのAPR requestは存在しうると書いてあるページはあるのですか、実在を見たのは初めてです。ただし、「このIP/MACの組合せは生きているよね」的な目的で使われるので、回答いただいた順番だと理由がわかりません。
またWindows/Linuxのarpテーブルのタイムアウトは通常数十秒であるようなので、これも回答いただいた話とは整合とれません。
Pi特有の動きかもしれません。ただし、ググってもそれらしい話は出てこないので、Pi実機が無いと確認できないですね。
すみませんが、原因不明です。
WireSharkのデータを追記しておきました。特にラズパイに変わった設定をしていないので、不思議なのですが。
初回のやりとりの直後、時間を空けてpingする直前の、ラズパイのarpテーブルの状態はどうでしょうか？
（理由不明ですが、タイムアウトせずにaprテーブルが変化無いことを確認したいです）
ICMP requestとreplyのmacは、正しくラズパイとWiFi機器のものでしょうか？
（WiFi機器の仕様？で、ICMP replyのmacが別のmacになっていれば、直後にmacとIPの組合せをリフレッシュしようとした動きも、理解できるかもです）
arp -a でarpテーブルを 見ましたが、1時間後（PING前）でもこのWiFi機器のmacアドレスが記載されたままでした。初回は正しくarpされることでわかりますが、スタティック設定もしていないので、何時間もテーブルが維持される理由は不明です。WiFiレベルで何かやっているのでしょうか？ WireSharkは、無線側にはつながっていなので見えないのですが？
両方ともmacアドレスは正しいものです。ルータのような複雑な装置ではないので、macを変えるような仕様はありません。
WireSharkは、無線側にはつながっていない？とは、どういう意味でしょうか？今までには無い情報と思います。
表現がまずかったですね。WiFiの無線パケットを直接キャプチャできていない、そこでの動きはわからないという意味です。無線を受信してからパケットを復号したレベルでWireSharkがラズパイ上で動作しています。無線上のやり取りについてはARPには関係ないと思っています。
linuxのarpについてはtoast-uzさんの回答でほぼ問題ないと思います。
しかし、これほどやり取りを重ねながら、まだまだ不明点があります。
・WiFi機器はルータですか？APですか？（つまりネットワークの境界に存在していて
そのIP宛にパケットを投げないとどこへもいけないのか？それとも
ただ管理用のIPアドレスが同一セグメント内で付与されているだけなのか）
・その機器がしばしばarpに無応答になるのは、機器の仕様のせいと断定してよいのか？
他に要因の可能性は考えましたか（考えてもらえるような質問をしましたか）
・そもそも無線LANにどういう認証方法を用いているのでしょうか。
（WPA2-EAPなのか・WPA2-PSKなのか、それ以外の何かなのか）
・あとWi-Fi機器のパケットキャプチャですが、手間はかかりますが可能です。
機器のWAN側にミラーリングポートのあるswitchを接続し、
そこにキャプチャ用PCを繋いで見てやれば良いのです。
ここら辺は、確認しておいた方が良いかもしれません。
ご健闘を祈ります。
追記
我ながらハードルの高いことをいっているなと思います。
不明点はどんどん聞いてください。
toast-uzさん、hana_yama_sanさん ありがとうございます。 ARPの問題ではないということが確信できたので、WiFi無線レベルの問題については、別途KaliLinuxのキャプチャー機を準備中です。無線レベルで異常がないか確認したいと思います。なおご質問のWiFi機器の仕様ですが、ルータ等ネットワーク機器ではなく、WiFiを持った設備機器でラズパイの制御対象です。ただしWiFi的にはWPA2-PSKの親機（AP）となっていて、ルータのようにふるまいますがルーティングするわけではありません。ただしDHCPサーバは持っています。WiFi機器の先には何もつながっていません。ご質問の中の言葉で行けば、管理用のIPがあるだけのもの に近いです。
ようやくWiFiキャプチャーができる状態になりましたので報告。なかなか現象が出なかったのですが、ようやく再現したところを掴んでみると、WiFi機器からなぜかDeauthentication（802.11プロトコル）が出て、切断されているようです。相手方に見てもらわないとわかりませんが、やはりこの装置のWiFiプログラム実装か設定に問題がありそうです。ありがとうございました。最初からそっちを見ろよということなのかもしれませんが、ARPの件が気になって進めなかったので。お世話になりました。
回答1件
0
ベストアンサー
少し推測入りますが、正常な動作と思われます。
ARP(7) MAN PAGE
https://linuxjm.osdn.jp/html/LDP_man-pages/man7/arp.7.html
上記の2つの記事を読み合わせると、ポイントは以下です。
- Linuxのarpテーブルは、いきなり消えずにbase_reachable_time_msの前後でSTALEという状態になる。このSTALEの状態はip -s neighbor showで観察できる。
- STALEになったエントリはgc_stale_time後に、gc_interval間隔で動作するガベージコレクションで消されるが、様々な要因で消えない場合もある。
- STALEの相手にpingをした場合、1秒ほど後に、古いMACアドレスがわかっている場合は、ユニキャストのプローブが送られる。
- 上記がucaset_solicit回失敗すると、新しいARPリクエストをネットワークにブロードキャストする。
よって、ip -s neighbor showで、長く残っているARPテーブルがSTALEとなっていれば、上記をほぼ裏付ける動作になります。STALEのテーブルが「様々な要因で消えない」のは個別の事情であり、かつ、仕様上は気にする必要は無いのではと考えます。
投稿2020/09/18 12:48
総合スコア3266
ご回答ありがとうございます。 ip -s neigh show については、STALE 状態にありことを確認できました。本件の主題である、ARP側の問題はないということが信じられそうです。ありがとうございます。
あなたの回答
tips
プレビュー
