MiSTer FPGA Forum

Found out because I couldn't connect by FTP, which was working fine before by just using 'mister' as the address. I noticed it was trying to connect to a different IP address than the MiSTer was displaying.

Changed to explicitly use that address and things worked again. Then, not even an hour later, the address had changed again. Turning my MiSTer on hours later and the address has changed yet again.

Anyone else experience this? Could this be caused by the MiSTer itself? Maybe because of a recent update? Or could this only be caused by my router?

Strange! Last Linux update was 05/01 so I suppose you would have noticed the problem earlier. If you did not change anything on your router there does not seem to have any reason for renewing the lease.
You could put your MISTer in fixed IP and see what it gives.

Ran into the same or similar problem a few weeks ago. The last digit of the IP number changed everytime i'd cold started the Mister. I've set a fixed IP in my Fritzbox and it works fine.

jca wrote: ↑Sun Jun 11, 2023 9:58 pm

Strange! Last Linux update was 05/01 so I suppose you would have noticed the problem earlier. If you did not change anything on your router there does not seem to have any reason for renewing the lease.
You could put your MISTer in fixed IP and see what it gives.

Good point. I did transfer files to the MiSTer after that date without problems and update regularly.

Retro-Nerd wrote: ↑Mon Jun 12, 2023 4:26 am

Ran into the same or similar problem a few weeks ago. The last digit of the IP number changed everytime i'd cold started the Mister. I've set a fixed IP in my Fritzbox and it works fine.

Seems to be a very similar problem here, the last digit keeps changing. Very odd how this wasn't a problem before. Maybe the router (which is part of my internet provider's modem) updated itself recently.

I guess setting a fixed IP would be a good idea then.

Surely its down to the DHCP server on your router? If its a problem then assign a static IP to it.

MrSniffles wrote: ↑Mon Jun 12, 2023 12:19 pm

Surely its down to the DHCP server on your router? If its a problem then assign a static IP to it.

The strange thing is that this is the first time, in over three years, that it is behaving like this.

Mine started doing it too about four weeks ago

That is strange. You could look at the DHCP lease lifetime on whatever device is providing the IP address and see if it is short. I think when DHCP gives out an IP address, it first pings it to see if it is in use. Maybe the IP address is pingable before it asks for DHCP and this is causing it to give out a new address each time. The simplest fix is to define it statically in DHCP, assuming the MAC address is not changing.

DiamondDave wrote: ↑Mon Jun 12, 2023 5:23 pm

Mine started doing it too about four weeks ago

Interesting. I'm not sure how long ago it was that I ftp-ed something to it. But I did address it by 'mister', so it could also have had the problem four weeks ago already, without me noticing.

Hmm, I just noticed that not only do my USB devices not work correctly after powering on, the ethernet connection is also not coming up. Then a couple of minutes later everything seem to work all of a sudden. Looks like something might be causing a long delay in the system on start-up. Maybe this is also causing the constant address changes.

For anyone having the issue of new IP addresses via DHCP on every cold boot, I'm curious if you're running into the same issue with request IAIDs I raised a while back. Some DHCP servers flat out ignore IAID and this problem likely doesn't manifest in those cases, but for those that respect it you may find this issue. Changing to clientid from duid solves the issue for me, but I have to make this change every time there's an OS update for the MiSTer.

I've written more about it here, and if you'd like try toggling this option for yourself in /etc/dhcpcd.conf the change is below. Important note, you may get one more IP address after making this change, but subsequent cold boots should be static (at least for the duration of your DHCP lease).

FROM

# 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

TO

# 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

prenetic wrote: ↑Tue Jun 13, 2023 5:24 am

For anyone having the issue of new IP addresses via DHCP on every cold boot, I'm curious if you're running into the same issue with request IAIDs I raised a while back.

I think this is it. I just did an update_all the other day after not having done one in months and ran into this. I noticed that there were several leases belonging to my MiSTer in my DHCP server all with client ids that were all just slightly different from each other.

prenetic wrote: ↑Tue Jun 13, 2023 5:24 am

For anyone having the issue of new IP addresses via DHCP on every cold boot, I'm curious if you're running into the same issue with request IAIDs I raised a while back. Some DHCP servers flat out ignore IAID and this problem likely doesn't manifest in those cases, but for those that respect it you may find this issue. Changing to clientid from duid solves the issue for me, but I have to make this change every time there's an OS update for the MiSTer.

