Synology + NDS / NAS disappears from app

Why should I have to care what protocols a product uses? 

Whether you like it or not, you are saying that the reason that the Naim app doesn't work is because of something that I haven't done.

It seems that Naim are releasing more and more network products. I suspect that more than 50% of the products that they sell are network products.

Are my Michelin tyres only going to work on certain road surfaces?

I don't care how things work as long as they do.

Anyway, at some point I will investigate my network settings to see if there is anything that can be changed to please the Naim app.

No Naim app diagnosis guide?

"Why should I have to care what protocols a product uses? "
Perhaps because if you use incompatible products they won't work together.  For instance: the Naim app uses the standard DLNA discovery protocol.  Do you know how your wireless router handles this?  Does it "optimise" the messages or does it transmit them unaltered as per the standard?

Unless you can answer this then it's not appropriate to blame Naim if your router takes a perfectly well formed message from (or to) the Naim app and either blocks it or passes it on after altering it.  This is exactly what my router was doing until I configured it to not interfere with the operation of DLNA.

"Are my Michelin tyres only going to work on certain road surfaces?"
Are the same tyres going to work on every make and model of car?

"I don't care how things work as long as they do."
Neither does the proverbial ostrich!  Unless you know how things work, when they don't, you won't know why; and then it's rather inappropriate to assign blame any specific person (or team or organisation) when you don't know the reason for the failure (and hence can't know who caused it).

No Naim app diagnosis guide?
Do your car tyres come with a diagnostic guide in case your car is skidding?  (And that's a much more critical failure!)

Investigating the network settings is a very good idea.  I genuinely wish you all the best of luck hunting down the cause of the problem.
It isn't easy: I know a bit about networks, but I was still stumped until S-i-S gave me some very wise advice on places to look for the problem.

All the Best
E

Hello all!!! I HAVE HAD A BREAKTHROUGH FINALLY!!

paying more attention to Mike-B, i tried to investigate why there were 2 IP addresses listed on my router. Firstly, I confirmed that DHCP is on. Did the reboots and all as suggested. Yet, 2 same IP addresses persisted - one on static, the other on DHCP. While my router listed names for all devices - one of these was listed incorrectly. The NAS was listed as a Sonos device, and the other one is actually a sonos one... Turns out that Sonos needs a static IP address to run its wireless speaker setup. The router seems to have picked the same IP address to assign it to the NAS. 

Being the tech wizard that i am (not), i decided enough was enough and so i re-installed DSM. This ended up giving the NAS a new (and different IP address). For the first 2-3 hours after that, the NAS showed up, but browsing remained super slow - folders took forever to show, the app hanged a few times, instead of showing the folder, it went back to the home screen. Could this have been because of the indexing? Not sure - my disk station suggested indexing was completed (around 500 albums). 

Anyway, a couple of hours more have since passed, and i am pleased to report that stuff is back on and singing reasonably well... thanks to all of you, i have lived to fight another day!!! :-)

You suggest that (as it's required by their system) you are still using a static IP address(es) for the Sonos.  If so may I suggest you look at the configuration of the DHCP server in your router.  In DHCP area of settings you'll find a range setting (something like 192.168.1.1 to 192.168.1.255).

Can I suggest changing that range to be 192.168.1.1 to 192.168.1.207.  Then assign the IP address(es) for the Sonos in the range 192.168.1.208 to 192.168.1.255.  This will prevent IP address clashes in the future.

Hi [@mention:36201736971392588]: i don't actually "Select" anything for Sonos. I plug it in and it manages to get a static IP address (for the sonos boost, which is wired. The speakers also reflect static IP addresses as well but as i said before, they don't run on my regular wifi - the Boost takes care of the sonos network)..

Further update [@mention:36201736971392588]: sonos now shows up as DHCP. Not sure what is going on... in the meantime, Naim App + NAS seems okay for now...

If you plug in the Boost and it automatically gets an IP address, it's almost certainly using DHCP (the other way to do that involves opening a back door around your network security and the router should be configured to reject that).

The boost then creates another overlapping Wireless Access Point connected to your main router by the Boost, distinguished from the first by using a separate SSID.  I don't know if it's an entirely separate network (i.e. connected to your main network via it's own router in the Boost, with it's own DHCP server etc.) or just a bridge and separate WAP (i.e. just extending your existing network via a separate SSID), but I suspect it's the latter.

P.S. your post arrived while I was writing mine!

Bananahead posted:

Why should I have to care what protocols a product uses? 

In just the same way you should care whether your car has a petrol, diesel or gas engine... get the wrong fuel in and it won't work, they are incompatible... a product using a shared resource like a network is exactly the same.

Simon-in-Suffolk posted:

Bananahead posted:

Why should I have to care what protocols a product uses? 

In just the same way you should care whether your car has a petrol, diesel or gas engine... get the wrong fuel in and it won't work, they are incompatible... a product using a shared resource like a network is exactly the same.

It could be a genuine Diesel engine and run on coal dust!  

(P.S.  The oil fuelled engine with glow plug ignited is actually a Stuart engine as invented by Ackroyd Stuart of Milton Keynes, rather than a Diesel engine as invented by Rudolph Diesel of Berlin, which used compression ignition.  That notwithstanding, the point remains valid.
You have a bugbear about over simplification; well this is one of mine! )

Chickabaddyshortshanks posted:

...............   re-installed DSM. This ended up giving the NAS a new (and different IP address). For the first 2-3 hours after that, the NAS showed up, but browsing remained super slow - folders took forever to show, the app hanged a few times, instead of showing the folder, it went back to the home screen. Could this have been because of the indexing? Not sure - my disk station suggested indexing was completed (around 500 albums). 

Anyway, a couple of hours more have since passed, and i am pleased to report that stuff is back on and singing reasonably well... thanks to all of you, i have lived to fight another day!!! :-)

