Styjun

I am investigating a strange problem on windows and I have no clue, what is going on.

I have a windows host running windows 10. This host is connected to two networks, our LAN and a WLAN. A program on that system is communicating via WLAN to an embedded system connected to the same WLAN network. The communication usually is working fine and uses HTTP and some custom TCP protocol.

When a software update is performed on the embedded system, it has to perform a reboot. The windows program sends a command to the embedded system via HTTP. This HTTP transaction finishes without any problem and the embedded system performs its reboot.

After the completion of the HTTP transaction the windows program waits for 10 seconds starting polling the embedded device by performing TCP connects. A one second timeout is used and the TCP re-connect is retried for at 120 seconds.

The network trace shows, that after 27 unsuccessful attempts to establish a TCP connection, the windows system suddenly stops sending the TCP SYN frames on the WLAN interface but it starts sending them to the default router on the LAN interface.

I have to idea, why windows is suddenly using the default router trying to reach a node on a locally connected network. :-(

After a while, windows starts using the WLAN interface, again. This seems to be triggered by a timeout of the ARP entry for the embedded system. Windows send an ARP reply on the WLAN interface, the embedded system sends an ARP response, and then windows is using the WLAN interface for the TCP SYN frames, again. Unfortunately the 120s retry period has expired by then.

Does anybody know, what is causing this strange behavior of windows, where I can find documentation about it and how I can stop windows from doing this?

Many thanks in advance,

Mario

Update

Today I checked the problem on windows 7 and windows 7 behaves the same as windows 10. I also observed HTTP connection requests originating from internet explorer being sent to the default gateway instead of the correct interface. I checked the routing table and the ARP table during the misbehavior and found, that the routing table is correct, but the ARP table is missing an entry for the embedded system.

It seems that something is causing windows to drop the ARP table entry and instead of issuing ARP requests on the interface found in the routing table to use the default route.

Next update

It seems to be intended behavior (a least according to https://superuser.com/a/743329/941271 and https://superuser.com/a/743329/941271.

I learned, that the arp -a command windows does not show the complete ARP table on windows :-(. When using netsh interface ipv4 show neighbors, I can see an entry for my target IP address marked as unreachable.

I haven't yet found any documentation about this 'feature' in Microsoft documentation.

Yet another update

I still have not found any description about this behavior from Microsoft, but I found an API to manipulate the neighbor table: GetIpNetTable2() and DeleteIpNetEntry2(). Calling DeleteIpNetEntry2() before trying to connect the target device solves my problem.

Here is my code:

#pragma comment(lib, "iphlpapi.lib")
static void PurgeUnreachableEntry(const boost::asio::ip::address &Addr)

 int AF;
 if (Addr.is_v4()) AF=AF_INET;
 else if (Addr.is_v6()) AF=AF_INET6;
 else return;

 PMIB_IPNET_TABLE2 pipTable = NULL;
 unsigned long status = GetIpNetTable2(AF, &pipTable);
 if (status != NO_ERROR) 
 
 printf("PurgeUnreachableEntry: GetIpNetTable() failed: %sn", 
 boost::system::error_code(status, boost::system::system_category()).message().c_str());
 return;
 
 boost::shared_ptr<MIB_IPNET_TABLE2> IpTable(pipTable, FreeMibTable);

 for (unsigned i= 0; i < pipTable->NumEntries; i++) 
 MIB_IPNET_ROW2 &Entry=pipTable->Table[i];

 if (!Entry.IsUnreachable) continue;

 boost::asio::ip::address EntryAddr;
 switch (Entry.Address.si_family)
 
 case AF_INET:
 EntryAddr = boost::asio::ip::address_v4(*(boost::asio::ip::address_v4::bytes_type*)&Entry.Address.Ipv4.sin_addr);
 break;
 case AF_INET6:
 EntryAddr = boost::asio::ip::address_v6(*(boost::asio::ip::address_v6::bytes_type*)&Entry.Address.Ipv6.sin6_addr, Entry.Address.Ipv6.sin6_scope_id);
 break;
 default:
 continue;
 

 if (Addr != EntryAddr) continue;

 DeleteIpNetEntry2(&Entry);