I've written more about it here, and if you'd like try toggling this option for yourself in /etc/dhcpcd.conf the change is below. Important note, you may get one more IP address after making this change, but subsequent cold boots should be static (at least for the duration of your DHCP lease).

FROM

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

TO

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

Thanks for the tip! Sadly, this doesn't seem to make a difference. The last IP address number increases on every reboot, it doesn't even have to be a cold reboot.

I see your problems and I'm sure that's the same behavior here with a full blown ISC DHCP server (but I didn't look and didn't check it out) because I'm using an internal DNS setup and connecting to my MiSTer by it's assigned name, like "mister1.mydomain.suffix", so I don't care about IP addresses.
It is far too complex for a normal user / small network to setup such a solution, of course, but you could also setup a PI-hole system in a virtual machine or Raspberry Pi. That way you'll get a double win: a DHCP+DNS resolving system and a network AdBlock system for your browser, including smartphones and tablets.

LamerDeluxe wrote: ↑Tue Jun 13, 2023 7:06 am

prenetic wrote: ↑Tue Jun 13, 2023 5:24 am

For anyone having the issue of new IP addresses via DHCP on every cold boot, I'm curious if you're running into the same issue with request IAIDs I raised a while back. Some DHCP servers flat out ignore IAID and this problem likely doesn't manifest in those cases, but for those that respect it you may find this issue. Changing to clientid from duid solves the issue for me, but I have to make this change every time there's an OS update for the MiSTer.

I've written more about it here, and if you'd like try toggling this option for yourself in /etc/dhcpcd.conf the change is below. Important note, you may get one more IP address after making this change, but subsequent cold boots should be static (at least for the duration of your DHCP lease).

FROM

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

TO

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

Thanks for the tip! Sadly, this doesn't seem to make a difference. The last IP address number increases on every reboot, it doesn't even have to be a cold reboot.

That's a little surprising, and you've recently updated/are running the latest and greatest build? Strange you're still pulling multiple leases -- I'm curious what's showing up in your DHCP request logs, or even the raw DHCP requests.

RealLarry wrote: ↑Tue Jun 13, 2023 8:07 am

I see your problems and I'm sure that's the same behavior here with a full blown ISC DHCP server (but I didn't look and didn't check it out) because I'm using an internal DNS setup and connecting to my MiSTer by it's assigned name, like "mister1.mydomain.suffix", so I don't care about IP addresses.
It is far too complex for a normal user / small network to setup such a solution, of course, but you could also setup a PI-hole system in a virtual machine or Raspberry Pi. That way you'll get a double win: a DHCP+DNS resolving system and a network AdBlock system for your browser, including smartphones and tablets.

For sure, it's probably clear from my GitHub writeup but I'm also something of an atypical user, even still I'd run into cases where the DNS record is pointing to one of the older/unused leases that lingers around every time the last octet would increment (which is also wasteful for smaller scopes with a lot of smart devices).

All correct but shouldn't be. The DHCP/DNS should free an unused lease after a defined TTL, but I have seen routers that are having a default lease time of weeks, if not months. And MiSTers network scripts aren't freeing it's own DHCP/DNS settings after a soft reboot, as do most of these smart devices.

prenetic wrote: ↑Tue Jun 13, 2023 8:17 pm

That's a little surprising, and you've recently updated/are running the latest and greatest build? Strange you're still pulling multiple leases -- I'm curious what's showing up in your DHCP request logs, or even the raw DHCP requests.

Yes, I update regularly, usually every time I use the MiSTer. Where would I find these logs? On MiSTer? Or should my modem/router be providing these logs?

I'm starting to wonder if I'm only noticing this problem now, because of the USB detection delay problem I'm having, as I've been using 'MiSTer' as the address for a long time. This would mask this problem if the DNS record updated quickly enough.

LamerDeluxe wrote: ↑Wed Jun 14, 2023 11:18 am

prenetic wrote: ↑Tue Jun 13, 2023 8:17 pm

That's a little surprising, and you've recently updated/are running the latest and greatest build? Strange you're still pulling multiple leases -- I'm curious what's showing up in your DHCP request logs, or even the raw DHCP requests.

Yes, I update regularly, usually every time I use the MiSTer. Where would I find these logs? On MiSTer? Or should my modem/router be providing these logs?

I'm starting to wonder if I'm only noticing this problem now, because of the USB detection delay problem I'm having, as I've been using 'MiSTer' as the address for a long time. This would mask this problem if the DNS record updated quickly enough.