Yes the super slow is because its indexing.     

Pleased to read its all OK now.    

Ah, I misread this the first time...

After reinstalling DSM it not only does a full re-indexing of the media files by the Media Server (specific for DLNA access), it also optimises the loading of DSM itself and re-indexes ALL the files for general file access and quicker searching via DSM.  All these processes take time, typically a few hours.  The re-indexing of the media files alone (i.e. by the Media Server) will only take about 1/4 to 1/3 of that time.

Thanks so much everyone!! Real character-building stuff, these NAS issues, aren't they?? :-)

Simon-in-Suffolk posted:

Bananahead posted:

Why should I have to care what protocols a product uses? 

In just the same way you should care whether your car has a petrol, diesel or gas engine... get the wrong fuel in and it won't work, they are incompatible... a product using a shared resource like a network is exactly the same.

Yeah, but my point is that I think that it is the car manufacturer that has the responsibility to tell you what sort of fuel to put in. 

Huge posted:

Thanks Mike, give me the easy ones won't you!  

@Chickabaddyshortshanks, you have followed Mike's advice, haven't you?  It's a basic point and very sensible advice: Until you fix that your network will be in all kinds of chaos.

........  sorry about that Huge,  I could see it was getting a bit intense,  & as am overseas at mo & with dodgy comms plus other things to do,  I felt I must refocus the thread a bit over the NDS with two IP addresses associated with one MAC address.  

Anyhow it seems OP has it sorted.

Hi Mike, no probs, actually you I and S-i-S often make quite a good tag team!  We seem to agree on quite a lot of techy type things.

( Great minds think alike, but fools seldom differ!   ) 

Huge actually under the covers Sonos does indeed use UPnP, just it's own flavour of it as opposed to the DLNA profile and does use SSDP discovery to announce and find its clients just like UPnP/ DLNA as used by Naim and other applications.

The good thing with Sonos is that it can use its own network if it's host network is problematic.

I am glad the OP has it sorted.. but again it appears the issues were possibly because IP address assignment at some point wasn't left as default to use  DHCP. There is really no reason on the modern consumer home networks of not using DHCP... it's there for a reason to make your home networks work. Please use it and don't use manually assigned  'statics'. I am sure so many problems will disappear if all left to default and one is not tempted to fiddle.

Most half descent home routers also  use a DNS cache linked with the DHCP so you can talk to devices such as NASs by local name and you don't need fixed IP addresses. This is how these networks have been designed to work, and makes these things straightforward.

For example my UPnP media servers network mount my music NAS by calling it by its name ' musicNAS' ... my router resolves that to whatever address it has been assigned... this way everything can be controlled by the router, IP addresses can be used as appropriate by the router DHCP, and everything just works 

Hi Simon,

