I am working on a Verdin project. I have enabled the WiFi connection on the module. I have configured my DHCP server to allocate a reserved fixed IP address to the Ethernet MAC address, but I have made no such reservation for the WiFi. Both the Ethernet and WiFi interfaces seem to be working fine.
However, I am getting warnings on my Windows development PC from my anti-virus software that there are duplicate IP addresses on the network.
Looking at my DHCP server, I see that it has:
Allocated two IP address to the Ethernet network using the MAC address as per the serial number of the module. One IP address is the reserved fixed one, and the other has been allocated from the free list.
Allocated the same two IP addresses to the WiFi network using a different MAC address (which I assume is the one in the WiFi component on the Verdin).
The following screen shot shows the DHCP allocations. 10.0.0.13 is the reserved address and 10.0.0.159 is the one allocated from the free list.
I have no idea why this is occurring, nor whether it is a problem with the Verdin module or the DHCP server. I have had no issues before with this DHCP server. It seems that after enabling the WiFi on the Verdin, it is somehow requesting two IP addresses on each network.
FWIW, it seems that I can only Ping the reserved IP address on the Ethernet network, and the freely allocated address on the WiFi network, not the other way around.
Any ideas on what might be causing this, and how to fix it?
Seems a bit interesting how the interfaces are sitting on the same subnet? Can you change your dhcp server to allocation addresses to the wifi side from a different subnet vs the ethernet? Is there a reason they need to exist on the same subnet?
I actually want both interfaces on the same subnet. As I said, they both seem to work fine so there is no problem there.
I forgot to add in my original post that ifconfig shows what I would expect - i.e. only one IP address on the ethernet, and one IP address on the WiFi. So nothing funny there.
Perhaps there’s a bug in your DHCP server (Wi-Fi rooter?). Does address pool setting in server include this fixed address? Try making fixed addresses excluded from DHCP address pool. If that doesn’t help, then perhaps DHCP server returns IP by name of lease-active device, ignoring the fact MACs are not always the same for equally named devices?
Regarding fixed address. Toradex Linux devices come with enabled avahi. You can ping/connect specific device from Windows by device name, just add .local suffix at the end, like verdin-xxx.local. Device name can be changed to something shorter and more easy to enter
At one point I also suspected the DHCP server, but I cannot explain how it is inter-relating the two MAC addresses - it should have no knowledge of the fact that they come from the same physical device. So that makes me suspect it’s the device (or more specifically the Linux ICMP client). Very strange.
I do have the fixed address excluded from the pool, so it’s not that.
I have come across some circumstances where the “.local” suffix doesn’t work, that’s why I am using the fixed IP address.
Have you looked at some wireshark captures of what is going on?
Perhaps there is some sort of proxyarp going on somewhere?
Is bridging the two interfaces together so they only require a single IP address an option?
As you may see Device Name send from DHCP client to DHCP server is the same on LAN and WLAN. This is root of my guess that perhaps bug lets DHCP server to return IP of “the same device” ignoring real MAC. BTW how does it reserve IP? Does list of reserved IP’s specify MAC + IP, or indeed device name + IP? Please check that list.
I install Torizon 5.6.0 on Verdin iMX8M mini and connect WLAN and LAN to a Ubiquiti EdgeRouter X. But I don’t see two IPs assigned to the same LAN on Verdin iMX8M Mini. The two IPs are assigned to WLAN and LAN respectively. You can try with another DHCP server or router.
@Edward I think you may be right that the DHCP server is relating the two because of the name. But it shouldn’t do that. As far as I recall ARP requests only contain the MAC address - no name information. The DHCP server must be getting the name later after the ARP has done its thing. The reservation is done using the MAC address, not the name.
@benjamin.tx Thanks for checking this. What you show is what I expected to see.
I think it must be an issue with the DHCP server. At the moment I’m not in a position to test another one but I will do so in the near future. If I find anything that sheds light on this I will post a response.
Right, it shouldn’t do that, but bugs cause weird things.
DHCP has nothing to do with ARP. ARP is for “what is the MAC of given IP on my subnet”. Requests to DHCP, which should happen prior to any ARP requests, are “I’ve no IP, my MAC is X, my name is Y. Please give me my IP”.
I’d try connecting windows laptop with LAN and WLAN the same way. Though Wireshark must be prepared first, I guess Windows may notice duplicate IP and renegotiate with DHCP sooner than you may read your current IP’s.
