Problem with ping or connect to WIZ810MJ

Network Module WIZ81xMJ
21

In case of PC, ARP is performed when responding after receiving ping request. However, our chip does not perform ARP when responding after receiving ping request. because, the received packet is considered valid.
This behavior is normal on most networks. However, it may be a problem in your customer’s network environment as shown below.

810MJ and PC-------SWITCH(ec-e5-55-67-d0-0d)-------GATEWAY(10.70.152.7, 00-5e-00-01-82)------/

1 switch, 1 gateway, but can be seen as a gateway with two macs.

810MJ and PC-------GATEWAY(10.70.152.7, 00-5e-00-01-82 and ec-e5-55-67-d0-0d)------/

In other words, the gateway needs to deal with problems that can occur because of two macs for the sub-model like our chip.

I know that you can not change your customer’s network environment.

If it works as tcp server, it can not operate in the your customer’s network environment.

If it works as tcp clien or udp, I suggest the solution as Implement ping reply with IP RAW.(you should have one extra socket.)

I attach the reference material.

How_to_implement_IPRAW_for_W7100_v1.2_en.pdf (478.0 KB)
ping.zip (3.1 KB)

22

There are only 2 problems with the solution proposed by Ricky.

  1. I have no extra sockets.
  2. 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?

23

You should have provided network configuration and wiring diagram, otherwise you operate some general terms in the specific situation, and it will be very hard to make proper suggestion to you.

In the starting message in this topic you say:

So obviously you have some switch between gateway and W5100, but now you say that ec-e5-55-67-d0-0d is a physical address of the router’s port.

This chapter is about how router will reply to the ARP requests. In current situation W5100 does not perform any ARP requests, thus chapter does not apply.

Can you please elaborate on the following:

  1. what MAC address is associated and used for IP packets in the network - virtual router MAC address or router port’s physical interface? I guess the answer is that virtual router MAC address (otherwise using additional virtual MAC address does not make sense);

  2. why IP packets arriving to W5100 re: ping are having physical interface MAC address, and not virtual router MAC address as they should have come from router, thus having 00-00-5e-00-01-82 in the source MAC field.

24

This chapter is about how router will reply to the ARP requests. In
current situation W5100 does not perform any ARP requests, thus chapter
does not apply.

What do you mean, “thus chapter does not apply”? This chapter is the heart of the whole problem. It describes how the virtual router provides the virtual MAC address. It clearly documents that the ONLY way for a connected device to obtain the virtual MAC address is by sending an ARP request. It clearly explains that any ethernet frames sent to the connected device must contain the PHYSICAL MAC address, not the virtual MAC address of the virtual router, and therefore the source MAC address of the ethernet frame CANNOT be used to get the virtual router MAC address. The Wiznet module has to follow the rules imposed by the VRRP protocol being used by the virtual router. Section 8.1.2 explains why it is NECESSARY for any connected device (like the Wiznet module) to perform an ARP request to obtain the virtual router’s virtual MAC address. This ARP request is a REQUIREMENT. It is NOT optional.

As far as elaborating:

  1. The MAC address associated and used for IP packets in the network is the virtual router’s virtual MAC address (00-00-5e-00-01-82). Because the switch implements VRRP (Virtual Router Redundancy Protocol), sending a packet to the physical MAC address of the switch (ec-e5-55-67-d0-0d) will NOT result in the packet being forwarded through the gateway to the rest of the network. Packets sent to that MAC address go nowhere.

  2. All ethernet packets arriving to W5100 from outside the local subnet are physically sent to the W5100 by the physical switch. They have the physical MAC address of the switch (ec-e5-55-67-d0-0d) because that is the physical device sending the packet, and ethernet is a PHYSICAL interface protocol. IP and VRRP are higher level protocols that operate with IP addresses. VRRP does some “magic” and implements virtual routers that have no real physical presence. This allows the system to replace one router (that has failed) with another router by having the replacement router take over the functionality of the same VIRTUAL router, using the same VIRTUAL router MAC address (the virtual MAC address is NOT associated with any particular physical piece of equipment). It’s called redundancy, and it makes for very high reliability networks. And it is completely transparent to any devices connected to the network. But it only works if the connected devices strictly follow the requirements of all network standards, and that means that ARP must be used to resolve the gateway’s IP address into the gateway’s MAC address.

