RPCEmu, LM98 and Windows 10 problem

RPCEmu 0.9.4/5.29 running on a Windows 10 Home Edn laptop, and I’m trying to set up LanMan98 version 2.08 (16 Feb 2021), which is the current, W10-friendly, one AIUI, to connect to a Documents folder on the PC, which I have shared via the ‘Properties-Advanced Sharing-Shared’ dialogue. This is accessible via LM98 on my Pi4, and I’m using exactly the same share name, server name and path under RPCEmu. But it won’t connect, and returns a ‘Timed out while connecting’ error every time. RPCEmu is using NAT to connect to the outside world, and CloudFS works fine (in fact, it comprises the only working ‘common’ folder between the two systems).

Any advice or suggestions will be gratefully received!

EDIT: I /have/ enabled SMB1.0/CIFS file sharing support in Windows.

Hi George,
it sounds to me you’re having some routing issues, but I cannot tell without more details.

In my case, I am using RPCEmu and !Omniclient, this because LM98 v2.06 did not work in my configuration, while !OmniClient worked fine.

If you want to try !OmniClient then:

I have configured LMTransport to IP (default is NetBEUI, this is deprecated by a very long time), to do this, open a TaskWindow and run:

*conf. LMTransport IP

I also have specified an LM Server IP, this because when using RPCEmu in NAT networking, the SMB Broadcasting doesn’t work, so RISC OS requires expressly to configure a nameserver, if you have a WINS name server in your network, then try:

*conf. LMNameServer <the-IP-of-your-wins-nameserver>

The above is not necessary if RPMEmu has a way to resolve the server machine name (if you are using a machine name).

In my case RPCEmu access the Samba resources fine and it can read and/or write on the remote resource.

This makes me think that, because the resource you’re trying to access is local on the same machine that is running RPCEmu, there might be some routing issue.

Do you have any log?

RPCEmu 0.9.4/5.29 running on a Windows 10 Home Edn laptop, and I’m trying to set up LanMan98 version 2.08 (16 Feb 2021), which is the current, W10-friendly, one AIUI, to connect to a Documents folder on the PC, which I have shared via the ‘Properties-Advanced Sharing-Shared’ dialogue.

As in bold – is that the same PC as the RPCEmu instance is on?

Yes: I only have the one PC; an Acer laptop. FWIW, RPCEmu had no problem connecting to shared folders under Windows 7, but i recently upgraded to Windows 10, as I do internet banking on the laptop.

I have configured LMTransport to IP

Done that.

RISC OS requires expressly to configure a nameserver, if you have a WINS name server in your network

I don’t, so I’ve set up my laptop as one in TCP/IPv4-Properties-WINS using its IP address, and restarted Windows. When I tried configuring RPCEmu (*Configure LMNameServer etc) it returned ‘Bad parameter’. Not sure if its allowed to configure a WINS server in this way: any suggestions?

WINS is not needed – the main thing necessary is to enable SMB v1 in the windows features since LanManFS and LanMan98 are still only supporting the old, insecure SMBv1 protocol.
Furthermore you need to use the hostname to connect to Windows – be it thanks to a name server, a hosts file, or by a host name like this: hostname<192.168.1.2>, that is the host name and in <> the IP address.
Same applies to Windows 11 BTW.

*Configure LMNameServer etc) it returned ‘Bad parameter’

The server given to LMNameServer must be an IP address – it’s stored in only 4 bytes of CMOS. If you try giving it a server name it’ll tell you that’s a Bad parameter. Typing *Configure on its own shows you the expected syntax of the respective commands.

Hi George,
as Sprow correctly pointed out, the parameter is an IP Address (I have mentioned it in my previous post). However, LMNameServer is not needed if you do not have a NetBIOS/WINS Server configured on your network/host (as pointed out also by Herbert).

Anyway, given the lack of logs available, I had to reproduce your problem and I managed to do so.

I can confirm that it’s a routing problem between Windows 10 Host and RPCEmu NAT network as I suspected at the beginning. In other words, it won’t work by using RPCEmu Networking in NAT mode.

To solve this problem it’s a bit complicated, and it involves configuring RPCEmu networking in BRIDGE mode (instead of NAT). You can have a look at the documentation here for configuring the “Ethernet Bridging” on Windows 10:

https://www.marutan.net/rpcemu/manual/net-win.html

Please note: the documentation there needs to be followed carefully and to the letter. There are just two minor mistakes:

1) When Installing the TAP Driver from OpenVPN, you do not need to install the whole OpenVPN, the TAP Driver is selectable from the installation Package you can find here:

https://openvpn.net/community-downloads/

2) The 2nd mistake is at the end of the procedure. If you have followed the procedure while your RPCEmu was running, then the Reset it asks for is not enough. You’ll also need to close RPCEmu and re-open it again before the Ethernet Bridge will work correctly.

