Ken Gagne at A2Central.com reports:

Coinciding with his KansasFest 2024 presentation, Stephen Heumann has
released his SMB FST for GS/OS. With this file system translator installed,
any Apple IIGS (physical or virtual) with a Marinetti connection can use the Server Message Block protocol to connect to file servers that are compatible with NTLMv2 (Kerberos is not supported), including Windows, macOS, Samba, Solaris, and illumos file servers.

The SMB protocol has been around since the 1980s, and support for the Apple IIGS has long been sought by retrocomputing enthusiasts such as Eric
Shepherd, who in August 2013 announced the S-Prize as a financial incentive
to develop an SMB FST.

At KansasFest, Heumann fulfilled that promise by demoing an emulated IIGS
using the FST to open, read, write, and copy files from remote servers. Accomplishing this feat required Heumann update ORCA/C to support 64-bit integers and develop cryptography routines for the 65816.

Among the inspirations Heumann cited were not only the S-Prize, but also
Kelvin Sherlock‘s KansasFest 2018 presentation,
"So You Want to Write an FST".

https://a2central.com/2024/07/stephen-heumann-smb-fst/ https://github.com/sheumann/smbfst

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The SMB FST for GS/OS
By Stephen Heumann

The SMB FST allows an Apple IIGS to access file servers using the SMB
protocol. The SMB FST is free and open source, but contributions to support this project are welcome.

System Requirements:

- An Apple IIGS with System 6.0.1 or later
- Marinetti 3.0b11 or later
- A Marinetti-compatible network interface (such as an Ethernet card)
- If you are using an Uthernet or Uthernet II, please be sure to install the latest version of their Marinetti link layers

[...]

Compatibility
The SMB FST is compatible with Windows, macOS, Samba, Solaris, and illumos
file servers. Using a modern, currently-supported version of the server software is strongly recommended. See the Server Configuration section below for information on how to configure these servers to work with the SMB FST.

The SMB FST may also work with other servers that support the SMB 2 or SMB 3 protocols, but they have not been tested.


[...]


General Server Requirements:

In order to work with the SMB FST, a server must meet the following requirements. The default configurations of Windows, macOS, Samba, Solaris,
and illumos servers meet most of these requirements (except as mentioned above), but if you have customized your server configuration, you should
check that it follows them.

The SMB FST supports SMB protocol versions 2.0.2 through 3.0.2. The server
must support at least one of these versions.

The server must support NTLMv2 authentication.

The server must not require encryption of SMB messages.

The server may require message signing, but this substantially reduces performance, so you may wish to disable it.

The SMB FST represents file types and resource forks on the server using alternate data streams (ADSs), in a manner compatible with macOS. In order
to fully support these features, the server must support ADSs. The SMB FST
can connect to servers without this support, but some operations will not
work on them.

The SMB FST can use an Apple-specific protocol extension to improve the
speed of listing directory contents, so this should be enabled if it is available on the server.

The SMB control panel detects servers on the local network using multicast
DNS Service Discovery (mDNS-SD), so servers must support this in order to be detected. You can still connect to servers that are not detected by manually entering their address.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/23/24 9:37 AM, D Finnigan wrote:

The SMB FST for GS/OS
By Stephen Heumann

Compatibility
The SMB FST is compatible with Windows, macOS, Samba, Solaris, and illumos file servers. Using a modern, currently-supported version of the server software is strongly recommended. See the Server Configuration section below for information on how to configure these servers to work with the SMB FST.

The SMB FST may also work with other servers that support the SMB 2 or SMB 3 protocols, but they have not been tested.

I agree this is a significant piece of GS/OS development. I watched Stephen's presentation from KansasFest last night and noticed he was running his 'GS' with GSPlus on a Mac, and was able to access his shares on the same Mac. Very nice. It seems
seamless, too.

