Jump to content
x=usr(1536)

tnfsd not serving files (Windows Server 2019 Standard) / returns to WiFi setup

Recommended Posts

tnfsd under Windows Server 2019 Standard seems to be starting just fine and finds the path to the files to serve without issue, but does not serve files when requested.  This is with the version current as of this time of writing downloaded from https://fujinet.online/download/ .

 

When this eventually times out, the #FujiNet returns to the Wi-Fi configuration screen for a few moments, then drops back to the TNFS Host List / Drive Slots menus.

 

Output has been sanitised.

 

Internal tnfsd server is defined as redacted.example.org in TNFS host slot 5.  This is resolving to 10.10.10.10, both of which are correct.  The log below covers the timespan between selecting that host with the RETURN key, and the entire process (including drop to the WiFi configuration screen) through to returning to the Host List / Drive Slot menus.

 

Spoiler

Using '/dev/cu.usbserial-14410' as serial port.
Showing logs:
[17:41:54]
[17:41:54]CF: 70 f9 04 00 6e
[17:41:54]sioFuji::sio_process() called
[17:41:54]ACK!
[17:41:54]Fuji cmd: MOUNT HOST
[17:41:54]::mount {4} "redacted.example.org"
[17:41:54]::mount_local Attempting mount of "redacted.example.org"
[17:41:54]::mount_tnfs {4:2} "redacted.example.org"
[17:41:54]Calling TNFS::begin
[17:41:54]Resolving hostname "redacted.example.org"
[17:41:54]Resolved to address 10.10.10.10
[17:41:54]TNFS mount redacted.example.org[10.10.10.10]:16384
[17:41:56]Timeout after 2000 milliseconds. Retrying
[17:41:59]Timeout after 2000 milliseconds. Retrying
[17:42:02]Timeout after 2000 milliseconds. Retrying
[17:42:05]Timeout after 2000 milliseconds. Retrying
[17:42:08]Timeout after 2000 milliseconds. Retrying
[17:42:09]Retry attempts failed
[17:42:09]TNFS mount failed with code -1
[17:42:09]ERROR!
[17:42:09]
[17:42:09]CF: 70 f9 04 00 6e
[17:42:09]sioFuji::sio_process() called
[17:42:09]ACK!
[17:42:09]Fuji cmd: MOUNT HOST
[17:42:09]::mount {4} "redacted.example.org"
[17:42:09]::mount_local Attempting mount of "redacted.example.org"
[17:42:09]::mount_tnfs {4:2} "redacted.example.org"
[17:42:09]Calling TNFS::begin
[17:42:09]Resolving hostname "redacted.example.org"
[17:42:09]Resolved to address 10.10.10.10
[17:42:09]TNFS mount redacted.example.org[10.10.10.10]:16384
[17:42:11]Timeout after 2000 milliseconds. Retrying
[17:42:14]Timeout after 2000 milliseconds. Retrying
[17:42:17]Timeout after 2000 milliseconds. Retrying
[17:42:20]Timeout after 2000 milliseconds. Retrying
[17:42:23]Timeout after 2000 milliseconds. Retrying
[17:42:24]Retry attempts failed
[17:42:24]TNFS mount failed with code -1
[17:42:24]ERROR!
[17:42:27]
[17:42:27]CF: 70 fe 00 00 6f
[17:42:27]sioFuji::sio_process() called
[17:42:27]ACK!
[17:42:27]Fuji cmd: GET SSID
[17:42:27]->SIO write 96 bytes
[17:42:27]COMPLETE!
[17:42:27]
[17:42:27]CF: 70 fb 00 00 6c
[17:42:27]sioFuji::sio_process() called
[17:42:27]ACK!
[17:42:27]Fuji cmd: SET SSID
[17:42:27]<-SIO read 96 bytes
[17:42:27]ACK!
[17:42:27]Connecting to net: redactonet password: soveryredacted
[17:42:27]WiFi connect attempt to SSID "redactonet"
[17:42:27]E (770702) wifi:sta is connecting, return error
[17:42:27]esp_wifi_connect returned 12295
[17:42:27]COMPLETE!
[17:42:27]
[17:42:27]CF: 70 fa 00 00 6b
[17:42:27]sioFuji::sio_process() called
[17:42:27]ACK!
[17:42:27]Fuji cmd: GET WIFI STATUS
[17:42:27]->SIO write 1 bytes
[17:42:27]COMPLETE!
[17:42:27]
[17:42:27]CF: 70 fb 01 00 6d
[17:42:27]sioFuji::sio_process() called
[17:42:27]ACK!
[17:42:27]Fuji cmd: SET SSID
[17:42:27]<-SIO read 96 bytes
[17:42:27]ACK!
[17:42:27]Connecting to net: redactonet password: soveryredacted
[17:42:27]WiFi connect attempt to SSID "redactonet"
[17:42:27]E (770802) wifi:sta is connecting, return error
[17:42:27]esp_wifi_connect returned 12295
[17:42:27]fnConfig::save
[17:42:27]fnConfig::save not dirty, not saving
[17:42:27]COMPLETE!
[17:42:29]
[17:42:29]CF: 70 f4 00 00 65
[17:42:29]sioFuji::sio_process() called
[17:42:29]ACK!
[17:42:29]Fuji cmd: READ HOST SLOTS
[17:42:29]->SIO write 256 bytes
[17:42:29]COMPLETE!
[17:42:29]
[17:42:29]CF: 70 f2 00 00 63
[17:42:29]sioFuji::sio_process() called
[17:42:29]ACK!
[17:42:29]Fuji cmd: READ DEVICE SLOTS
[17:42:29]->SIO write 304 bytes
[17:42:29]COMPLETE!
Serial port closed!
redacted.example.org

 

