LanManFS/98

Hi,
LanManFS and LanMan98 have the odd issue I am impacted by when connecting to my up-to-date Windows 11 computer since recently:

1. Multi-IP
My Windows PC has more than one IP address – this is due to the fact that I have the application guard enabled which internally installs some virtual switch since it seems to use some HyperV features.
The result is that the NETBIOS name lookup query returns both IP addresses (please do not ask why that local virtual switch IP is returned since it is pretty useless for this for connecting except locally on the Windows PC).
Unfortunately LanManFS and LanMan98 can’t cope with this since they use the first IP only and that is more often that not the wrong one resulting in a failed connection.
LanMan98 offers a work-around since I can state the server name as “hostname” and with that LanManFS uses that IP and thus does not need to rely on a NETBIOS lookup.
The good solution would be for such a LanMan client to use the IP that matches the local network, if available, and/or try all of them for reachability to take a useable one

2. IP only
Just to note that if in the connection info for the server I just enter an ip address instead of a host name both clients fail to connect
I did not try to find out why this happens – might be that the NETBIOS lookup is done using the ip address and that fails, or whatever
Until recently I didn’t cars since LanMan98 woked well.

3. Special characters
Until recently using LanMan98 worked just fine (since I was able to use the hostname notation it connected reliably).
But all of a sudden some internal changes on the Windows 11 side have the impact that in directory displays I do see file names with special characters (and for me German umlauts do happen), but I can’t access those files anymore!
Using LanManFS these files are well accessible; using LanManFS or LanMan98 to connect to my NAS those files work as before too.
So I assume some change on the Windows 11 side has some impact on LanMan98 (but not on LanManFS)

Summary
Any hint how to get either LanMan98 or LanManFS back to work with an up-to-date Windows 11 system that has more than one IP is much appreciated.
Currently LanMan98 is a pain since few files with special characters like German umlauts in the name fail to work
Currently LanManFS is useless since it can’t cope with multi IP addresses and I will not disable the application guard
Thus I have to use my NAS as work-around which does work but is a superflous additional step

Wish
A versatile, new client that
a) copes with multi IP systems
b) copes with odd characters
c) offers SMB v3
d) full IPv6 support

Unfortunately LanManFS and LanMan98 can’t cope with this

Oh, interesting.
Maybe this is why I could never get it to work with my netbook that had both wired and WiFi networking (this multiple IP addresses).

a) copes with multi IP systems

That would be good, especially if looking to support IPv6 which has multiple addresses in addition to IPv4 (sometimes it’s a wonder this stuff actually works, isn’t it?)

b) copes with odd characters

I wouldn’t hold your breath waiting for coherent UTF-8 support.

d) full IPv6 support

There is now an IPv6 stack.

c) offers SMB v3

A long standing wish, that even attracted me to the bounty scheme (at the donation side). The target amount has been reached many years ago…
(UTF-8 support is at least as urgent, of course.)

The result is that the NETBIOS name lookup query returns both IP addresses

What is the IP of your WINS Server? And which system is acting as the official WINS Server in your network? Your NAS or your Windows 11 PC?

I have here OmniClient on RPCEmu (and every RISC OS system) connecting fine to my Pi-NAS, passing over 2 different subnets and also using VLANs (I don’t allow any Windows System to use SMBv1 on my network or even sharing resources over SMB 3, they are both vulnerable and being actively exploited by both remote and local malware, so my Windows systems have only SMB Client enabled and only SMB v3).

The way to solve name resolution issues (given NetBIOS is blocked on W11, unless you really lower protection) is to use an internal DNS server and use it to resolve WINS names over Linux/BSD. For the multiple IPs on the same system, you’ll need to use port forwarding, because your software switch, not only needs to have the socket ports opened, but it also needs to know “where” to route the traffic in input on the external IP to the internal.

The configure your RISC OS as I show at the end of this article here:

https://paolozaino.wordpress.com/2023/03/07/retrocomputing-how-to-build-a-raspberry-pi-server-to-share-files-with-retro-or-vintage-systems-and-modern-platforms-part-1/

If your W11 is a laptop, I would advice against allowing RISC OS to use it as an SMB server, you’ll carry that extremely insecure configuration around even going to a caffe or any other public network. If it’s a desktop, oh well, still very dangerous, but at least it shouldn’t be used in public networks.

b) copes with odd characters

That will take a bit of work on multiple pieces of the OS: LanManFS and LanMan98, the Filer and the File System… As mentioned by Rick, I wouldn’t hold your breath waiting for it to happen soon.

