Init rcS Speed / Faster MiSTer Boot Time

[RealLarry]

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.

[prenetic]

[...] 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.

[Bas]

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]

• 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.
• Set a short dhcp-server lease time eg: 900 secs (15 mins). Leases will expire after 15 mins and will be removed from the lease-table in your dhcp-server.
• The reboot function in MiSTer does not trigger shutdown scripts as stated by RealLarry. If a dhcp lease is not released, the next request for the same lease will take longer. So run the poweroff script and check if you still have the same issues.

[RealLarry]

• 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

[Bas]

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.

[Akuma]

...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.

[RealLarry]

...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...

[prenetic]

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.

Code: Select all

user@router:~$ tail -f -n 0 /var/log/dnsmasq.log | grep -i 'b4:b0:24:29:08:21'
Aug 14 11:09:20 dnsmasq-dhcp[4826]: DHCPDISCOVER(bond0.10) b4:b0:24:29:08:21
Aug 14 11:09:20 dnsmasq-dhcp[4826]: DHCPOFFER(bond0.10) 192.168.10.65 b4:b0:24:29:08:21
Aug 14 11:09:20 dnsmasq-dhcp[4826]: DHCPREQUEST(bond0.10) 192.168.10.65 b4:b0:24:29:08:21
Aug 14 11:09:20 dnsmasq-dhcp[4826]: DHCPACK(bond0.10) 192.168.10.65 b4:b0:24:29:08:21
Aug 14 11:09:22 dnsmasq-dhcp[4826]: DHCPREQUEST(bond0.10) 192.168.10.68 b4:b0:24:29:08:21
Aug 14 11:09:22 dnsmasq-dhcp[4826]: DHCPACK(bond0.10) 192.168.10.68 b4:b0:24:29:08:21 MiSTer
Aug 14 11:09:46 dnsmasq-dhcp[4826]: DHCPREQUEST(bond0.10) 192.168.10.68 b4:b0:24:29:08:21
Aug 14 11:09:46 dnsmasq-dhcp[4826]: DHCPACK(bond0.10) 192.168.10.68 b4:b0:24:29:08:21 MiSTer

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):

Code: Select all

# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid

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:

Code: Select all

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether b4:b0:24:29:08:21 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.68/24 brd 192.168.10.255 scope global dynamic noprefixroute wlan0
       valid_lft 86170sec preferred_lft 75370sec

When watching dnsmasq logs I now see the same address offered for each request:

Code: Select all

user@router:/etc/dnsmasq.d$ tail -f -n 0 /var/log/dnsmasq.log | grep -i 'b4:b0:24:29:08:21'
Aug 14 13:25:06 dnsmasq-dhcp[30909]: DHCPDISCOVER(bond0.10) b4:b0:24:29:08:21
Aug 14 13:25:06 dnsmasq-dhcp[30909]: DHCPOFFER(bond0.10) 192.168.10.68 b4:b0:24:29:08:21
Aug 14 13:25:06 dnsmasq-dhcp[30909]: DHCPREQUEST(bond0.10) 192.168.10.68 b4:b0:24:29:08:21
Aug 14 13:25:06 dnsmasq-dhcp[30909]: DHCPACK(bond0.10) 192.168.10.68 b4:b0:24:29:08:21
Aug 14 13:25:08 dnsmasq-dhcp[30909]: DHCPREQUEST(bond0.10) 192.168.10.68 b4:b0:24:29:08:21
Aug 14 13:25:08 dnsmasq-dhcp[30909]: DHCPACK(bond0.10) 192.168.10.68 b4:b0:24:29:08:21 MiSTer
Aug 14 13:25:33 dnsmasq-dhcp[30909]: DHCPREQUEST(bond0.10) 192.168.10.68 b4:b0:24:29:08:21
Aug 14 13:25:33 dnsmasq-dhcp[30909]: DHCPACK(bond0.10) 192.168.10.68 b4:b0:24:29:08:21 MiSTer

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.

[Akuma]

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

[prenetic]

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).

[Akuma]

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

[held]

How's this coming along?