LanMan98 2.06 Connection lost (4)

A VRPC-DL RO 6.20 running under Win 10 Pro, fully updated. Two harddrives C: and D:

After working without pain since last year…
Suddenly LM98 is failing to connect to the two Shared drives or directories on the computer, presenting a “Connection lost (4)” error every time.

However LM98 will still connect successfully with Shared Drives and directories on the other computers on our home LAN. (Win 10 and Win 7 computers).

As it is specific to this computer (nb:1) I wondered if it might be IRPStackSize being a bit under sized, but tweaking that has not changed the situation.

Anyone here have some idea what’s going on and maybe a fix.

Thanks

Dave

Nb:1 My Notebook, also running Win 10 and a mirror of the above mentioned VRPC-DL… The (Same) LM98 connects with the Notebook’s Shared Harddrive and Directories okay.

D.

You say your Win10Pro machine is fully updated, does this mean the other Win10 computers aren’t? If so I’d be suspicious of a Windows update causing the problems (is it possible your other Win10 machines haven’t got the Fall Update since with my computers Windows would still say it was up to date even when it hadn’t got this big upgrade. So maybe if you keep updating one of your other Win10 computers and it stops working too you’ll have the cause even if you dont have the solution.

One thing you could try on the VRPC main PC would be to try disabling the firewall and trust builder endpoint (name from memory) services through services.msc and disabling/snoozing any other firewall/antivirus software through their own configuration to see if its firewall related.

Belarc Advisor reports both machines running W10 are up to date with Win 10 version 1709 build 16299.309

Considering LM98 is reaching remote machines on the LAN okay, One Win 10, two Win 9 pro, but only failing to connect with the machine it is on, I don’t think it is a firewall problem, but as part of my testing I did have a temp switch off of the firewall, no change in the LM98 situation.

I also removed all VRPC permissions in the firewall configs, then reinstated them, no change with LM98.

AV temp switched off, no change.

Thanks for your thoughts.

Dave

Does anyone know what causes “Connection lost (4)”? That surely is key to the diagnosis.

I’m stabbing in the dark somewhat, because I use neither Windows (any version) nor VRPC, but I think the usual reasons for failure to connect include that LanMan98 only supports older versions of protocol and/or encryption methods that are being turned off. Every time MS force an update on a computer, the settings that the user carefully makes to re-enable them are disabled again.

Mnnn! Interesting thoughts Mr H.
I’m really just a user of computers with a very little knowledge of behind the UI, and I find matters networking very arcane…

So just to assuage my annoyance I’d also like to know what “Connection lost (4)" is, but as per usual error messages are to the average user meaningless. (self edited other words). (Cannot find any relevant info after much online searching either).

With regard to LM98… Up until now the only thing I’ve needed to repair after a Win 10 update is “Sharing and Permissions” which updates mess with, after that LM98 would work again.

What I really can’t get my head around is why will LM98 connect with remote computers on the LAN but won’t communicate with the Shared Harddrives upon which it is installed.

To add to my confusion, within VRPC I have Mounts for the two Harddrives C: and D: and they connect okay?

No doubt different Protocols in play, but I wouldn’t know, would I? ;-)

Item one by one, I’ve compared the security and network setting of both Win 10 computers and they are AFAIKS the same.

Dave

Sans typo, that last sentence should be…

Item one by one, I’ve compared the security and network setting of both Win 10 computers and they are AFAICS the same.

D.

Dave,

Could it be that SMB v1 is turned off?

From Bernard Veasey’s helpful networking guide the following text may be of help.

“If you get the error: ‘Connection reset by peer’, go to:  Control Panel > Programs & Features > Turn Windows Features On or Off > SMB 1.0/CIFS File Sharing Support SMB 1.0/CIFS Server and make sure it is ticked, then Restart your Windows PC.”

I can tell you for sure that the protocols used by LanMan98 and VRPC are entirely different.

Do you have any other RISC OS machine on your LAN? It would be useful to know if it has the same problem connecting via LanMan98.

Whenever I’ve had this problem in the past, it’s almost invariably been caused by a Windows ‘update’ altering shared folder permissions. It seems to do this at random, which may explain why you can connect to one machine but not the other. Might be worth looking in that direction.
Edit: sorry Dave Symes, missed the bit about you already checking Sharing and Permissions earlier. Glad you got it sorted.

“If you get the error: ‘Connection reset by peer’, go to: Control Panel > Programs & Features > Turn Windows Features On or Off > SMB 1.0/CIFS File Sharing Support SMB 1.0/CIFS Server and make sure it is ticked, then Restart your Windows PC.”

Bang, bang bang… That was the LM nail being firmly hit upon its head.

Thank you Doug,
Along with resetting Sharing and permissions which I’d already done, checking as you suggested revealed that SMB 1.0/CIFS Server was unticked, ticking that back on, rebooting and way to go, LM98 now does the business.

I never saw a ‘Connection reset by peer’ error though, only “Connection lost (4)".

Interestingly, also checking the Win 10 notebook where the VRPC RO error did NOT occur I find the SMB 1.0/CIFS Server was still ticked on.