While that's taking place, this is what tnfsd is reporting on the Windows side:

 

Spoiler

PS C:\Program Files (x86)\tnfsd> .\tnfsd.exe Q:\software\Atari\A8\
Starting tnfsd version 20.1115.2 using root directory "Q:\software\Atari\A8\"
Allocating new session for 0x00
Allocated new session for 0x29
Allocating new session for 0x00
Allocated new session for 0x4823
Allocating new session for 0x00
Allocated new session for 0x18be
Allocating new session for 0x00
Allocated new session for 0x6784
Allocating new session for 0x00
Allocated new session for 0x4ae1
Allocating new session for 0x00
Allocated new session for 0x3d6c
Allocating new session for 0x00
Allocated new session for 0x2cd6
Allocating new session for 0x00
Allocated new session for 0x72ae
Allocating new session for 0x00
Allocated new session for 0x6952
Allocating new session for 0x00
Allocated new session for 0x5f90
PS C:\Program Files (x86)\tnfsd>

 

Used ^C to drop out of tnfsd.  Note that this appears to happen regardless of whether it's run manually under administrator (such as above) or its own non-privileged account from Task Scheduler at boot.

 

Any thoughts?  This doesn't happen on any of the other hosts I've connected to (which are all external).

Edited by x=usr(1536)

Share this post


Link to post
Share on other sites

Quick additional notes:

  • Seems to work OK under Windows 10 Pro (both as administrator and unprivileged user)
  • Windows Firewall is disabled in all testing
  • Server 2019 has the mountpoint on a physical drive; Windows 10 has it on a network share
  • Brief test on Raspbian showed tnfsd to work correctly

This seems to be centred around something different in 2019, but I'm not sure what.  Going to look into this a bit further later today.

Share this post


Link to post
Share on other sites

Haven't figured this one out.  Currently building out a RasPi to run the Linux version of tnfsd and smbclient to act as middleware between the A8 and Server 2019 instance.

 

Theoretically, a W10 binary should work the same on Server 2019 as on the desktop OS.  Why it apparently isn't, I don't know.

 

If this is something the person(s) responsible for the W10 build are willing to look into, I'll provide a legitimate Server 2019 Standard key for build / test purposes.

Share this post


Link to post
Share on other sites
22 minutes ago, mozzwald said:

Have you tried building from source on the machine? That's where I'd start.

 

Negative.  I don't currently have any Windows build environments, and am loath to put one together on that particular server since my general philosophy is to never use servers in the same ways as a general-purpose / desktop machine may be.  Having said that, it's something that may be doable if I can set up a parallel installation.

Share this post


Link to post
Share on other sites

Not totally sure about this, but it looks as though this may be a Fujinet-related issue.  Maybe.  Here's what I did:

 

Ran packet captures on both the Server 2019 and Raspbian boxes for all traffic between them and the Fujinet.  Server 2019 is a VM; Raspbian is on physical hardware.  Both are using wired interfaces on the same core switch.  They're on a different subnet (and VLAN) to the Fujinet, but there are no firewall rules, etc. that would prevent traffic from crossing both VLANs in either direction.

 

Server 2019 was running the pre-built binary from fujinet.online; tnfsd on the Raspbian box it was built standalone out of a clone of the git repo.  Underlying OS, etc. are all current as of this morning on both machines.  Both ran tnfsd with highest privileges possible.

 

There are no issues with the binary starting up and running on either machine, ditto finding their path to the files to share.  Server 2019 is using a physically-attached disk; Raspbian is mounting a share on Server 2019 via CIFS.  Both appear fine in that regard and work as expected.

 

The captures showed some interesting differences: Raspbian responds twice to the Fujinet's requests, whereas Server 2019 never does (i.e., we see inbound traffic but no outbound).  Raspbian only captures four packets; Server 2019 gets ten.  This is consistent across a number (dozen-plus) of runs.

 

I'd be happy to make the captures available if it would help - just don't want to attach them publically.

Share this post


Link to post
Share on other sites

Just curious if this is something that is being investigated, or if it would be worth filing a bug in github.  I'd really like to get a public-facing TNFS server up and running, but until it can be prototyped for home usage, I'm at an impasse for doing so.

Share this post


Link to post
Share on other sites
On 2/28/2021 at 1:15 PM, x=usr(1536) said:

The captures showed some interesting differences: Raspbian responds twice to the Fujinet's requests, whereas Server 2019 never does (i.e., we see inbound traffic but no outbound). 