Yeah it'd be at your DHCP server, whether that's on your router or otherwise would be specific to your network -- you might not have visibility into it. If it's related to your USB issues I'd still expect the MiSTer to be served the existing DHCP lease instead of getting a new one, that's odd to me.

One thing/patch that could also help is to edit the file /etc/init.d/S40network and to edit the "dhcpcd" line there:

/usr/sbin/dhcpcd -k

The parameter "-k" prompts the Linux Kernel (more precisely: the network stack) to release it's assigned IP address(es) and DNS setting when rebooting MiSTer. This patch is not permanent and needs to re-applied after an OS update.
I've opened an issue at MiSTer's githup repo but it was rejected.

RealLarry wrote: ↑Thu Jun 15, 2023 9:46 am

One thing/patch that could also help is to edit the file /etc/init.d/S40network and to edit the "dhcpcd" line there:

Code: Select all

/usr/sbin/dhcpcd -k

The parameter "-k" prompts the Linux Kernel (more precisely: the network stack) to release it's assigned IP address(es) and DNS setting when rebooting MiSTer. This patch is not permanent and needs to re-applied after an OS update.
I've opened an issue at MiSTer's githup repo but it was rejected.

I don't have that line in my s40network file.

#!/bin/sh
#
# Start the network....
#

# Debian ifupdown needs the /run/network lock directory
mkdir -p /run/network

case "$1" in
  start)
	printf "Starting network: "
	/sbin/ifup -a
	[ $? = 0 ] && echo "OK" || echo "FAIL"
	;;
  stop)
	printf "Stopping network: "
	/sbin/ifdown -a
	[ $? = 0 ] && echo "OK" || echo "FAIL"
	;;
  restart|reload)
	"$0" stop
	"$0" start
	;;
  *)
	echo "Usage: $0 {start|stop|restart}"
	exit 1
esac

exit $?

I have a s41dhcpcd file as well, which also doesn't contain it. That file references a dhcpcd.conf file, which is unchanged from the default one.

LamerDeluxe wrote: ↑Thu Jun 15, 2023 10:21 am

I don't have that line in my s40network file.

Damm'it, you're right. The original script should look like this:

  stop)
	printf "Stopping network: "
	/sbin/ifdown -a
	[ $? = 0 ] && echo "OK" || echo "FAIL"
	;;

and mine is

  stop)
	printf "Stopping network: "
	/usr/bin/umount -f -a -t cifs -t nfs4
	/usr/sbin/dhcpcd -k
	/sbin/ifdown -a --exclude=lo
	[ $? = 0 ] && echo "OK" || echo "FAIL"
	;;

I'm using my patch since a year or longer, hadn't had any issues with it and can reboot and reconnect as much as I want to

Hints:

• The "umount" ensures that any mounted network mount is getting disconnected before dropping IP/DNS to prevent timeouts when rebooting

• The "ifdown" ensures that any network device is really turned down

That way one could create a "shutdown" script to drop all active connections, power down also used external devices (NAS, tty2rpi, ...) and to "cut the power line" after script is done (made by the magic of an IoT device). That's the way of an easy life I'm doing and representing
If interested, just ask.

I can confirm this issue is happening since the latest update. I never had a problem for many years, until now.

• My workaround was to map a Static MAC/IP in my router, as previously suggested.

I had the same problems as described here. Since 2019 I have never had such problems dealing with the MiSTer. This error is particularly annoying if you want to use the remote control script. I then always had to enter the 2 newly assigned digits. I finally assigned a fixed IP to the MiSTer and now everything works as usual.

prenetic wrote: ↑Tue Jun 13, 2023 5:24 am

For anyone having the issue of new IP addresses via DHCP on every cold boot, I'm curious if you're running into the same issue with request IAIDs I raised a while back. Some DHCP servers flat out ignore IAID and this problem likely doesn't manifest in those cases, but for those that respect it you may find this issue. Changing to clientid from duid solves the issue for me, but I have to make this change every time there's an OS update for the MiSTer.

I've written more about it here, and if you'd like try toggling this option for yourself in /etc/dhcpcd.conf the change is below. Important note, you may get one more IP address after making this change, but subsequent cold boots should be static (at least for the duration of your DHCP lease).

FROM

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

TO

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

Mister indeed increases the last digit of it's IP address after a reset, eventhough I have configured my DHCP server to hand out the same one based on the MAC address.

