There are only 2 problems with the solution proposed by Ricky.
- I have no extra sockets.
- My application operates as a TCP server.
The Wiznet module does NOT meet internet standards. ARP must be used to resolve IP addresses into MAC addresses. RFC 5798 states:
8.1.2. Host ARP Requests
When a host sends an ARP request for one of the virtual router IPv4
addresses, the Virtual Router Master MUST respond to the ARP request
with an ARP response that indicates the virtual MAC address for the
virtual router. Note that the source address of the Ethernet frame
of this ARP response is the physical MAC address of the physical
router. The Virtual Router Master MUST NOT respond with its physical
MAC address in the ARP response. This allows the client to always
use the same MAC address regardless of the current Master router.
When a VRRP router restarts or boots, it SHOULD NOT send any ARP
messages using its physical MAC address for the IPv4 address it owns;
it should only send ARP messages that include virtual MAC addresses.
This may entail the following:
o When configuring an interface, Virtual Router Master routers
should broadcast a gratuitous ARP request containing the virtual
router MAC address for each IPv4 address on that interface.
o At system boot, when initializing interfaces for VRRP operation,
delay gratuitous ARP requests and ARP responses until both the
IPv4 address and the virtual router MAC address are configured.
Since the Virtual Router Master MUST respond to the host ARP request with the virtual MAC address of the virtual router, even though that reply will have the source MAC address of the physical router, that implies that the host CANNOT assume that the physical MAC address it receives from the physical router is the correct MAC address of the router. There MUST be an APR request from the host, else the virtual MAC address of the virtual router cannot be known.
The Ping request frame received by the Wiznet module IS valid, but it contains the PHYSICAL MAC address of the router, not the VIRTUAL MAC address of the virtual router, which is where the reply must be sent. And an ARP request is the ONLY way to obtain the virtual MAC address. (That’s why an interface implementing VRRP MUST delay ARP replies until the virtual router MAC address is configured. The virtual router must NEVER reply to an ARP request with its physical MAC address. That MAC address is WRONG, so why should the Wiznet module assume the physical MAC address is right?)
Wiznet is “cheating” on its implementation of the protocol, and any time you cheat there will arise a condition in which the cheat fails, and the device will not perform properly.
The only proper fix for this problem is for Wiznet to change its network implementation to ALWAYS use ARP to resolve IP addresses into MAC addresses. The question is, when can I expect this fix to be implemented?