{As an aside, I'll say it was nice to see the KansasFest audience openly applaud Stephen for his work}.

So, I've been attempting to do something similar on Windows 10 with David Schmidt's GSPort and its emulated Uthernet.

I've downloaded and installed Ewen's updated v1.0.5 link layer (hat tip to Ewen - the man still rocks), installed Bonjour for Windows and tried to make a connection.

Here's the 'wall' that I'm up against -- It appears that Windows 10 *Home* doesn't have a built-in SMB 3 server, only a built-in SMB 3 client.

It does offer the deprecated SMB 1 server option, but the SMB FST won't work with that.

So, any and all suggestions are hereby solicited, short of upgrading to Windows 10 *Pro*. I tolerate Windows out of necessity -- I'm not a fan.

Am I missing something obvious?

Thanks.




Hugh Hood

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/24/2024 2:51 PM, Stephen Heumann wrote:

Windows 10 Home does include SMB 2/3 server functionality. I've tested
it with the SMB FST, and it works. I think you may just be seeing that
there is an option to _disable_ SMB 1 support, but not SMB 2/3.

There are some Windows settings that can have the effect of blocking SMB connections, such as setting the network to "Public" or certain firewall settings. If you have another modern computer available to act as a
client, I'd suggest testing with that to confirm that the SMB server is working and accepting connections. If that works but you still can't
connect from the GS, let me know.

Home versions of Windows always had somewhat limited/simplified sharing options.

With regards to the FST, it (along with AFPBridge and NetDisk) is not
stable with the MacIP Link Layer on my real ROM 01 IIgs (crashes when
trying to copy 100+kb files). I suspect there are unresolved bugs with
the link layer and/or Marinetti when transferring "large" amounts of data.

Oddly this "bug" doesn't seem to show up all that often under
GSport/GSplus and everything works fine. I can only trigger it if the
AppleTalk bridge is set to "230k" and emulate a ROM 01 IIgs. Everything
is vastly more stable with an emulated ROM 3 (I don't have a real one to
test via LocalTalk) and an emulated ROM 01 rarely crashes if the
AppleTalk bridge is set to "turbo". The Uthernet link layer seems stable
under the emulator on both ROMs. I don't have a real Uthernet card to
test on my ROM 01 IIgs.

Something unrelated you may want to add to the readme. If someone is
sharing the same folder with netatalk 2.x and samba (like A2SERVER is
setup to do), don't enable vfs_fruit, otherwise you'll have a metadata
MESS on your hands since netatalk 2.x stores resource folks in separate folders. Best to only access those shares with AFPBridge or the native
AFP client.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

D Finnigan <[email protected]> wrote:

Ken Gagne at A2Central.com reports:

…

Among the inspirations Heumann cited were not only the S-Prize

Posting a public follow up as email appears not to have been received.

I see that GitHub allows donations to support Stephen however it requires
entry & storage of credit card details. Does Stephen have a PayPal account?
I have viewed the s-prize pledges and hope that people will back them up.

Regards
Andrew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/27/2024 8:17 PM, Stephen Heumann wrote:

Donations through GitHub Sponsors are the most convenient mechanism for
me, so I'd prefer to have people donate there if they are able to. If
someone wants to donate but cannot use GitHub Sponsors, contact me
privately and we may be able to work out an alternative.

What about those that don't have a Github account?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Before I throw in the towel on getting Stephen's cool new SMB FST working for my specific use case, may I ask someone who is currently running David Schmidt's GSPort .v31 (with Marinetti / Uthernet LL 1.0.5) on a Windows 10 Home computer to see if they
can access their SMB2 shares that are on the *SAME* computer? (ie - local shares)?

Stephen was certainly correct -- Windows 10 Home does have an SMB2 server. I have it enabled and running, in fact, and have spent an embarrassing amount of time in the Windows registry (and elsewhere) and viewing Wireshark logs trying different things
suggested on the Windows help forums to make a connection.

Regardless, all I can manage is: "An SMB connection could not be established with the server."

FWIW, other TCP apps work on the emulated GSPort computer, including Ewen's Webber and SAFE2.

So, I'm just asking if perhaps it has something to do with GSPort under Windows 10 Home accessing SMB shares on the local computer.

If someone has that specific instance working, I trudge on until it works. Otherwise, I'll stop beating my head against the wall.

{Also, I don't have a modern computer to access the Windows shares via SMB2, as my old Tiger PowerMac uses SMB1}.

Thanks.




Hugh Hood


On 7/24/2024 1:51 PM, Stephen Heumann wrote:

On 7/23/24 12:39 PM, Hugh Hood wrote:

Here's the 'wall' that I'm up against -- It appears that Windows 10
*Home* doesn't have a built-in SMB 3 server, only a built-in SMB 3 client. >>
It does offer the deprecated SMB 1 server option, but the SMB FST won't
work with that.

So, any and all suggestions are hereby solicited, short of upgrading to
Windows 10 *Pro*. I tolerate Windows out of necessity -- I'm not a fan.

Am I missing something obvious?

Windows 10 Home does include SMB 2/3 server functionality. I've tested
it with the SMB FST, and it works. I think you may just be seeing that
there is an option to _disable_ SMB 1 support, but not SMB 2/3.

There are some Windows settings that can have the effect of blocking SMB connections, such as setting the network to "Public" or certain firewall settings. If you have another modern computer available to act as a
client, I'd suggest testing with that to confirm that the SMB server is working and accepting connections. If that works but you still can't
connect from the GS, let me know.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/4/2024 2:08 PM, Hugh Hood wrote:

Before I throw in the towel on getting Stephen's cool new SMB FST
working for my specific use case, may I ask someone who is currently
running David Schmidt's GSPort .v31 (with Marinetti / Uthernet LL 1.0.5)
on a Windows 10 Home computer to see if they can access their SMB2
shares that are on the *SAME* computer? (ie - local shares)?

Stephen was certainly correct -- Windows 10 Home does have an SMB2
server. I have it enabled and running, in fact, and have spent an embarrassing amount of time in the Windows registry (and elsewhere) and viewing Wireshark logs trying different things suggested on the Windows
help forums to make a connection.

Regardless, all I can manage is: "An SMB connection could not be
established with the server."

This is normal due to how winpcap/npcap's packet injection works. It is
also a limitation of VMs using bridged networking on a machine. You
would need a router that does "hairpin routing" since your emulated
machine and host machine can't directly see each other's packets.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris,

Thanks for that explanation.

One question -- if a router offers a 'port forwarding' feature, would that suffice for the hairpin routing you mention?

Thanks for the networking education. It's definitely one of my weak areas.




Hugh Hood


On 8/4/24 9:40 PM, Christopher G. Mason wrote:

This is normal due to how winpcap/npcap's packet injection works. It
is also a limitation of VMs using bridged networking on a machine.
You would need a router that does "hairpin routing" since your
emulated machine and host machine can't directly see each other's
packets.

On 8/4/2024 2:08 PM, Hugh Hood wrote:

Before I throw in the towel on getting Stephen's cool new SMB FST
working for my specific use case, may I ask someone who is
currently running David Schmidt's GSPort .v31 (with Marinetti /
Uthernet LL 1.0.5) on a Windows 10 Home computer to see if they can
access their SMB2 shares that are on the *SAME* computer? (ie -
local shares)?

Stephen was certainly correct -- Windows 10 Home does have an SMB2
server. I have it enabled and running, in fact, and have spent an
embarrassing amount of time in the Windows registry (and elsewhere)
and viewing Wireshark logs trying different things suggested on the
Windows help forums to make a connection.

Regardless, all I can manage is: "An SMB connection could not be
established with the server."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/5/2024 11:38 AM, Hugh Hood wrote:

Chris,

Thanks for that explanation.

One question -- if a router offers a 'port forwarding' feature, would
that suffice for the hairpin routing you mention?

Thanks for the networking education. It's definitely one of my weak areas.

Hugh Hood

Port forwarding will not provided this. Unfortunately "hairpin" routing
isn't a common feature in a typical consumer router.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/24/2024 9:48 PM, Stephen Heumann wrote:

Yes, there are known issues with the MacIP link layer, which likely
cause the problems you're seeing. (Basically, it does Memory Manager
calls in an interrupt handler, when it may not be safe to do so.) Maybe
the issues will be fixed someday, but for now an Ethernet card is a
better bet for stable TCP/IP networking on the GS.

