Hopefully a question easily answered

[kenp]

Is a TNFS server a network file server running the Trivial File Transfer Protocol? 

I haven't found other than a posting here anything about a TNFS server for Android anything about a TNFS server for Linux.  If it uses the TFTP then It should be pretty straight forward, I think.

[+David_P]

No, it is another protocol, originally developed for the Spectrum.

 

https://atari8bit.net/projects/software/fujinet-tnfs-server-image/

 

http://spectrum.alioth.net/doc/index.php/TNFS_server

 

[mozzwald]

57 minutes ago, kenp said:

TNFS server for Linux

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

[kenp]

Very good and thank you for the quick replies. 

I think I'm going to get the TNFS server running on a Linux machine then I'll have a good backup to the SD card in the FujiNet.  (It's always about redundancy, having a backup that's easily available.  That's why I made sure I had two 5.25" floppy drives for the task ahead.  🙂  )

[kenp]

Finally came back to this.  More experience seems to say that this is the best way to archive a bunch of floppy disks, straight to a hard drive.

I have the tnfsd.linux64 for Linux, my system's OS, have it in /usr/bin, chmod to let it execute, try running it and get a "unable to bind" message. 

No rules in the firewall to prevent activity on port 1638 (if I've remembered the port  number correctly. but no rules for anything 16xx.)  Actually, I've just double checked and the local firewall is turned off. 

Haven't tried putting it in the background yet.  Will try that after it's seems to be running okay.

Cripes, I'm getting old and slow on this stuff.

Any help appreciated.

[mozzwald]

41 minutes ago, kenp said:

I have the tnfsd.linux64 for Linux, my system's OS, have it in /usr/bin, chmod to let it execute, try running it and get a "unable to bind" message. 

Can't say I've ever heard of that error before. If you run it without any options it should exit and show you:

Usage: tnfsd <root dir> [-c <username>]

so basically, you just point it to a dir where your files are and optionally enable chroot with -c

 

What distro are you running?

[kenp]

22 minutes ago, mozzwald said:

Can't say I've ever heard of that error before. If you run it without any options it should exit and show you:

Usage: tnfsd <root dir> [-c <username>]

so basically, you just point it to a dir where your files are and optionally enable chroot with -c

 

What distro are you running?

Yeah, that's what the page of instructions said and it's likely so foolproof that no one ever wrote up a debugging page 'cause I haven't found one.  (Might be in the GIT pages but I haven't been able to figure those out, either.)

Ubuntu 20.04, running it from a terminal as root, directory for the files is /work/Atari/ with permissions 0777

Here's the command and response.  (I should have included this before.)

 

root@Socrates:~# tnfsd.linux64 /work/Atari/
setroot real path: /work/Atari
Starting tnfsd version 23.0207.1 using root directory "/work/Atari/"
Unable to bind
root@Socrates:~#

 

and what I'm using as the test set is the Holmes CDs that I downloaded.

 

root@Socrates:/work# ls -al /work/Atari
total 24
drwxrwxrwx  5 kpoole kpoole 4096 Mar 10 21:01  .
drwxrwxrwx  6 root   root   4096 Mar 10 21:20  ..
drwxrwxrwx  4 kpoole kpoole 4096 Jan 19 17:37 'Holmes 1'
drwxrwxrwx 17 kpoole kpoole 4096 Jan 19 17:37 'Holmes 2'
drwxrwxrwx 44 kpoole kpoole 4096 Jan 19 17:37 'Holmes 3'
-rw-rw-rw-  1 kpoole kpoole  428 Jan 19 17:37  index.html
root@Socrates:/work#

 

Socrates is a relatively new AMD Ryzen 7 5700G home build grossly overprovided with DRAM and HDD space.

 

If this can be got running so I can read and write directly to the .ATR files on the Linux machine I'll be over the moon.

[DjayBee]

Check if something is already listening on port 16384/udp.

 

Some time ago (I unfortunately could not find the thread) somebody else had a similar problem.

It was caused by some VoIP software (IIRC it was related to FaceTime) which uses ports 16384-32767 for RTP or something similar.

When tnfsd was started during bootup, it came first and could claim 16384 (forcing the other software to start at 16385).

[kenp]

5 hours ago, DjayBee said:

Check if something is already listening on port 16384/udp.

 

Some time ago (I unfortunately could not find the thread) somebody else had a similar problem.

It was caused by some VoIP software (IIRC it was related to FaceTime) which uses ports 16384-32767 for RTP or something similar.

When tnfsd was started during bootup, it came first and could claim 16384 (forcing the other software to start at 16385).

 

 

Found it by searching for nmap.  Lots of stuff to go through there.  Some things that might apply, some not.  Was beginning to wonder if this would be easier under Windows but not according to this thread, I think.

Thanks for pointing me to it.

[DjayBee]

This is not what I meant. It is not a problem of the binary or dustribution.

 

On Windows try

netstat -an -p UDP | find "16384"

and if it finds something run this command as Administrator and "manually" search for the line containing 16384.
The succeeding line will contain the program which opened the port

netstat -anb -p UDP | more

 

On Linux try (which immediately shows the process holding the port)

netstat -ulpn | grep 16384

 

Dunno for MacOS.

 

Now I also know why I could not find the thread: It is on FujiNet's Discord server in the apple-ii channel on Nov, 23rd.

[kenp]

1 hour ago, DjayBee said:

This is not what I meant. It is not a problem of the binary or dustribution.

 

On Windows try

netstat -an -p UDP | find "16384"

and if it finds something run this command as Administrator and "manually" search for the line containing 16384.
The succeeding line will contain the program which opened the port

netstat -anb -p UDP | more

 

On Linux try (which immediately shows the process holding the port)

netstat -ulpn | grep 16384

 

Dunno for MacOS.

 

Now I also know why I could not find the thread: It is on FujiNet's Discord server in the apple-ii channel on Nov, 23rd.

The thread I found still has some good info and I'll look more into it later but now on to the suggestion here.

 

Well, bugger me. 

I thought lets be very careful and do this after a clean reboot and get a good trace on it.  (i'd tried some of these commands and gotten conflicting results, claimed ports but no daemon.)

 

So, I do a full shutdown and start and type a few commands to get a baseline before I try the tnfsd command  then the tnfsd command to watch it bork again and the bloody thing didn't bork.  I just booted MachDOS from my Linux machine.  Here's the console capture.

 

kpoole@Socrates:~$ sudo -i
[sudo] password for kpoole:
root@Socrates:~# netstat -ulpn | grep 16384
root@Socrates:~# systemctl | grep tnfs
root@Socrates:~# tnfsd.linux64 /work/Atari/
setroot real path: /work/Atari
Starting tnfsd version 23.0207.1 using root directory "/work/Atari/"
192.168.123.211 s=00 c=00 q=00 | REQUEST cmd=0x00 TNFS_MOUNT
192.168.123.211 s=00 c=00 q=00 | TNFS_MOUNT
Looking for existing sessions with IP 192.168.123.211
Allocating new session for 0x00
Allocated new session for 0x4567
validate_dir: Path='/work/Atari/'

    ....    and it goes on and on with the log to show what's happening

 

I knew something was different when it didn't say "unable to bind" so I tried connecting to an ATR file, a DOS to boot from that isn't normally on my SD card, and it just worked.

 

Now I'm both overjoyed that it worked and puzzled as all heck about why it worked (other than giving it a clean slate to start from.)  But we take our little victories as they are granted to us.  I'll do the setup for it to automatically start in the systemd setup and see where we go from there.

 

Thank you for the help and guidance in getting this to work.

[kenp]

Definitely, a good thing has happened.  I just did a disk copy from a physical disk to an .ATR image file on the PC.

 

Yes, this is going to make the whole process so much simpler.  I can copy to the image file on the PC, rename it to the colour and number for its library and tuck it away in the right folder without needing to take the SD card out of the FujiNet.  I think I could even proceed with a blank SD card.  (it still needs the card for the print file.)

 

Great stuff.