When I said it doesn't use standard protocols, I obviously din't mean that it doesn't use ANY standard protocols (in fact I stated that I believed it was using DHCP).  I was trying to get across that just because the Sonos was working, that doesn't prove that the network is operating perfectly in every way (and therefore if the Naim App was failing, the Naim App MUST be at fault).  I was specifically refering to the DLNA protocols but didn't want to get into detailed arguments as to why networks should specifically support one set of protocols built on UPnP as opposed to another set of protocols also built on UPnP  And why the designer of a router might feel they're entitled to use IGMP snooping to 'optimise' DLNA messages (and mess them up!) whereas it doesn't 'optimise' Sonos messages and leaves them untouched.  The explanations could get very convoluted and stray into areas of product development and marketing philosophy about which I could only offer conjecture!

The question I asked was, in Boost mode, does Sonos extend the network (with a WAP using a different SSID) linked via a bridge, or create a new network (also using a WAP with a different SSID) linked via a router.  This is something to which I don't have the answer.

P.S. I also recommended sticking to DHCP.  I use one static, but only because the DNS in my router has timing issues (and that address range is specifically excluded from DHCP control) and I only use it for the one device whose connectivity is affected - all the others are DHCP.

Huge, you might be mixing a few points or I might not be understanding you correctly.. let me try and help.. but I might fail..

The discovery methods used by Sonos, DLNA etc are the same, they use a protocol called SSDP - Simple Service Discovery Protocol. It uses multicast addressed datagrams as opposed to unicast addressed  packets. These multicast datgrams are connectionless... However these don't use broadcast frames, as on a larger home network that can be inefficient and cause unnecessary loading on wifi and clients. They multicast datagrams, and these use groups. Something called IGMP manages these groups.

Effectively a device says 'hey I want to be discovered by this group' and then one of application main hosts of the group says repeatedly  ' confirm to me you want to be still discovered in this group and tell me what you can do ' .

This goes on for some network printers, home automation, audio DLNA, some video IPTV devices, Sonos etc etc.

So after a while there can be a few groups active on your home network .. with one being used for SSDP.

Now although multicast groups are used, some / most ? Home networks don't use a multicast router supporting local groups.. so the IGMP group management becomes a system of co opting and cooperation relying on clients to advertise and respond all with their own timers and rules... this is where things can go awry in my opinion.

Really what you need is a multicast router to manage the groups and police them and keep memberships accurate... an alternate if your router doesn't do this  is to run an IGMP querier which does the same policing job... this is what I do... and the vagaries of group copying and cooperation appear eliminated... I never have room not found for example on my Naim amp... and my network printers always appear.... Before I used a querier I occasionally got room not found or media servers disappearing.. not a big issue as it usually cleared itself but an irritant ... and my network printer sometimes needed to be power cycled before it appeared to devices ...