Unfortunately, the Wiznet module fails to follow this requirement.

25

8.1.2 explains what router supporting VRRP should do in response to ARP request from the device on the network. It says nothing about requirement for that device sending this ARP request.

Once more, you say a lot of words instead of drawing the diagram how things are connected.

From your words, you have W5100, connected to switch with port MAC address of ec-e5-55-67-d0-0d, and then that switch is connected further to another switch or to router supporting VRRP.

I still think that W5100 has a right of sending reply back to switch at MAC address ec-e5-55-67-d0-0d, and then this switch - seeing that packet is designated for the outer network - performs ARP request to identify router’s MAC address and performs routing back to the router onto router’s virtual MAC address.

Why switch with port ec-e5-55-67-d0-0d does not do it? When it gets packet with IP address directed outside of the network, per your words, it must issue ARP request to know gateway MAC address, and send it to that MAC address. And as it does not, then, per your words, it also has the same issue you claim W5100 is having. Or it just does not know where gateway is (you should be able to configure it).

26

My IP address is 10.70.154.81. My subnet mask is 255.255.252.0. My gateway IP address is 10.70.152.7

Packets sent to another IP address on my subnet must be sent to the destination IP address using the MAC address of the destination IP address. And I don’t care how Wiznet gets the MAC address of the destination IP address. Any way to get it is fine with me, and the packet will be delivered just fine. Do you agree with this?

Packets sent to another IP address NOT on my subnet must be sent to the destination IP address using the MAC address of the gateway IP address. And I don’t care how Wiznet gets the MAC address of the gateway IP address. Any way to get it is fine with me, and the packet will be delivered just fine. Do you agree with this?

27

I did some test here, and see that if W5100 is an originator - of ping request or of TCP connection - for the access of remote network, then it performs ARP requests to identify gateway MAC address. I can not reproduce your exact setup, will see what I can do.

I think I agree with you, but I can not find this statement - “… clients should automatically send IP packets with a destination outside a given subnet mask to a network gateway …” in internet protocol (IP) RFC. Can you locate it please?

28

I did not get my statement regarding sending packets out of the subnet via the gateway IP address from any RFC (IP or otherwise). I thought this was basic networking 101 knowledge.

Check out this Wikipedia article regarding gateways: https://en.wikipedia.org/wiki/Gateway_address

I quote from that article:

When packets are sent over a network, the destination IP address
is examined. If the destination IP is outside of the network, then the
packet goes to the gateway for transmission outside of the network.

Also, from that article:

The gateway address must be configured on each host. The network host IP
interface binds the gateway address to the MAC address of the physical
gateway by broadcasting IP datagrams and caching the MAC address of the reply from the gateway in an ARP table stored on the host.

This “broadcasting IP datagrams” is, of course, the ARP protocol. Now, one can make an argument that an ARP request might not be necessary to obtain the MAC address of the gateway, but in the case of a virtual router implemented using VRRP, RFC 5798 clearly states that the only way the virtual router will disclose its virtual MAC address is in a reply to an ARP request. RFC 5798 clearly states that the source MAC address of an ethernet packet will NOT be the virtual router (i.e. gateway) MAC address. So there appears to be no way to route packets outside the local subnet without getting the virtual router’s virtual MAC address using ARP. Do you agree?

29

While Wikipedia is a great source of the information, I do not trust it and saw several events when text in there was totally wrong. I actually took the quote from the same article, and it needs checking against standard anyway to be 100% precise.

There could be a workaround for this problem:

  1. packets arriving from the outside with source MAC address being virtual router MAC address 00-00-5e-00-01-82, then W5100 will respond to it;
  2. if you really have intermediary device between W5100 and router (as it is still not clear), set up this intermediary device to be a routing device examining packets it receives for itself and forward packets designated for outer world to the virtual router MAC address, in other words perform the function W5100 does not currently perform.