I have tried testing the "patched" v1.3 revision of the link layer that disables interrupts in the buffer routines. It didn't really improve
things. Hopefully the bugs will eventually figured out. MacIP is much
more accessible to IIgs users with the introduction of devices like the TashTalk and AirTalk.

Unfortunately, 816 ASM isn't something I'm too familiar with. Setting up
the assembler environment to build the link layer was an adventure on
its own. At least I'm all setup to test any future developments.

Yes, Netatalk 2.x and Samba have incompatible metadata representations. Netatalk 3.x is more compatible with Samba, but drops AppleTalk support.
(It can be used with AFPBridge, though.)

This is being worked on. The ball has already started with adding
AppleTalk support back into a future release of Netatalk.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

This is normal due to how winpcap/npcap's packet injection works. It is
also a limitation of VMs using bridged networking on a machine. You
would need a router that does "hairpin routing" since your emulated
machine and host machine can't directly see each other's packets.

At least at some point in the past it helped to install the Microsoft
Loopback Adapter and make the traffic go to / come from there. Because that approach makes the traffic accessible by npcap.

Regards,
Oliver

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hugh,

One question -- if a router offers a 'port forwarding' feature, would that suffice for the hairpin routing you mention?

Port forwarding is used with external access to your router, allowing you to point incoming connections to specific NAS drives, webcams, or computers on your LAN.

Good routers will let you change an incoming port number, and redirect it to a different port number on a specific device. This would allow you for instance to have multiple NAS drives on your LAN, with each one responding to FTP Port 21, but then to
access them individually from outside by using unique port numbers in the FTP client.

Cheers - Ewen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Speccie <[email protected]> Wrote in message:r

Hugh,> One question -- if a router offers a 'port forwarding' feature, would that suffice for the hairpin routing you mention?Port forwarding is used with external access to your router, allowing you to point incoming connections to specific NAS drives,

webcams, or computers on your LAN.Good routers will let you change an incoming port number, and redirect it to a different port number on a specific device. This would allow you for instance to have multiple NAS drives on your LAN, with each one
responding to FTP Port 21, but then to access them individually from outside by using unique port numbers in the FTP client.Cheers - Ewen

I never understood this, thx!
--
~Die then Soar~


----Android NewsGroup Reader---- https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)