mozzwald

You can get servers or source code from https://fujinet.online/download for linux, mac, windows

Can you try this formatter and see if it makes a difference? https://www.sdcard.org/downloads/formatter/ Where did you get the FujiNet from?

This ^ is the issue with your systemd script. To use the chroot capability it must be run by root user instead. See the example systemd script in my first post.

You're almost there... just move to the tnfsd directory and run make from there cd ~/spectranet/tnfs/tnfsd make OS=LINUX DEBUG=1 You can leave off the DEBUG flag if you don't want the extra messages but you still need the OS flag

This is interesting. SIO2BT firmware uses PlatformIO Espressif32 v3.2 and the 'normal' builds use v3.4. Still, if it worked on 6/5/22, I wonder what might be the cause. So you've tested all normal builds newer than 6/5/22 and confirmed the issue is present in all of those?

B = BOOT, it's just another hotkey to boot. I spose we could remove that since everyone uses OPTION. Interesting comment in the code: case 'B': // Taken from original config. What is that checking for? mount_and_boot();

Formatted as FAT32 is correct Can you try a firmware from early last year and see if that works? You mentioned it *might* have been working before. I still think it's an SD card (or socket) issue, but this is worth a shot.

Can you confirm this by flashing something older and testing? With latest firmware I just loaded the Micro League Baseball ATX from a 32GB SD card on FujiNet and it worked fine. I suspect a SD card issue is the culprit. Do you have another card you can try? If not, check the card for errors with a computer. Maybe backup the card, reformat it and copy everything back is worth a try too.

I've just tested this 32G card for the first time and it's working for me. Do you know what model your 32Gb card is? What OS and program did you use to format it?

@moonlight_mile the x64 docker image was update by @tschak909 https://hub.docker.com/r/tschak909/tnfsd-x64

This would be an issue with any way you run the old TNFS server. I not that familiar with docker. Maybe you can just shut it down and replace the binary inside the container?

The voltage display is only for show and does not affect any functionality so you should be ok. We are still working on the host slots bug and will let you know

ok, there could be a few things causing this. atari 5V on SIO does not have enough power and there is a large voltage drop SIO 5V pin on fujinet is bent/damaged in some way and not making good contact resistor divider or esp32 pin on fujinet is damaged somehow Are you powering the FujiNet from the Atari or with external USB power? Try powering the FujiNet with USB cable and check SIO voltage in the web interface to see if it changes

ok, well, if you have a rough idea of when the last time you updated it, go through the list of firmware and pick one from around that time and test it. I suspect you have a hardware problem but need to confirm if a previously working firmware shows the same symptoms or not.

That date means the board is indeed v1.6 which is being correctly identified by the firmware. Can you reinstall the previous working firmware you had on it and confirm if the SIO Voltage is correct or not?

You are using an old version, please use the latest updated yesterday which should have debug output enabled: https://github.com/FujiNetWIFI/spectranet/blob/master/tnfs/tnfsd/bin/tnfsd.exe Looking at your logs there I see that lseek is not called when there were 2 timeouts in a row. The other had a single timeout and received an out of order packet and continued to lseek. Perhaps it's getting stuck after 1 timeout error

The prebuilt binaries we provide have debugging enabled. If you are running with systemd, you should be able to use journalctl to get the output. Otherwise, you can run tnfsd from the command line and it spits out all the info

@tsom the latest version is 23.0207.1 which is displayed when started.

A vulnerability has been found in the TNFSD server that can allow a person to get directory listings outside of the configured TNFS root directory. We were notified of the issue on Jan 31, 2023 and have been working on a fix since that time. The fix is now available as source code and binaries in our Github repo (https://github.com/FujiNetWIFI/spectranet). Binaries at https://fujinet.online/download have also been updated. Anyone running a publicly available TNFS server should update their TNFSD server immediately. The issue occurs when requesting a directory listing with ".." which can allow viewing the file listing in directories above the TNFS root. In our testing we were not able to download or view contents of any files outside of the TNFS root, only get directory listings. The bugfix compares the absolute path of the TNFS root directory with the absolute path of the requested directory and if the requested directory is not inside the TNFS root it will return a listing of the root directory instead. This has been tested on Windows 10 64Bit, Linux 64bit and Raspberry Pi 3B+ armhf. We have also overlooked the fact that the Linux version of TNFSD has built in chroot capabilities already which would prevent this bug from happening in the old vulnerable version. Linux users can run the server with the '-c [username]' flag to start it in it's own chroot (ex: sudo tnfsd /home/tnfs -c tnfs) and we recommend using this option going forward. Windows users do not have the chroot option and must use the updated TNFSD binary. For Linux users running the server with systemd, this is an example script with chroot: [Unit] Description=TNFS Server After=remote-fs.target After=syslog.target # replace /tnfs with your TNFS directory [Service] User=root Group=root ExecStart=/usr/local/sbin/tnfsd /tnfs -c tnfs [Install] WantedBy=multi-user.target We hope our transparency and action to fix the issue shows our commitment to security and to keeping your trust. Thank you for your understanding.

I'm asking if you know the actual hardware version to determine if the hardware version detection code is broken or not. I made a small change to the detection code recently and it's quite possible something broke. Please confirm if you know for sure the actual hardware version is v1.6 (not the auto detected version that the firmware tells you). Button B Long Press and Button C Short Press on v1.3 and up hardware produce the same result, Safe Reset. If you continue to Hold Button B while FujiNet boots up it will wipe the configuration stored in the FujiNet internal memory. Maybe you are referring to the configuration reset and not a simple reset.

So, which hardware version do you actually have?

Do you know which hardware version you actually have? Your webui screenshot reports v1.6.1 but perhaps that's wrong. I noticed in your log file you did a long press of button B for safe reset which leads me to believe you may have older hardware since you did not use the button C short press.

Way back in the beginning of FujiNet a script was created in the build system to set the version number based on the git commit short hash. This is still in use. I suppose it's about time we use actual version numbers. Will chat with the rest of the team and figure something out and look into adding build date to the webui and/or config screen

It could be a network hiccup. If you hookup FujiNet to a computer and capture the debug output it will show what's happening and you might see there is a tnfs timeout. https://github.com/FujiNetWIFI/fujinet-platformio/wiki/FujiNet-Flasher#capturing-serial-debug-output

I just uploaded a SIO2BT build which is up to date with the above fixes. "version": "2023-01-30 0.5.adfa332c-SIO2BT", "version_date": "2023-01-30 02:51:10", "build_date": "2023-01-30 02:51:10", "description": "SIO2BT Enabled Firmware up to date with master",