Dave Higton,
Yes, here on the LAN there are other VRPC installs on various computers running Win 7, as well as the Win 10 Notebook, and an ancient RISC PC running RO 6.20

Not one of those had the problem.

So it seems this continual MS interference with the Win 10 updates is to blame again.

So folks, thanks to everyone for the suggestions, and particularly to Doug for passing on Bernard’s tip.

Dave

So it seems this continual MS interference with the Win 10 updates is to blame again.

As I pointed out when this came up on the newsgroups, MS are turning off SMB 1.0 for a reason: the protocol has a security hole which suspected to be the attack vector for one of the recent high-profile malware outbreaks. Nothing “native” has used SMB 1.0 for many years¹, nor has any mainstream “non-native” stuff — so it’s only been left on to support ancient third-party stuff like RISC OS.

If you turn the service back on, make sure that the machine(s) are safely behind a secure, properly configured firewall. In any corporate environment, you’d get very short shrift if you asked for SMB 1.0 to be restored things like file servers.

¹ Was XP the last version of Windows to require it, or is it even older than that?

No doubt good advice Mr F.

Mmmnnn! Or better, perhaps a baby with bathwater solution…

I guess the obvious answer is dump ancient RISC OS completely and just use up-to-date Windows or Linux… RISC OS doesn’t have a working firewall facility… Well if it does I wouldn’t know anything about it.

Obviously the Win computers have their firewalls active, and IIRC the Router has some protection active, but aside from that… Arcane. :-(

I vaguely remember some years ago when old LM98 stopped working, before it was updated, someone suggested a something Fish alternative, I did install it, and made various attempts to configure it… In the end gave up as I couldn’t get it to work.

D.

In any corporate environment, you’d get very short shrift if you asked for SMB 1.0 to be restored things like file servers.

Yup. We’ve had practice at not using responses that involve two words with the second being “off”

Was XP the last version of Windows to require it, or is it even older than that?

In default build. I believe there were add-ons.

Dave: Basically what you really really want to see is the completion of the new IP stack work so that the newer more secure protocols can be used.
Which does raise the question – will the new stack be confined to RO5 and if so does that sound the death knell for other versions on a network.

Which does raise the question – will the new stack be confined to RO5 and if so does that sound the death knell for other versions on a network.

I think the answer here is that older machines should be supported if it is practicable to do so – meaning that if the changes required to support older machines are minor, then okay; but if supporting old suggests mucking up possibilities with RO5, then no…

That said, how much RISC OS software understands or can in any way cope with IPv6? ;-)

Can I reply by asking how much Windows software working at the application layer understands activity at the IP layer? (layer 6/7 vs layer 3)

…will the new stack be confined to RO5 and if so does that sound the death knell for other versions on a network.

If someone could explain (If it can be done) how to get RO 5.23 working on a VRPC-DL install then I’d have a go with it.

I did have a RPCEmu 0.8.15 (Still do) running RO 5.23 and it was networked, but since a while back when I had the first lot of trouble with this machine (Windows not the hardware) and it was all put to rights, I’m not going to do anything to mess with the Windows networking by adding a RPCEmu bridging.

Dave

If someone could explain (If it can be done) how to get RO 5.23 working on a VRPC-DL install then I’d have a go with it.

I’m not aware of anyone having done that.
It’s probably that no one with the aptitude has tried but then if someone goes and spends more than the cost of a Pi to emulate an old item of hardware and run a 26-bit OS they are probably more interested in running old software that doesn’t run on a Pi than doing anything with new features of a 32 bit OS.
Why spend time making the emulator less compatible with the stash of old software?

Dave: Basically what you really really want to see is the completion of the new IP stack work so that the newer more secure protocols can be used.

Which part of modern SMB (or perhaps NFSv4, or SCP or whatever) needs an updated IP stack? I thought it was really a problem in the higher layers?

Which part of modern SMB

I think that would be the change to message signing requiring an improved encryption algorithm.
My memory says MD5 gets ditched.

Anyway, suffice to say that people have noted that the only way to make things work currently is to revert Windows to SMB1 support which obviously reduces the security of the Windows install.

Aside: It just occurred to me: Dave reported this with RO6.20 and LM98 – does that combination not do SMB2? If not then there’s a few problems ahead for users with that setup.

I think that would be the change to message signing requiring an improved encryption algorithm.
My memory says MD5 gets ditched.

Sounds a lot like layer 5. Why would that need a new layer 3/4 implementation?

How would I know, where to look, to find out if RO 6.20 and LM98 do SMB2?

Dave

Well… After some more updates I now find LM98/2 again not playing the game.

All the SMB 1 stuff is ticked on. sharing active, permissions set.

Pah!

D.

Well… After some more updates I now find LM98/2 again not playing the game.

I think you need to look at the logs and see what was updated.
MS (and other suppliers) have been doing lots of security related patching in recent months and this may be one of those biting.

I think you need to look at the logs and see what was updated.

I have no idea what I might be looking for.

Without LM98 I’m stuffed anyway, I’ve just checked all my recent backups of RO stuff by other means (No LM) and every single one is now totally Expleted-up.

It’s enough to get the GM not only rattling the cage (It’s happening) but breaking out.

Sigh! Through gnashing teeth!

D.