If you manage to configure your Windows Host correctly then RPCEmu will also be able to use the old Acorn ShareFS protocol and so will be able to talk directly with your Raspberry Pi running RISC OS.

However there are few caveats:

• When using RPCEmu via Ethernet Bridge it will be slower at connecting to thing than when using NAT Network option.
• I have noticed that, sometimes when you reboot RISC OS and RPCEmu is in bridged networking and you’re using the recompiler (faster) then RISC OS does not reboot and you get a black screen. This can be solved by closing RPCEmu and reopening it again.
• To improve interconnectivity between RPCEmu and the Windows Host there is a way, but it’s not easy and requires to install vSwitch which will allow to create a virtual switch between the two and that can help performance, but it introduces more complexity.

For everyone else that may want to attempt this in the future, you’ll also need to ensure that:

• Your Windows Firewall allows connections for the SMB protocol
• Your Windows is configured to allow SMBv1 and non encrypted passwords (very insecure!)

Hope this helps and good luck! :)

Anyway, given the lack of logs available, I had to reproduce your problem and I managed to do so.

Well done, Paolo – and thanks!

it involves configuring RPCEmu networking in BRIDGE mode

Ah! I was afraid that might be the case. As a long-time user of RPCEmu I am familiar with bridging as it was the only option until NAT was introduced relatively recently. It was always fiddly to set up – you’re quite right there – and it was a great relief when NAT rendered the process unnecessary. To be honest, I’ll probably stick to NAT and rely on CloudFS as the go-between on the Windows side. But many thanks for your time and trouble, and it will no doubt be very helpful to other W10 users – I can’t be the only one to encounter the issue.

EDIT: I’m pretty sure this problem was not present under Windows7 + RPCEmu + NAT. Does that make sense?

EDIT 2: Herbert is right – I’ve just tested it :-o! Adding the server’s IP address in <> after Server Name enables connection, here at least, under NAT. Would someone else kindly test this (Paolo)?

RPCEmu’s hostfs supports symlinks which allow folders on the host machine to appear within hostfs. Below is the syntax for Windows 10 with Powershell run as administrator. Paths can be copied from File Explorer using the tool in the ribbon.

PS C:\WINDOWS\system32>  cmd /c mklink /D "C:\Users\djp67\RPCEmu\RPCEmu527\hostfs\SymLink\Public" C:\Users\Public
symbolic link created for C:\Users\djp67\RPCEmu\RPCEmu527\hostfs\SymLink\test <<===>> C:\Users\Public
PS C:\WINDOWS\system32> cmd /c mklink /D "C:\Users\djp67\RPCEmu\RPCEmu527\hostfs\SymLink\vrpc" "C:\VirtualAcorn\VirtualRPC-DL\HardDisc4"
symbolic link created for C:\Users\djp67\RPCEmu\RPCEmu527\hostfs\SymLink\vrpc <<===>> C:\VirtualAcorn\VirtualRPC-DL\HardDisc4
PS C:\WINDOWS\system32>

I hadn’t realised hostfs supported symlinks

PS C:\WINDOWS\system32> cmd /c mklink /D “C:\Users\djp67\RPCEmu\RPCEmu527\hostfs\SymLink\Public” C:\Users\Public

I’m pretty sure the quote marks around the parameters are only required if there is a space in the parameter string.

For users with Win7-8.1 (or anything without powershell 7) I think this will do the job:

Open the CMD prompt as administrator and then type something like:

where D:Public is a directory with Public access and the directory symlinks must exist in your RPCEmu root directory
Feel free to select your target shared directory :)¹

If you have a NAS mapped as something like Z: then mklink /D d:\RPCEmu\hostfs\symlink\PCPublic z:
will give you a link into the NAS share

Prior to Win7, I think you need something like Junction

¹ I’m not a fan of dropping large amounts of data in \Users – that’s probably due to the horrors of roaming profiles with silly large content in the profile (MS have a different opinion, which is why Teams dumps itself in the profile.)

Open the CMD prompt as administrator and then type something like:
mklink /D d:\RPCEmu\hostfs\symlink\PCPublic d:\Public

Recently, I was given this tip by Vince Hudd for use in the Linux version:

cd /home/john/rpcemu-0.9.4/hostfs
ln -s /home/john/pCloudDrive pcloud

I now have a directory pcloud sitting amongst all the other directories when I open HostFS from the icon bar. Objects are now downloaded into RPCEmu as fast as my system will cope with.

Vince also pointed out that the AddTinyDir <path to the symlink> would put it on the icon bar for even quicker (more convenient?) access.

Same applies to Windows 11 BTW.

About that… https://www.theregister.com/2022/04/20/smb1_uninstalled_by_default_windows_11/

smb1_uninstalled_by_default_windows_11/

If you create a symlink, as above, then I don’t think the OS in RPCEmu needs to worry about the attached network device being SMB1, SMB2, or even SMB3

Probably a bit of a pain for non-RPCEmu users though, but this is “RPCEmu” forum.