Threaded Mode | Linear Mode

Pepsican · 18-03-2024, 16:03

(18-03-2024 15:50)simoncn Wrote:
(14-03-2024 21:21)Pepsican Wrote: I updated the network last week. As MinimServer is a vital app for me, I checked it immediately and there are problems. So, they are there from the start. Also, the entire network was rebooted multiple times during its configuration.

Just double-checking, did this network reboot include powering the Synology off and on?

Also, you could try installing MinimServer on your hard-wired PC to completely eliminate the possibility of an issue with the Synology.

Everything. Anyway, the Synology reboots automatically once a week.

But if I install MinimServer on the PC, how would that help? Kazoo runs on the same device and if I want to check from other devices, it would reintroduce the Access Points into the mix.

simbun · 18-03-2024, 16:16

(18-03-2024 11:42)Pepsican Wrote:
(17-03-2024 22:26)simbun Wrote: I take it Kazoo didn't discover BubbleUPnP server running on the Android phone?

Well...I hadn't paid attention to that. So when I just started Kazoo, it was, to my surprise, there! And within seconds it also picked up MinimServer.

Then I think that takes us full circle back to what I said originally Smile

(12-03-2024 22:56)simbun Wrote: Given the delay, it sounds like the SSDP discovery broadcast isn't getting to MinimServer

The fact that mconnect discovered BubbleUPnP means the AP multicast is working, and now with Kazoo also able to connect to BubbleUPnP means the same is likely of the switch.

Given that disabling the Synology firewall didn't work, and that I know nothing about Synology I'm afraid I can't help more with this.

I'm sure @simoncn will be able to get to the bottom of it.

simoncn · 18-03-2024, 16:34

Thanks for this capture log.

In packets 5696-5700 (213 seconds), MinimServer sends NOTIFY messages for the first time. Kazoo running on the PC receives these messages and connects to MinimServer.

Prior to this in packets 421/440/444 (18 seconds), Kazoo sends some M-SEARCH requests to the multicast address 239.255.255.250 (the multicast address for UPnP discovery). This request is looking for UPnP devices on the network. There are many subsequent similar M-SEARCH requests. MinimServer running on the NAS doesn't respond to any of these but a Linn device at address 192.168.22.20 does respond in packet 422. This means that your network is able to forward M-SEARCH requests to the Linn device but is not able to forward M-SEARCH requests to the NAS.

Is there a difference in how the Linn device and the NAS are connected to the network?

Pepsican · 18-03-2024, 16:49

(18-03-2024 16:16)simbun Wrote:
(18-03-2024 11:42)Pepsican Wrote:
(17-03-2024 22:26)simbun Wrote: I take it Kazoo didn't discover BubbleUPnP server running on the Android phone?

Well...I hadn't paid attention to that. So when I just started Kazoo, it was, to my surprise, there! And within seconds it also picked up MinimServer.

Then I think that takes us full circle back to what I said originally

(12-03-2024 22:56)simbun Wrote: Given the delay, it sounds like the SSDP discovery broadcast isn't getting to MinimServer

The fact that mconnect discovered BubbleUPnP means the AP multicast is working, and now with Kazoo also able to connect to BubbleUPnP means the same is likely of the switch.

Given that disabling the Synology firewall didn't work, and that I know nothing about Synology I'm afraid I can't help more with this.

I'm sure @simoncn will be able to get to the bottom of it.

Kazoo found both. But only after a while. It seems it only detects things on the basis of the NOTIFY, not on the basis of the M-SEARCH.

Pepsican · (This post was last modified: 18-03-2024 17:25 by Pepsican.)

(18-03-2024 16:34)simoncn Wrote: Thanks for this capture log.

In packets 5696-5700 (213 seconds), MinimServer sends NOTIFY messages for the first time. Kazoo running on the PC receives these messages and connects to MinimServer.

Prior to this in packets 421/440/444 (18 seconds), Kazoo sends some M-SEARCH requests to the multicast address 239.255.255.250 (the multicast address for UPnP discovery). This request is looking for UPnP devices on the network. There are many subsequent similar M-SEARCH requests. MinimServer running on the NAS doesn't respond to any of these but a Linn device at address 192.168.22.20 does respond in packet 422. This means that your network is able to forward M-SEARCH requests to the Linn device but is not able to forward M-SEARCH requests to the NAS.

Is there a difference in how the Linn device and the NAS are connected to the network?

That Linn device is my SOtM SMS-200. Both are connected by cable to the Switch. The SMS-200 is connected on the AP Gigabit port (which is pass-through) and the NAS is connected via cable directly to the switch. As we have now eliminated the switch as being the problem, we should focus on the NAS then?

simoncn · 18-03-2024, 18:14

Can you swap the connections to the SMS-200 and the NAS to make sure it is not related to how these devices are connected?

Also, I am still not sure whether you have powered the NAS off and on. Rebooting might not be equivalent to doing this.

Pepsican · (This post was last modified: 19-03-2024 00:53 by Pepsican.)

Oh my. Did I have an adventure this evening. Your question to swap connections made me discover that I had actually not yet connected my NAS to the switch (it was part of the plan for the new network so in my head this had happened). It was connected to the Arris Modem, which in turn is connected to the switch. Anyway, as soon as I connected the NAS to the switch, MinimServer was immediately discovered by Kazoo, mConnect and Bubble. So, it was not the switch or the NAS. It was the Arris.

I then tried to figure out why the Arris was not passing on the M-SEARCH and while I was searching I found some other things wrong with the modem. Its gigabit ports were working at 100Mb only. Long story short, I reset the damn thing, redid the configuration of it, fixed the port speed issue, found a bug for using NTP (if you want a different NTP server than the one set by the ISP/Arris, the device will not reboot and you have to reset it again), and never found the reason why the Arris will not pass on the M-SEARCH request (I tried port forwarding 1900 to the NAS, did not work, checked all settings but could not find anything obvious).

I give up, it just solidifies my believe that excluding the ISP provided device as much as possible from your network is a good move.

So in conclusion, the problem is solved by connecting the NAS directly to the switch (yay TP-Link!), but no idea why the Arris is not doing its job properly. And quite frankly, I must have had this issue before I think, but I either didn't care enough about it or it was not as bad as it has been in the past week.

Pepsican · 19-03-2024, 00:51

(18-03-2024 18:14)simoncn Wrote: Also, I am still not sure whether you have powered the NAS off and on. Rebooting might not be equivalent to doing this.

Did it. Full shutdown, no efffect.

(18-03-2024 18:14)simoncn Wrote: Can you swap the connections to the SMS-200 and the NAS to make sure it is not related to how these devices are connected?

Yesss....about that....turns out my NAS was not connected to my switch but to my Arris. Once I reconnected the NAS to the switch everything worked! See previous reply for the long version.

simoncn · 19-03-2024, 13:11

Glad to hear you found the cause of the problem. Happy listening!

Pepsican · (This post was last modified: 20-03-2024 14:52 by Pepsican.)

@simoncn @simbun
Thank you both for your support and especially your perseverance with the issue. Makes paying the license fee worth every cent!

So people, if you still have doubts, don't. This is by all means and in every way a superior product that is worth the money. Install the software, try it out, ask your questions and you will then happily pay the license because you actually get good value in return.

And you can quote me on that.