LanManFS: Bad Parameters

I don’t normally use LanMan, preferring LanMan98. But today I tried using LanManFS, only to get “Bad parameters” from every attempt to mount a share.

I also have an Obey file from very nearly 2 years ago that attempts to mount three shares; it clearly worked then. The parameters for the shares (server name, share (path), user and password) are still all correct. What can have changed?

Infuriatingly, “Bad parameters” gives me no clue which parameter(s) it doesn’t like, much less how to correct it/them.

Platform is a RasPi 3B+, OS is 5.29 (25-Oct-20), LanManFS is 2.66 (31 Aug 2020). I’ve also tried Colin’s version that should show hidden file names; same result (not surprising as it seems to come from the same source version).

I should add that I get the same results, whether I supply 3 or 5 parameters to the LanMan:LMConnect or into Omni’s GUI.

I’ve tried searching in the RISC OS sources for “Bad parameters” which takes me to message E01. I can’t see where E01 is referenced in the sources, though.

I tried using LanManFS, only to get “Bad parameters” from every attempt to mount a share. Infuriatingly, “Bad parameters” gives me no clue which parameter(s) it doesn’t like, much less how to correct it/them.

Almost certainly it’s nothing to do with what you typed into OmniClient (that tends to give more specific errors like ‘Server not found’ or ‘Access denied’). On the occasions I’ve had ‘Bad parameters’ it’s because the contents of Inet$EtherType were nonsense, or that its value wasn’t set at the time LanManFS started, therefore it was empty and a bad parameter. If Inet$EtherType looks reasonable then *RMReinit LanManFS and try again.

I can’t see where E01 is referenced in the sources, though.

Most modules generate the token names at runtime from the error number so you’re unlikely to find E01, it’d be “E%0” or “E%d” with 1 substituted in.

On the occasions I’ve had ‘Bad parameters’ it’s because the contents of Inet$EtherType were nonsense, or that its value wasn’t set at the time LanManFS started, therefore it was empty and a bad parameter.

Perhaps LanManFS should check the Inet$EtherType value, at start and flag a “faulty” zero value?
OK, it doesn’t cover the contents being total nonsense but it does cover one failure mode.
Then again it’s obviously checking at use time and bringing up a “bad parameters” message so whatever that check is could be done at start and flag the problem?

Thanks, Sprow. I looked at Inet$EtherType today and it was correctly set as ej0, and indeed the mounts all mounted. Goodness knows why it was faulty yesterday. I did start several versions of LanManFS yesterday, so I have to assume that Inet$EtherType must have been wrong all the time. A reboot presumably would have fixed the fault and left me none the wiser. I had, of course, been using the LAN before trying LanManFS, and it was fully functional.

Naive old me can’t help wondering why on earth LanManFS wants to know Inet$EtherType. Just get on and use whatever’s there, I’d have thought.

A reboot presumably would have fixed the fault and left me none the wiser.

However, you did something more than just a quick Microsoft style “fix” and everyone now knows to check for evidence of this bug.

Honestly, LanManFS/Omni’s error reporting leaves a lot to be desired. I got the “bad parameters” error earlier when I typing quickly and didn’t fill in the share folder name (ie. I filled in the RISC OS name, and the server name, but not the share itself). I’ve seen the same error come out for various other error states and failed connections. It basically seems to happen if the LMconnect command fails immediately, I think. However, I’ve never narrowed it down.