All in all , I think using your NAS is probably the best solution. Keep in mind that MS is going to increase W11 security even more (especially with the new regulations UK telecommunication and network connecting device, EU CRA and the US forthcoming regulations too, so I don’t see using W11 and/or W10 as a reliable way to keep everything working on the long run)

HTH

Maybe this is why I could never get it to work with my netbook that had both wired and WiFi networking (this multiple IP addresses).

Probably had a default gateway defined on both – not good. Of course, if you set the system to disable wireless when wired is active, that problem goes away. Usually a BIOS setting in laptops.

What is the IP of your WINS Server? And which system is acting as the official WINS Server in your network?

Ah the joys of netbios settings, with a decent DHCP you can set the default 0×08 to be a more useful (in enterprise setups with a WINS server) 0×02, to reduce the broadcasts spammed uselessly round the network segment
I suspect that in the local home network with no WINS server, the broadcast option is possibly best.

    B-node: 0x01 Broadcast                                  <== THIS
    P-node: 0x02 Peer (WINS only)
    M-node: 0x04 Mixed (broadcast, then WINS)               <==  or maybe this
    H-node: 0x08 Hybrid (WINS, then broadcast)

None of the RISC OS foreign or remote filing systems cope with either reserved character translations or top bit set characters in a consistent or reversible way. The only thing I can recommend that will allow files to be transferred between any type of filing system is to stick to alphanumerics, underscore, dash and pling, which obviously wont work very well for anyone not exclusively using English.

Here are some responses (I don’t know how to to replies quoting):

UTF-8 support:
Just to make clear, it is LanMan98 connecting to a current Windows 11 failing; LanManFS has no such issue, so I dare say it is a LanMan98 issue and not the long-standing topic of a decent UTF-8 support overall.
And just to note further: LanMan98 does correctly show the files in the filer (including all special characters) but fails to copy or open those file.
The idea to use a reduced character set in file names would work around the issue somehow – but I simply am not keen to accept that limitation (though it seems for temporary quick transfers I have to at the moment)

IPv6:
I know that there is an IPv6 stack. What I meant is that LanManXX or a replacement hopefully will support that since the OS offering IPv6 does offer the platform needed but does not imply that apps will be able to use that.

WINS:
There is no dedicated WINS server – there is no need for such a server in a small local network.
And just to note it is just LanManXX having issues! With other systems like Windows, Linux, MacOS and even my SAT receiver (ok, probably running some Linux based firmware) there is no such connection issue; just with LanManXX.

Subnets:
Oops, seems to be a misunderstanding: I just meant that LanManFS/98 should if they get back more than one IP address for their NETBIOS query figure out the best one to use and trying the one in the local subnet first might be a good idea.
I know how network with subnets, routing, and even broadcasts across subnets etc. works – but that is not the issue, the issue is that LanManFS/98 fails to pick the correct IP address to use if it gets more than one; I guess they simply use the first one from the list.
LanMan98 at least offers a work-around by offering the option to tell it which IP to use.

Security:
Sure, I know that using SMBv1 is insecure and that you surely not want that enabled on a laptop on some public network; as a matter of fact on my Laptop SMBv1 is certainly not enabled. But the Windows 11 PC is my local desktop computer.
Sure I could set up a massively hardened Linux box for file sharing and then every time I transfer go through that so that SMBv1 is only enabled there – but I prefer a balance between security on one side and usability on the other and copying from Windows to some SMB server and from there to RISC OS in two steps is possible but less comfortable.
As a matter of fact when I’d take the security real serious then LanManFS/98 would be no-goers overall and I’d either consider to look into NFS, or use RPCEmu on the Windows box and from there use ShareFS (knowing the latter offering security by obscurity only). But again, we’re on my local home network where my RISC OS box shall talk to my non-portable Windows box and I want a comfortable solution.

Infrastructure:
Sure, if I set up some nice DNS, WINS etc. with all the bells and whistles I might be able to get LanManFS to connect to a multi IP windows host. But seriously? Any other system (Mac, Linux, Windows) works without all that overhead – it is just the RISC OS clients that fail to work in a normal current environment… and of the two one can connect the other can copy all files…
For now I’m stuck with using my NAS as intermediate space for my transfers since LanManFS and LanMan98 can connect and have not file name issues – except if I have reduced character set file names since LanManFS can (still) cope with those.

Like with most other things on RISC OS the clients date from the 1990s, and have stubbornly remained there regardless of minor tinkering.