[lwip-devel] ETHARP_TRUST_IP_MAC and IGMP querier

[Frédéric BERNON]

Hi,

 

I meet a new problem on the field, and I'm not sure of the device which implement the right behavior (lwIP vs CISCO) :

 

I got a lwIP device plugged on a CISCO 3750 switch. This last is the network IGMP querier, but also implement a inter-VLAN routing. To do that it implement a virtual MAC address (which cause the problem, I will explain later). I got this network configuration :

 

 

lwIP Device : MAC 00:13:bd:00:07:6a, IP 10.10.0.39 / GW 10.10.0.254

 

CISCO 3750 (on the interface connected to the lwIP device): MAC 00:15:62:cf:1a:c2, IP 10.10.0.254

 

PC "pinger": IP 10.4.250.15 (connected on the CISCO 3750, but on another VLAN than my lwIP device).

 

I attach a wireshark capture done on the link between the lwIP device and the CISCO.

 

 

Now, the problem: due to the VLAN configuration, the CISCO send its IGMP Query message with the "good" IP (10.10.0.254), but with another "virtual" MAC address : 00:15:62:cf:1a:80 !!!! Of course, the CISCO doesn't recognized this MAC address as one for routing packets !!!

 

To show the problem, I ping from my PC to my lwIP target. Before the IGMP query, no problem. But when the CISCO send it - with a different MAC address but with the same IP, I lost any unicast communication with my lwIP device (no ping, no http...).

 

The problem is that my lwIP target is build with ETHARP_TRUST_IP_MAC=1, so, when it received the IGMP query, it change its ARP table, and all packets sent to the gateway are sent to the wrong MAC address, so ping stop to work !!!

 

You can see in the capture that echo reply from lwIP target are sent to 00:15:62:cf:1a:c2 before IGMP query, and to 00:15:62:cf:1a:80 after. Of course, the CISCO doesn't route the echo reply because it doesn't route unicast packets (I suppose it drop them) when it received them with 00:15:62:cf:1a:80 as destination ethernet address.

 

If I build with ETHARP_TRUST_IP_MAC=0, no problem.

 

My question is : is it legitimate for the CISCO switch to send packets with a different MAC address that its interface one (and with the same IP)?

 

If it's legitimate, shouldn't we change the ETHARP_TRUST_IP_MAC=1 code to only call etharp_ip_input if the dst ip address is not a multicast one? Same for broadcast ?

 

Thank you for your comments...

 

 

 

ETHARP_TRUST_IP_MAC.pcap
Description: Binary data