Minimwatch doesn't connect to minimserver on qnap

[RSJ]

The solution was to point MinimWatch to the 'correct' subnet - so, thank you.

I am not sure why, after many years of using MinimWatch and MinimServer, this has suddenly become an issue.

[gotburger]

I have a similar problem and I have found the operation that causes the problem. But it shouldn't?

Set-up:
- MinimServer 2.2 is the QNAP app on a TS-832X; Server ohnet.subnet=192.168.50.0
- QNAP interfaces *before* the "operation" are both on 192.168.50.0/24
- Minimwatch on Windows 10 with ohnet.subnet=192.168.50.0 (host has one interface and is on 192.168.50.0/24

So far everything works fine.

The operation: Move one of the QNAP interfaces to subnet 192.168.20.0/24

Now:
- The MinimServer does NOT show up in Linn Kazoo on the 192.168.50.0/24 subnet
- The MinimServer status page is accessible over BOTH 192.168.20.0/24 and 192.168.50.0/24

It seems like the (server) ohnet.subnet=192.168.50.0 instruction is ignored.
Haven't found out whether 192.168.20.0/24 is served instead. It is not expected to be so since the ohnet.subnet is set properly as far as I can understand. (Still wondering why the network mask is not required input - hard to understand the interface selection procedure.)

Any idea as to why the server becomes unavailable on the ohnet.subnet specified?

[simoncn]

(25-04-2023 14:33)gotburger Wrote:  The operation: Move one of the QNAP interfaces to subnet 192.168.20.0/24
Now:
- The MinimServer does NOT show up in Linn Kazoo on the 192.168.50.0/24 subnet

When you set the MinimServer ohnet.subnet property to 192.168.50.0, the ohNet stack (used by MinimServer for UPnP communications) makes an arbitrary choice of a single adapter on the 192.168.50.0 subnet. If it has chosen the adapter that you later change from 192.168.50.0/24 to 192.168.20.0/24, control points using the 192.168.50.0/24 subnet will no longer be able to see MinimServer.

The solution is to remove the ohnet.subnet setting for MinimServer. This enables MinimServer to send UPnP advertisements on all available subnets. Alternatively, you can leave the ohnet.subnet setting as 192.168.50.0 and stop and restart MinimServer using QTS App Center after changing the adapter subnet to 192.168.20.0/24. This will cause MinimServer to select an adapter that is still on the 192.168.50.0 subnet.

Quote:- The MinimServer status page is accessible over BOTH 192.168.20.0/24 and 192.168.50.0/24

The MinimServer status page is accessed using HTTP, not UPnP. The ohnet.subnet property controls UPnP access to the server, not HTTP access.

Quote:Haven't found out whether 192.168.20.0/24 is served instead.

This should not happen if ohnet.subnet is set to 192.168.50.0.

Quote:(Still wondering why the network mask is not required input - hard to understand the interface selection procedure.)

For each adapter, the IP address is combined with the network mask and compared with the value of ohnet.subnet if set. If multiple adapters match, one of these is chosen arbitrarily.

[gotburger]

This seems to work OK:
- disable the extra adapter (the one desired to have an 192.168.50.0/24 address)
- the ohnet.subnet setting removed

The same with ohnet.subnet set to 192.168.50.0 does not work (at least is not stable)

Having a second adapter active on 192.168.20.0/24 and ohnet.subnet set to 192.168.50.0 shows similar behavior.

Seems like any adapter needs to be on same subnet to operate properly...

Installed packages:
[*minimserver-2.1.2]
minimserver-2.2
minimserver-update-240


List of modules:
[* jminim-2.0.145.jar]
[jminim-2.2.100.jar]
jminim-2.2.105.jar
* minimlaunch$-2.0.103.jar
[* minimreader-2.0.115.jar]
minimreader-2.0.117.jar
* minimscript$-2.0.110.jar
[* minimserver-2.0.174.jar]
[minimserver-2.2.100.jar]
minimserver-2.2.109.jar
[* minimui-2.0.130.jar]
minimui-2.2.100.jar
[* ohnet(linux-arm64)-1.32.4280.zip]
ohnet(linux-arm64)-1.33.4785.zip

[simoncn]

I am not clear on what you would like to achieve. Do you want MinimServer to be accessible from both the 192.168.0.50 and 192.168.0.20 subnets at the same time?

[gotburger]

(26-04-2023 13:49)simoncn Wrote:  I am not clear on what you would like to achieve. Do you want MinimServer to be accessible from both the 192.168.0.50 and 192.168.0.20 subnets at the same time?

As a string point I have the NAS serving 192.168.50.0/24 (I have reverted to that configuration now; ohnet.subnet left blank).

I'd like to have another adapter to subnet 192.168.20.0/24 for other purposes. MinimServer preferrably not serving 192.168.20.0/24, but OK if it does.

All attempts having another adapter serving 192.168.20.0/24 for other purposes have rendered MinimServer to cease serving the 192.168.50.0/24.
Leaving the ohnet.subnet blank or set it equal to 192.168.50.0 makes no difference.
It isn't the expected behaviour as far as I understand.

I can refrain from connecting the NAS to the extra subnet for now and later consider a transition to a containerized solution.

[simoncn]

I am away from home for a couple of days. When I return, I will set up a similar configuration to see what MinimServer is doing.

[simoncn]

My test results are as follows. I am using a main subnet 192.168.0.0 on adapter 1 and an additional test subnet 192.168.1.0 on adapter 2.

Scenario A:
1) Enable both adapters. With ohnet.subnet unset, start MinimServer from App Center.
2) MinimServer starts and is visible and functional on subnet 192.168.0.0. It is probably also visible on 192.168.1.0 but I can't easily confirm this with my test setup.
3) Set ohnet.subnet to 192.168.0.0.
4) MinimServer remains visible and functional on subnet 192.168.0.0. It is probably not visible on 192.168.1.0 but I can't easily confirm this with my test setup.

Scenario B:
1) Enable both adapters. With ohnet.subnet set to 192.168.0.0, start MinimServer from App Center.
2) MinimServer starts and is visible and functional on subnet 192.168.0.0. It is probably not visible on 192.168.1.0 but I can't easily confirm this with my test setup.

Scenario C:
1) Enable both adapters. With ohnet.subnet set to 192.168.0.0, start MinimServer from App Center.
2) MinimServer starts and is visible and functional on subnet 192.168.0.0. It is probably not visible on 192.168.1.0 but I can't easily confirm this with my test setup.
3) Remove the ohnet.subnet setting.
4) MinimServer disappears from subnet 192.168.0.0.

Scenario C is not as expected and appears to be a problem with either MinimServer or ohNet. You should avoid doing this at present and should instead use either scenario A or B to run MinimServer on one adapter/subnet while leaving the second adapter/subnet free for other purposes.

[simoncn]

I have found the problem in MinimServer that is causing unexpected behaviour with scenario C. It will be fixed in the next MinimServer update. For now, the workaround is to use either scenario A or scenario B.

Thanks very much for helping me find this problem.

[gotburger]

Thanks,
For the time being I knep bott adapters on the same subnet and keep the subnet setting for ohnet.subnet. This seems to work fine for now. Good that there is solution underway!