Now the bit about IGMP snooping... I doubt any router manufacturer is mangling specificly with DLNA SSDP messages... however with multicast group data you need to control what goes where within reason, you don't want to load a wifi network with a particular group's data if no client on the wifi is a member of that group.. and some groups could carry a lot of data... (SSDP doesn't however) .. and so this is where the IGMP snooping comes in... it prunes the data for non group members saving precious bandwidth, especially on wifi.

The issue can be however when you have a loose system of coopting and cooperation and even with a querier with some routers, that the router doesn't correctly iinterprete the IGMP ( and there are a few version) and so gets confused with memberships and pruning... Now this is why the 'fix' is to disable IGMP snooping in such scenarios... you can get away with this with most SSDP scenarios, but could cause massive performance issues on a wifi network in other setups... it all depends what and how is using your network.

Interestingly the Cisco 2960 switches have IGMP snooping enabled by default ( as you would expect for a quality network component) ... I am not aware of any issues here in using these devices with Naim... but in the  limit this is down to interoperability with the group clients coopting and the network components ... especially the wifi routers. BTW the little Netgear switches just don't have the process horsepower to deal with this, so they assume all groups are shared with everyone.

Simon

Simon-in-Suffolk posted:

I am glad the OP has it sorted.. but again it appears the issues were possibly because IP address assignment at some point wasn't left as default to use  DHCP. There is really no reason on the modern consumer home networks of not using DHCP....

Simon, are you talking about fixing IP addressed instead of using your router's DHCP server, as opposed to just using the router to allocate a fixed address to the NAS (or whatever)? I have occasionally done the latter and found that it has made NAS/Server discovery a little faster and more reliable. 

Indeed.. I am talking about it not really being sensible not to use DHCP for most with home networks. Yes you can bind fixed addresses to clients in most DHCP setups, if you really need to do this then this is fine... as the address is still assigned by DHCP...however I would be cautious about referring to a specific address in an application for most home applications, it's far better to refer to its host or client Name and have the local DNS resolve to the current IP address assigned by your DHCP server.

Mike-B posted:

Chickabaddyshortshanks posted:

 Before I started tinkering with my router settings, the NDS was listed as a "static" IP address. My NAS showed twice in the client list; same IP address but different MAC addresses. One of these was "Static" and the other was "DHCP". I over-rode the "DHCP" one to be a manual IP. As you have suggested, I have just deleted the manual setting, and now everything shows up as DHCP (except for the duplicate NAS one, with static). 

Lots of clues here;  NDS listed as static IP,  factory default is DHCP.  NAS with two MAC addresses !!! thats a new one on me,  I think you mean two IP addresses,  "static" & "DHCP".  This has all the signs of the wireless hub modem being confused with incorrect inputs & trying to associate two IP's to the same MAC.   I really would change everything to DHCP,  after this everything will need a reboot,  then after the first reboot,  power it all off again & leave the wireless hub off for at least 10 minutes before restarting it first ,  then after the hub has completed its start sequence,  then reboot each other device, one at a time, afterwards.

Hi,

One thing that comes to mind is if your NAS has multiple Ethernet ports then have you connected more than one of them to your network switch? Unless you are configuring VLANs or you have your network set up for teaming of network links for bandwidth aggregation or failover (all highly unlikely in a normal domestic install unless you're a complete geek) then this can certainly cause issues.

Similarly - if you have multiple Ethernet ports on the NAS then make sure that the configuration for all the ports is set to DHCP - not just the port that you are using (so that if you do use a different port in the future you don't wonder why it's not visible on your network if it's still set to a static address on that port).

When restarting your network take everything on the network down (don't forget TVs and set top boxes etc.) and then power down your router, leave it off for ten minutes and then power it up again, leave the router for 10 minutes to fully power up and stabilize then bring up all the devices on your network one at a time.

Cheers

Phil

Simon, I think the manufacturer's of home routers just don't take care when writing the UIs (or possibly get confused themselves).

In the case of my router, enabling the UPnP setting on the router specifically allows devices on the network to use UPnP to configure the router, it doesn't affect UPnP messages.  Enabling DLNA on the router opens the ports for DLNA (rather than doing it manually).

However it still makes a complete mess of trying to control multicast.  Unless I tun off IGMP snooping, SSDP through the router is about as usable as a squashed beetle; alter turning it off everything multicast that I've actually investigated ends up everywhere; so in practice it now seems to effectively treat multicast as broadcast.  Multicast video streams hit every single box on my wired network, so for that looks as though the router's not really distinguishing and it's definitely treating multicast as broadcast (I've not checked if they also get transmitted over the wireless link).  So now IGMP doesn't seem to do anything - inefficient this may be, but at least it works.  With SSDP, this may be because all the devices I have do use the same SSDP group(s), so they should all get it - but I haven't the time or inclination to trace everything (or to bother tracing other multicast).  

The DNS timing issues are nothing to do with that, they relate to the very short DNS response window that Windows allows under some circumstances (particularly sometimes when waking from hybrid sleep and re-establishing connections)  This is a completely different reason for using a static IP - noting at all to do with the Naim system or any discovery or streaming issues.

Huge, yes SSDP uses a single group IP multicast address of 239.255.255.250.. so all apps using SSDP will use this group. Differing applications sharing the use of SSDP will need distinguish between them selves based on the clients meta data details whether they are relevant or not.

You can ping 239.255.255.250 from a client and you should see all group members return a response using their IP unicast address to the ping... it's quite a good basic technique for diagnosing issues.. if there is an issue with inappropriate pruning throug bad IGMP snooping then you probably won't see a ping response back from a client that should otherwise be responding.

Hi Simon,

Just tried that and the results are inconsistent dependant on the client location used to do the ping.  In the worst case the ping times out without any response at all!

I'm going to try connecting a laptop to various point on the network and see what comes back in each place...  could be interesting.  Currently I'm amazed that the Naim system and Naim app work as well as they do with such a crap router in the system!  Much respect to Naim for actually making it so tolerant!