MiSTer FPGA Forum

Hi, everyone.

I have multiple MiSTer setups at home, some of which use the cifs_mount.sh to point to a share on a Synology NAS. Recently, I just upgraded one of them with a MiSTer Multisystem I/O board and case, and took that as an opportunity to do a fresh install with a new SD card.

Setup went as expected for everything, but I haven't been able to get cifs_mount to work on the new setup. I've double-checked hostnames, credentials, settings, etc. to make sure everything matches the original setup.

Here's what I've done to debug:

• The MiSTer itself is getting an IP address and a solid network connection (the new update_all works without a hitch).
• I've tried updating the "vers" number in the advanced options argument to both suggestions, and neither worked.
• I tried toggling WAIT_FOR_SERVER with no luck either way.
• I can successfully ping the network share from the MiSTer terminal.

My second setup (in the living room) wasn't having any problem, I tried moving my Multisystem to the living room, swapped out all the physical connections, and tried again. No luck. I tried copying the script and ini verbatim from the living room setup to the Multisystem, but that also didn't work.

By "not working", I mean the cifs_mount script shows the terminal screen and the root login confirmation, and then it hangs with no further status updates, though the cursor continues to blink and I see the expected garbage when I try hitting hotkeys to escape. I have to hard reset to leave this screen or otherwise return to the menu. One odd symptom: after about twenty seconds, the MiSTer menu/desktop background starts to periodically flash on the screen for a frame before showing the terminal output again.

Does anyone have any thoughts on why this would be working on one MiSTer but not the other?

Thanks.

Do you happen to have both a wired and a wireless connection at the same time? That always causes grief. If you can, always use the wired connection, and unplug any wireless cards. It's got a dedicated gigabit, so it's faster and it doesn't bottleneck any USB drives you have attached.

We had someone a few weeks back who had enormous trouble with their wired connection when they plugged in an adapter with Bluetooth and Wifi, even though they didn't configure the Wifi part. As soon as they took the adapter out, everything started working, IIRC.

If you have multiple misters on a network you have to adjust their mac addresses or they all show up as one mac address

Thanks for your replies.

No, I'm not using wifi on either setup. My connection always drops during update_all, so I'm using a wired connection in both places now. Unless the MiSTer Multisystem board has an integrated wifi module (quick Googling seems to suggest not), then there shouldn't be a conflict.

That's interesting about the MAC addresses, though. I don't use both MiSTers at the same time, but I found the mac_address_change.sh script and ran that on the Multisystem, just to be safe. No luck, unfortunately.

The duplicate MAC thing definitely might be causing the issue. Make sure the other Mister is fully powered off, and maybe reboot the NAS if that's not too painful. If that would disrupt things, turning off the other Mister and waiting fifteen minutes should clear the ARP cache on the server, meaning it will forget whatever MAC was in use.

Then see what happens with mounting on the Multisystem Mister. If it works, that probably means you do have a duplicate MAC. Type "ifconfig -a" at a command prompt. What you're looking for is the 'eth0' block, and then the third line down says "ether" followed by hex digits. I don't remember the default, but I think it's something like 02:03:04:05:06:07. If you see something with that kind of pattern, that means you're still using the default MAC.

To fix that, edit the file /media/fat/linux/u-boot.txt. If you're mounting the card to edit from Windows, it will be linux/u-boot.txt off the root. It should say something like this:

ethaddr=38:22:18:94:44:16
v=loglevel=4 usbhid.jspoll=1 xpad.cpoll=1

The first line sets your MAC address. It should be something random, you can just pick numbers you like. Each Mister should have a different one.

The second line sets your polling rate to be 1000Hz for both XBox controllers and regular joysticks. You don't have to have it, but it's a good idea.

If you save the file, and then cold boot the Mister and do another ifconfig -a, the eth0 block should now list "ether" as being the random numbers you typed in. Assign a different random number to the other Mister, ensure it's working, and then see if you can mount your share from both simultaneously.

It's been a while, but I finally resolved the issue. I don't know why the issue was resolved, but I figured I'd post again here in case another Internet stranger has the same issue.

First, as suggested here, I ran the script to change the MAC address. I'm pretty sure the script did its job - my MiSTer lost the IP assignment that had been setup for the old MAC address - but it would still hang whenever I ran the script.

I tried taking the SD card out of the working living room setup, and putting it in the non-working MultiSystem... and it worked. I copied cifs_mount.sh from the working SD card over to the non-working one, and sure enough, everything ran fine. So, it was the script file I was using.

The working file is version 2.0.1, and I edited directly instead of setting up an INI file. The non-working file is also 2.0.1, but I configured it with an INI file, and I did not set MOUNT_AT_BOOT to true. Otherwise, all the configuration options are the same.

Not really sure what's happening, but I'm thrilled that it's finally working again.

Double check your u-boot.txt. At least one version of the MAC address script would blow away the existing file writing the new MAC argument. You want to be sure that "v=loglevel=4 usbhid.jspoll=1 xpad.cpoll=1" is still there, if you want 1ms polling on your controller(s).