Synology + NDS / NAS disappears from app

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!

Add Reply

×
×
×
×