tcpclientクラスを使用してTCP/IP通信。他装置からデータ送信後に、自装置からARPコマンドが送信されると、データ受信の[ACK]を返さない。

Question

いつもお世話になっております。
神田と申します。

.NET Framework 2.0で、tcpclientクラスを使用してTCP/IP通信をしています。

他装置からデータ送信後( Wiresharkのログ(1) )に、自装置からARPコマンドが送信される( Wiresharkのログ(2) )と、
データ受信の[ACK]を返しません。
[ACK]を返さないため、他装置からデータの再送( Wiresharkのログ(3) )が発生します。


OSは、windows embedded 2009です。
他装置から定期的に送信されるTCP/IPデータをUDPに変換する処理を行っています。

XPベースの組込み用OSで、デフォルトで１０分毎にARPテーブルをクリアし、ARPコマンドを送信します。
ARPテーブルをクリアする間隔を１０分から６０分に変更して、ARPコマンドの送信間隔を伸ばすように
設定変更しよう考えています。

根本的に、リトライが発生しないよう[ACK]を返すようにしたいのですが、
どなたか解決策をアドバス頂けると大変助かります。

お手数ですが、ご教授よろしくお願い致します。



他装置(他社の組込み装置)
　192.169.34.1

自装置(OS: XP embedded 2009)
　192.169.1.2
　192.169.2.2
　192.169.33.1


＜wiresharkのログ＞
---------------------------------------------------------------------------------------------------------------------------------------
(1) 2107 2015-06-05 03:10:58.291594000 192.169.34.1 192.169.1.2 TCP 78 4417 1500 1137→10011 [PSH, ACK] Seq=4417 Ack=1 Win=1500 Len=24
　　2108 2015-06-05 03:10:58.309363000 192.169.34.1 192.169.2.2 TCP 78 4417 1500 1138→10021 [PSH, ACK] Seq=4417 Ack=1 Win=1500 Len=24
　　2109 2015-06-05 03:10:58.329385000 192.169.34.1 192.169.33.1 TCP 78 4417 1500 1139→10330 [PSH, ACK] Seq=4417 Ack=4417 Win=1500 Len=24
　　2110 2015-06-05 03:10:58.365317000 192.169.34.1 192.169.33.1 TCP 166 6833 1500 1140→10351 [PSH, ACK] Seq=6833 Ack=1 Win=1500 Len=112

(2) 2111 2015-06-05 03:10:58.418610000 Interfac_80:**:** Broadcast ARP 60 Who has 192.169.34.1? Tell 192.169.1.2
　　2112 2015-06-05 03:10:58.419376000 Seiko_16:45:84 Interfac_80:**:** ARP 60 192.169.34.1 is at 00:80:**:**:**:**

　　2113 2015-06-05 03:10:58.419420000 192.169.2.2 192.169.34.1 TCP 60 1 65487 10021→1138 [ACK] Seq=1 Ack=4441 Win=65487 Len=0
　　2114 2015-06-05 03:10:58.519189000 192.169.33.1 192.169.34.1 TCP 60 4417 65487 10330→1139 [ACK] Seq=4417 Ack=4441 Win=65487 Len=0
　　2115 2015-06-05 03:10:58.519198000 192.169.35.2 192.169.34.1 TCP 60 1 64863 10351→1140 [ACK] Seq=1 Ack=6945 Win=64863 Len=0
　　2116 2015-06-05 03:11:00.397934000 192.169.33.1 192.169.34.1 TCP 78 4417 65487 10330→1139 [PSH, ACK] Seq=4417 Ack=4441 Win=65487 Len=24
　　2117 2015-06-05 03:11:00.402953000 192.169.34.1 192.169.33.1 TCP 60 4441 1476 1139→10330 [ACK] Seq=4441 Ack=4441 Win=1476 Len=0
　　2118 2015-06-05 03:11:00.418410000 192.169.34.1 192.169.33.1 TCP 60 4441 1500 [TCP Window Update] 1139→10330 [ACK] Seq=4441 Ack=4441 Win=1500 Len=0

(3) 2119 2015-06-05 03:11:01.234802000 192.169.34.1 192.169.1.2 TCP 78 4417 1500 [TCP Retransmission] 1137→10011 [PSH, ACK] Seq=447 Ack=1 Win=1500 Len=24
(4) 2120 2015-06-05 03:11:01.234881000 192.169.1.2 192.169.34.1 TCP 60 1 65487 10011→1137 [ACK] Seq=1 Ack=4441 Win=65487 Len=0

Answer 1

ARPテーブルをクリアしてしまうのが根本的な原因ですよね。

ARPテーブルをクリアしてしまうと、IPアドレスとMACアドレスの関連付けができなくなるので、一時的に送信が途絶するのは当然と思えます。ACKの送信をリトライはしないので、リトライが発生するでしょう。

本来ウィンドウズの挙動では、ARPキャッシュのエントリは未使用状態が2分以上続いた場合に、キャッシュから削除されるような動作をします。通信で使用中のエントリを削除するようなことはしません。質問の内容からはARPテーブルをクリアする実装に至った経緯がわかりませんが、ARPテーブルをクリアする必要があるのかを再検討されるのがよいかと思います。

---

甕星

Answer 2

甕星 様

いつもお世話になっております。
神田です。

ご回答頂き、大変ありがとうございました。

ARPテーブルのクリアについて調べたところ、定期的に通信していても、
デフォルト10分でARPテーブルがクリアされるようです。
このため、アプリケーションの処理には関係なく、
ARPテーブルがクリアされ、ARPコマンドが送信されます。

FAパソコンのメーカーに問合せしたところ、次のご回答を頂きました。

Microsoft の KB233401 と同じ問題が発生していると思われます。
Microsoft によれば、この動作は仕様であり、”ARP が少なくとも
1 つのパケットを保持しなければならない” と規定した RFC 1122
Host Requirement には準拠しているとのことでした。

これからも、どうぞよろしくお願い致します。

Answer 3

そのFAメーカーの回答にはいまひとつ納得できませんね...。
「複数あるパケットの最後１つ以外」が失われたわけではないように見えます。
RFC1122の記述はこうですが、192.169.1.2からACKの代わりに出て行った「少なくとも１つのパケット」はキャプチャ上には存在しないですよね。そうであれば、失われたACKはまさに「少なくとも１つのパケット」に該当するはずですが。

The link layer SHOULD save (rather than discard) at least one (the latest) packet of each set of packets destined to the same unresolved IP address, and transmit the saved packet when the address has been resolved.

---

jzkey