Firewall settings on your Winbox? Some kind of security policy in effect? 

Share this post


Link to post
Share on other sites
33 minutes ago, x=usr(1536) said:

Just curious if this is something that is being investigated, or if it would be worth filing a bug in github.  I'd really like to get a public-facing TNFS server up and running, but until it can be prototyped for home usage, I'm at an impasse for doing so.

Try accessing both your TNFS servers (raspi & windows) using the python TNFS client. If it fails also, then you've got a windows problem.

https://github.com/FujiNetWIFI/spectranet-tnfs-fuse/blob/master/tnfs_client.py

Share this post


Link to post
Share on other sites
1 hour ago, DrVenkman said:

Firewall settings on your Winbox? Some kind of security policy in effect? 

 

Firewall is disabled, and there's nothing in GPO (or software) that should be causing the traffic to drop.  It's literally just a base OS with some fileshares enabled.

 

1 hour ago, mozzwald said:

Try accessing both your TNFS servers (raspi & windows) using the python TNFS client. If it fails also, then you've got a windows problem.

https://github.com/FujiNetWIFI/spectranet-tnfs-fuse/blob/master/tnfs_client.py

 

Will do.  Is there a recommended version of python, or is anything current in the 3.x release OK?

Share this post


Link to post
Share on other sites
1 hour ago, x=usr(1536) said:

Will do.  Is there a recommended version of python, or is anything current in the 3.x release OK?

I can only get it to run on python 2.7

Share this post


Link to post
Share on other sites

Here's what I'm seeing between the MacOS test machine and the Server 2019 instance:

 

Spoiler

macos:tnfsd xusr1536$ python --version
Python 3.8.8
macos:tnfsd xusr1536$ ./tnfs_client.py server2019
Connecting to server2019:16384...
Remote server is version 1.2
Contents of /:
    .
    ..
    .DS_Store
    Homesoft Collection
    archive.org
    collections
/> cd collections
/collections> ls
Contents of /collections:
    .
    ..
    .DS_Store
    holmes cd
/collections> cd ..
/> ls
Contents of /:
    .
    ..
    .DS_Store
    Homesoft Collection
    archive.org
    collections
/> quit
Bye!
macos:tnfsd xusr1536$

 

The client seems to be working under python 3.8.8, but I still need to test against the Raspi.

Share this post


Link to post
Share on other sites

OK, here's what I'm seeing from the Macbook to the Raspi (still using python 3.8.8):

 

Spoiler

macos:tnfsd xusr1536$ ./tnfs_client.py raspi
Connecting to raspi:16384...
Remote server is version 1.2
Contents of /:
    .
    ..
    subdir
    test.txt
/> cd subdir
/subdir> ls
Contents of /subdir:
    .
    ..
    zerolength.txt
/subdir> cd ..
/> ls
Contents of /:
    .
    ..
    subdir
    test.txt
/> quit
Bye!
macos:tnfsd xusr1536$

 

Now, on the Raspi side, here's what I'm seeing while the above is taking place on the client:

 

Spoiler

[email protected]:~/build/tnfs/tnfsd/bin $ ./tnfsd test/
Starting tnfsd version 20.1115.2 using root directory "test/"
Allocating new session for 0x00
Allocated new session for 0x4567
10.1.10.100 s=4567 c=30 q=08 | Bad command
10.1.10.100 s=4567 c=31 q=09 | Bad command
10.1.10.100 s=4567 c=30 q=10 | Bad command
10.1.10.100 s=4567 c=31 q=11 | Bad command
10.1.10.100 s=4567 c=30 q=19 | Bad command
10.1.10.100 s=4567 c=31 q=1a | Bad command
Freeing session ID index 0
^C
[email protected]:~/build/tnfs/tnfsd/bin $

 

At this point, it does appear that something's not quite 100% with how the FujiNet is communicating with either tnfs server.

 

Just to level the playing field, all of the above testing was performed on both wired and wireless connections (which are the same subnet in the same VLAN).  No difference.  Internal firewall rules have been checked for transit between the LAN / WLAN and subnet that the tnfs servers are in; they're clear.  No software firewalling is in use on either server. 🤷‍♂️

Share this post


Link to post
Share on other sites

Still having this issue.  The problem with that being the case is that I can't test from actual #FujiNet hardware.

 

I did order a V1.3 #FujiNet in part to see if it made any difference, but it arrived DOA and I'm in the process of RMAing it for a replacement so that may take a while to resolve.

Share this post


Link to post
Share on other sites

OK, this one is both perplexing and refusing to die.

 

Today, tnfsd decided to start working on the RasPi for absolutely no discernible reason.  Nothing has changed since I last griped about it, and it continued to work after I a) rebuilt it from scratch for giggles, and b) installed it as a service started by systemd at boot.  In any event, I'm just going to roll with it and not invest any effort into trying to figure it out.

 

Windows' tnfsd is still exhibiting the same behaviour.  However, with the RasPi now behaving, I can use that to build things out and go from there.  Windows is going to require a different approach to the *nix versions anyway, but it should still be doable (I think).

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...