TOPPERS Project
Replies: 2 comments 1 reply
-
|
長島と申します。 まだ、デバッグ作業を始めるまでには至っていませんが、とりあえずの連絡で失礼します。 私は、TINETにFuzzingテストを行っていまして、ARPテーブル関連では下記の事象を発見して対処しました。 頂いたメールを読んだ限りでは、該当するかわかりませんが、TINETのその他の対処もありますので、Fuzzingテストのリポジトリをご連絡いたします。 対策したTINETのリポジトリは、下記になります。 報告いただいた内容をテストするコードを書いて確認したいと思います。 以上です。 |
Beta Was this translation helpful? Give feedback.
-
|
長島様 どうぞよろしくお願いいたします。 |
Beta Was this translation helpful? Give feedback.
-
|
報告頂いた内容について、現象を確認し修正いたしました。 |
Beta Was this translation helpful? Give feedback.
-
TINETご担当者様
TINET 1.7 の動作について確認をお願いします。
IP出力処理からARP解決を始めた状態で新たなIP出力処理が発生すると，①先の出力処理が無効になる事象，あるいは②間違ったMACアドレスに対して送信する事象が見られています。
調べたところ，ether_output から arp_resolve の流れの処理において，ARPの解決待ちになっているarp_cache エントリが次の出力処理によって上書きされることが関係しているようです。
具体的には，
IP出力処理時にARP解決（arp_resolve）を実行します。
ARP解決にて arp_cache の探索（arp_lookup）を実行し，未登録であれば空き（expireがゼロ）の箇所のエントリを割り当てます。エントリにIPアドレスが代入されます。
arp_resolve に戻り，取得したエントリの expire がゼロであれば，ペンディング中のフレームがあれば（hold）それを捨てますが，ここではそれはありません。その後，今回の送信フレームをペンディングし（hold に代入）し，最後に ARP解決要求を送信します。ARP応答を受け取ったときに expire に値が入ることになります。
このペンディング中に新たなIP出力処理が発生すると，こちらについても同じようにARP解決を実行します。
この際，arp_cahce の探索（arp_lookup）にて先のペンディング中のエントリが（expire が未だゼロのままなので）が割り当てられます。エントリには新たなIPアドレスが代入されます。
そして arp_resolve に戻ると，ペンディング中の送信（hold）を捨てますが，この度は先のペンディング中のフレームが代入されており，それを捨ててしまいます。
これが一番目の問題です。
次に，先のARP解決要求への応答が届きます（in_arpinput）。
arp_cache内 にエントリを探しますが，IPアドレスが見つからないため，新たなエントリを探します，つまり expire がゼロのままの箇所で，やはり先と同じエントリになり，そこに応答結果を反映させます。
この場合，ip_addr と hold は2番目のIP出力時のものが代入されており，ARP応答によるMACアドレスは1番目のIP出力時のものという矛盾が発生します。
そして，hold されているフレームを送信すると，MACアドレスが異なる先に送信するようになります。
これが二番目の問題です。
問題点とこちらで考えた対策をまとめると次のようになります。
問題点1：ARP応答待ちレコードを「空き」としてしまっています。
保留扱いとなっているARPテーブルは「空き」と判断しないようにすると良いです。
問題点2：ARP応答受信時にIPアドレスチェックをしていません。
ARP応答で受信したIPアドレスと保留扱いとなっているIPアドレスをチェックして一致したら保留扱いとなっている情報を送信するようにすると良いです。
問題点3：同じIPアドレスの応答待ちが複数あった場合を考慮していません。
これは以上の問題点1,2を対応した結果，複数のARP応答待ち状態が発生するケースが生じます。応答待ちとなっているレコードに同じIPアドレスが複数あれば全て送信するように変更すると良いです。
以上，ご確認のほどよろしくお願いいたします。
Beta Was this translation helpful? Give feedback.
All reactions