MiSTer FPGA Forum

prenetic wrote: ↑Sun Aug 14, 2022 5:32 am Interesting, there are dozens of other devices on my network that don't get a chance to release their IP address before getting powered off (IoT/smart devices are a great example), and they gracefully start back up receiving their existing lease from the DHCP server -- it seems like the MiSTer should be able to do the same.

Yeah, same here with a dozen of SonOff and self-built IoT things. Maybe they're using another type of DHCP client which are having a proper handling of old leases. Dunno. I personally don't like dhcpcd (often had troubles with it in the past) and use dhclient on my Linux boxes instead. Never got difficulties since then.

[...] whether this is expected behavior?

Definitely not. What (type of) DHCP server are you using? I'm sure that most of us are using their router's build in DHCP server...I for myself are using ISC DHCP in combination with Bind9 on my master server, which is running Debian Linux.

RealLarry wrote: ↑Sun Aug 14, 2022 6:20 am

[...] whether this is expected behavior?

Definitely not. What (type of) DHCP server are you using? I'm sure that most of us are using their router's build in DHCP server...I for myself are using ISC DHCP in combination with Bind9 on my master server, which is running Debian Linux.

Yeah, I'm using whatever build of dnsmasq comes with my router -- pretty standard issue stuff and nothing else on my network winds up with multiple addresses like this. Guess I won't really know more unless other people check their MiSTer wlan adapters with "ip address" from the shell to see if they've got at least two addresses listed like I do.

The DHCP server is supposed to do the bookkeeping of IP leases. If you're seeing duplicate MAC addresses on the LAN then you're in for trouble like this. Otherwise things should "just work".

Akuma wrote: ↑Sun Aug 14, 2022 11:12 am

• MiSTer by default uses mac address 02:03:04:05:06:07. The mac address can be changed with the mac_address_change in Scripts.

Hell, I hadn't this on the scope anymore. This and a shorter lease time should fix it.
I was just playing with my 3rd MiSTer setup which I hadn't used for some months and instead of updating the whole stuff, I rsync'ed all from my MiSTer1's SD onto MiSTer3's SD - except /media/fat/linux/u-boot.txt (which contains the MAC of eth0 set by mac_address_change). But after the first fresh boot of MiSTer3 it requested two IP addresses from DHCP because of the correct MAC (one IP) but the wrong hostname which still was "MiSTer1" (another IP). After correcting hostname to "MiSTer3", I rebooted the device which freed the two IP addresses (thanks to my fix in /etc/init.d/S40network.sh) and requested a single new IP. Done

That's a very roundabout way of going about this issue. DHCP doesn't care about hostnames. It presents a MAC and wants a lease. Your entire issue comes from duplicate MAC addresses on your segment. The DHCP server gets confused by this and by this alone, as does ARP and by extension also your local switch. The only way to structurally fix this is to guarantee that every device on your segment only ever does a DHCP request using a unique MAC.

So one must ensure that any tweaking to the MAC gets done before the interface comes up, and that such tweaking results in unique MAC's within the local network segment.

The issue cannot (!) be worked around by setting static IP's on multiple MiSTers. Collisions will keep occurring on L2 and ARP will go bonkers.

It is against spec to have duplicate MAC addresses on the same segment in just about any case, ignoring trickery to do with HA-clustering and load balancing that explicitly does this kind of trickery in a controlled and purposeful way.

Do not, under any circumstances, permit duplicate MAC addresses to coexist on a regular home network.

You're welcome to dismiss this post at will of course. It comes from decades of hands-on experience building big business networks. I haven't checked the MiSTer in detail on this issue yet because I only have a single one. I'd be happy to help with any effort to fix this structurally.

Bas wrote: ↑Sun Aug 14, 2022 12:48 pm ...Your entire issue comes from duplicate MAC addresses on your segment

I think he meant to say that the sync overwrote all unique characteristics including the mac address and host name, and after correcting those everything started working again.

Akuma wrote: ↑Sun Aug 14, 2022 1:56 pm

Bas wrote: ↑Sun Aug 14, 2022 12:48 pm ...Your entire issue comes from duplicate MAC addresses on your segment

I think he meant to say that the sync overwrote all unique characteristics including the mac address and host name, and after correcting those everything started working again.

Yep, that is most likely to be the case. But I'm not the addressee as I haven't any issue apart from this behavior today; it's @prenetic how is reporting his issues...

I've only got a single MiSTer so the duplicate MAC issue doesn't seem to show up here, I only see one MAC showing up on the port in my switch's MAC table. Poking around a bit I can see two sets of DHCP requests coming into dnsmasq from the MiSTer on startup which mirrors the information I see in both the current leases table and IP addresses on the device itself.
Separately, Wireshark is showing the first set of requests (sans hostname, for the .65 address) with a vendor class identifier of "udhcp". The second set of requests that come in don't include a vendor class identifier (they're from dhcpc), but they do include the hostname of "MiSTer" as well as an IAID which is what's causing the double lease since DUID and DUID+IAID are considered unique clients in the eyes of the DHCP server. In this case, the DUID is the MAC address according to the flag in both sets of DHCP requests. The client identifier behavior is controlled in /etc/dhcpcd.conf (default configuration shown below):
Given the use case of the MiSTer "duid" mode (DUID+IAID) isn't necessary, and on its own this wouldn't be a problem but it did lend itself to a viable albeit clumsy workaround for testing. As Akuma pointed out udhcpc wasn't completely disabled in the base image which is complicating things as again the client identifiers differ between the two sets of DHCP requests being made, leading to the double lease issue. This was likely introduced when the transition was made from udhcpc to dhcpc at least a year ago.

Related issues:
https://github.com/MiSTer-devel/Main_MiSTer/issues/448
https://github.com/MiSTer-devel/Linux-K ... /issues/29

To confirm my suspicions, I cleared the leases for the MiSTer from dnsmasq and flipped the client identifier configuration from "duid" to "clientid" in /etc/dhcpcd.conf. Now when starting up the MiSTer I only show one address in the wlan0 interface with the expected flags:
When watching dnsmasq logs I now see the same address offered for each request:
There are still two sets of requests being made (one from udhcpc, and another from dhcpc), but at least this way there's only one client identifier provided to the DHCP server, and thus only one lease allocated which ultimately gets updated with the hostname once the dhcpc requests come in. Ideally this would be resolved by fully disabling udhcpc instead of changing the default behavior of dhcpc.

That's because ifup/ifdown are hardcoded to use udhcpc. Try renaming /usr/sbin/udhcpc to /usr/sbin/_udhcpc.

Akuma wrote: ↑Mon Aug 15, 2022 12:27 pm That's because ifup/ifdown are hardcoded to use udhcpc. Try renaming /usr/sbin/udhcpc to /usr/sbin/_udhcpc.

Thanks, I was trying to make sense of everything but was having a hard time locating what I needed within the MiSTer organization on GitHub. It seems a few other people are also experiencing the udhcpc+dhcpc dual lease problem and are looking into it in the GitHub issue I linked previously. I've added my findings there also (https://github.com/MiSTer-devel/Linux-K ... 1214634815).

The "Linux Image" source of linux.img needs to be available on Github, for me to create any pull requests.

How's this coming along?