why don't we reply arp request for specific mac address

[578141611]

I encounter a situation in win10 like the picture. I open the nic with tun mode,then the mac address of gateway is generated by nic driver.but I find the code of arp response only accept broadcast type.while the arp cahe expired the system will send specific mac address for checking.

[cron2]

Hi,

On Wed, Jan 06, 2021 at 05:00:38AM -0800, 578141611 wrote:

I encounter a situation in win10 like the picture. I open the nic with tun mode,then the mac address of gateway is generated by nic driver.but I find the code of arp response only accept broadcast type.while the arp cahe expired the system will send specific mac address for checking.

What are you doing to trigger these ARP queries?

(In other words: I do not think we see them in OpenVPN context, and this is what the tap6 driver has been developed for, and is tested against)

gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

[578141611]

Excatly, I use tun2socks to open nic tap6 with tun mode,but there is a customer can not get ip packet via wireshark,so I check the code of tap6.I find the is limit for arp reply. //----------------------------------------------- // Is this the kind of packet we are looking for? //----------------------------------------------- if (src->m_Proto == htons (NDIS_ETH_TYPE_ARP) && MAC_EQUAL (src->m_MAC_Source, Adapter->PermanentAddress) && MAC_EQUAL (src->m_ARP_MAC_Source, Adapter->PermanentAddress) && ETH_IS_BROADCAST(src->m_MAC_Destination) && src->m_ARP_Operation == htons (ARP_REQUEST) && src->m_MAC_AddressType == htons (MAC_ADDR_TYPE) && src->m_MAC_AddressSize == sizeof (MACADDR) && src->m_PROTO_AddressType == htons (NDIS_ETH_TYPE_IPV4) && src->m_PROTO_AddressSize == sizeof (IPADDR) && src->m_ARP_IP_Source == adapter_ip && (src->m_ARP_IP_Destination & ip_netmask) == ip_network && src->m_ARP_IP_Destination != adapter_ip) ETH_IS_BROADCAST(src->m_MAC_Destination) 2.0.0.1 is the ip address if nic,2.0.0.4 is the geteway.

[578141611]

I want modify little code ,follows down. ETH_IS_BROADCAST(src->m_MAC_Destination)

to

ETH_IS_BROADCAST(src->m_MAC_Destination) || MAC_EQUAL (src->m_MAC_Destination, mac)

according rfc 826 https://tools.ietf.org/html/rfc826

Another alternative is to have a daemon perform the timeouts. After a suitable time, the daemon considers removing an entry. It first sends (with a small number of retransmissions if needed) an address resolution packet with opcode REQUEST directly to the Ethernet address in the table. If a REPLY is not seen in a short amount of time, the entry is deleted. The request is sent directly so as not to bother every station on the Ethernet. Just forgetting entries will likely cause useful information to be forgotten, which must be regained.

[578141611]

@cron2 Wish your reply, sincerely.

[cron2]

Hi,

On Thu, Jan 07, 2021 at 04:25:25PM -0800, 578141611 wrote:

Excatly, I use tun2socks to open nic tap6 with tun mode,but there is a customer can not get ip packet via wireshark,so I check the code of tap6.I find the is limit for arp reply.

The more interesting question is how you set up the routing on the tap interface (if at all), and which IP addresses are talking to each other.

In the OpenVPN context, all routes always point to the gateway IP, and Windows has no issues keeping the ARP cache up to date.

gert

-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de