30

Regarding your proposed workarounds:

  1. Packets from the outside cannot arrive with a source MAC address of 00-00-5e-00-01-82. Ethernet is a physical routing network layer. It only uses physical MAC addresses. In the case of VRRP the virtual router uses a virtual MAC address which does not correspond to any physical interface. (That is what allows VRRP to dynamically move the router to different redundant hardware while keeping the same virtual MAC address so the change is completely transparent to other devices on the network. The source MAC address will NEVER be the same as the virtual router (i.e. gateway) MAC address in the case of VRRP.
  2. Another switch/router (not using VRRP) between my devices and the Hirschmann ethernet switch is being considered, but might be cost-prohibitive.

So you still don’t believe that ARP should be used to translate the gateway’s IP address into the gateway’s MAC address? How about this statement from RFC 894:

Dynamic Discovery

  Mappings between 32-bit Internet addresses and 48-bit Ethernet
  addresses could be accomplished through the Address Resolution
  Protocol (ARP) [5].  Internet addresses are assigned arbitrarily
  on some Internet network.  Each host's implementation must know
  its own Internet address and respond to Ethernet Address
  Resolution packets appropriately.  It should also use ARP to
  translate Internet addresses to Ethernet addresses when needed.

Broadcast Address

  The broadcast Internet address (the address on that network with a
  host part of all binary ones) should be mapped to the broadcast
  Ethernet address (of all binary ones, FF-FF-FF-FF-FF-FF hex).

The use of the ARP dynamic discovery procedure is strongly
recommended.

I know it only says “strongly recommended”, but that carries much more weight than simply “recommended”. Also, RFC 5798 clearly states that the source MAC address of an ethernet frame from the router will be the physical address of the physical router, NOT the virtual MAC address of the virtual router (i.e. gateway). But the virtual router MUST respond to an ARP request with the virtual MAC address of the virtual router. This seems to indicate that an ARP request is the ONLY way to obtain the virtual MAC address of the virtual router.

The W5100 clearly does not work with VRRP. Every other device tested on this network to date has performed flawlessly. The W5100 is broken and should be fixed. Likewise for the W5300. The W3150A+ and W3100A are also broken, but are obsolete, so I don’t expect them to get fixed. I DO think it is in the best interests of Wiznet to fix their broken products which are still in production.

Eugeny, are you a Wiznet employee, or just another user?

31

My setup:

  • W5100 connected directly to the Windows PC;
  • W5100 configured with IP=192.168.3.55, mask=255.255.255.0, GW=192.168.3.1;
  • PC configured with 192.168.1.51, mask=255.255.255.0, GW=192.168.3.55;
  • PC running Wireshark.

Configuration is not really valid under production environment, but gives understanding on how W5100 handles the situation

  1. ping

PC sends ping request to the W5100 with source MAC being PC MAC address, and destination MAC being W5100 MAC address. Source IP=192.168.1.51, destination IP=192.168.3.55. I would expect W5100 seeing that source IP is on different subnet than destination IP, thus seeing ARP query asking for MAC address of the 192.168.3.1.

It does not happen; W5100 responds directly to the MAC address of the PC without performing any ARP requests.

  1. connecting to W5100.

Setup: opening socket 0 for listening on port 0x1000, and using telnet 192.168.3.55 4096 to connect.

Connected successfully, see no ARP requests to get MAC of configured gateway - same story, W5100 sends replies back to the same MAC address it got request from.

It seems W5500 has a workaround to the problem introducing FARP bit in the MR:

In Force ARP mode, It forces on sending ARP Request whenever data is
sent.

I do not see this functionality documented for W5100.

One more way to fix the things could be implementing W5100’s operation using MACRAW mode through socket 0 as @Ricky suggested in his reply. It is more complex, will load MCU and force MCU to manage sockets and their concurrency, but you will be free on managing MAC and IP fields of the packets.

I am not WIZnet employee, I am a user who knows about W5100, its architecture and programming slightly more than others.