In my pfSense router, when I set the option 'Ignore Client Identifiers' for the DHCP server, Mister does take the IP address I configured for it.
It indeed this seems to be a problem with the client ID that looks to be changing with every reset?

I again disabled 'Ignore Client Identifiers' for my DHCP server and with these changes in /etc/dhcpcd.conf Mister also picks up the right IP address again. Using clientid instead of duid looks to be a better default setting...

oferinga wrote: ↑Sun Mar 24, 2024 9:51 pm

Mister indeed increases the last digit of it's IP address after a reset, eventhough I have configured my DHCP server to hand out the same one based on the MAC address.

In my pfSense router, when I set the option 'Ignore Client Identifiers' for the DHCP server, Mister does take the IP address I configured for it.
It indeed this seems to be a problem with the client ID that looks to be changing with every reset?

I again disabled 'Ignore Client Identifiers' for my DHCP server and with these changes in /etc/dhcpcd.conf Mister also picks up the right IP address again. Using clientid instead of duid looks to be a better default setting...

Yeah, unfortunately this part of the issue was never fixed. I included DHCP datagram contents in the GitHub link I posted that describes this issue in greater detail. Since many consumer routers are running a build of dnsmasq set up to handle DHCP, changing from duid to clientid will ensure the same lease is used between reboots. That said, this change will need to be repeated with every major OS update as the config will be overwritten.

The codebase for MiSTer is large and spread across multiple repos which I'm unfamiliar with, otherwise I'd have put in a pull request long ago. If someone can point me in the right direction, I'd gladly spend some time on it. Given the MiSTer installation process now generates a random client ID with proper prefix bits (instead of 02:03:04:05:06:07), there is even less of a reason to continue using DUIDs in DHCP requests even for networks that have multiple MiSTer devices.

In the meantime, manually changing the config is a viable workaround.

Popped into the MiSTer Discord and just learned that if you do modify /etc/dhcpcd.conf to use clientid instead of duid, you can then copy the config to /media/fat/linux/ and the change will be retained during OS updates. One less thing to worry about.

My router won’t let me edit non-active MAC addresses so I don’t assign static IP addresses on my router.

I have assigned my MiSTer to use a static IP address and have had no problems.

Also you may be able to access your device using mister.local or something similar. You be able to ping just ‘mister’ as well.

prenetic wrote: ↑Mon Mar 25, 2024 5:06 pm

oferinga wrote: ↑Sun Mar 24, 2024 9:51 pm

Mister indeed increases the last digit of it's IP address after a reset, eventhough I have configured my DHCP server to hand out the same one based on the MAC address.

In my pfSense router, when I set the option 'Ignore Client Identifiers' for the DHCP server, Mister does take the IP address I configured for it.
It indeed this seems to be a problem with the client ID that looks to be changing with every reset?

I again disabled 'Ignore Client Identifiers' for my DHCP server and with these changes in /etc/dhcpcd.conf Mister also picks up the right IP address again. Using clientid instead of duid looks to be a better default setting...

Yeah, unfortunately this part of the issue was never fixed. I included DHCP datagram contents in the GitHub link I posted that describes this issue in greater detail. Since many consumer routers are running a build of dnsmasq set up to handle DHCP, changing from duid to clientid will ensure the same lease is used between reboots. That said, this change will need to be repeated with every major OS update as the config will be overwritten.

The codebase for MiSTer is large and spread across multiple repos which I'm unfamiliar with, otherwise I'd have put in a pull request long ago. If someone can point me in the right direction, I'd gladly spend some time on it. Given the MiSTer installation process now generates a random client ID with proper prefix bits (instead of 02:03:04:05:06:07), there is even less of a reason to continue using DUIDs in DHCP requests even for networks that have multiple MiSTer devices.

In the meantime, manually changing the config is a viable workaround.

I'm pretty sure this change would be in one of two places:

https://github.com/MiSTer-devel/Linux-Kernel_MiSTer

https://github.com/MiSTer-devel/Linux_I ... tor_MiSTer

aberu wrote: ↑Mon Apr 22, 2024 3:06 pm

I'm pretty sure this change would be in one of two places:

https://github.com/MiSTer-devel/Linux-Kernel_MiSTer

https://github.com/MiSTer-devel/Linux_I ... tor_MiSTer

Thank you!

https://github.com/MiSTer-devel/Linux_I ... er/pull/18