Router choice

So you adjusted your network settings to be able to get the Naim setup to work? Well good luck for the future, you can only hope that Naim developers do not touch that part of the code ever again. 

You simply do not understand that this is the other way round than it should. If it works for you, fine. Apparently you accept a lot from developers. Again, fine.  

From a development standpoint, it's plain stupidity off course. If you do not develop your products to work on the widest range of consumer network products with their standard settings enabled, well, you will not be in business very long. 

But enough of this, maybe you should explain OP how he should configure his router. 

Re T+A guys,nothing to do with DLNA protocol. They fiddled with layer 3 or 4 protocol settings. You would have accepted it, the rest of the world not. Including me, sold the stuff, never looked back. 

Also, you are focussing on DLNA issues, but who says that the issue in  that space? As you said, there are no specific settings in apps. The only thing we know is that everything works, bar the Naim stuff. 

Sorry that I have still not given you an answer, Huge.

My old Dell Windows 7 Desktop also has a wired connection to the router and is nearly always switched on when I use the Naim app.

I thought I would experiment by leaving it off for a few days in case it was interfering in some way.  My dealer said yesterday that this is not possible but the app has not failed since the Dell has been off which is completely unprecedented.  Usually it fails several times a day.

Either there is a coincidence or the Dell is the rogue spanner in the works.

i shall experiment more and let you know, assuming that you are still interested and replies are still possible.

Switches were already installed by the dealer.  There is an upgraded router which I can get from Sky for free so I will get that anyway although I appreciate that the consensus seems to be that it is probably not the router and, if it is, I shall need a much better one.

I am touched by all the kind and thoughtful comments by members, some of which I don't understand.  It seems to me that Naim expect an awful lot of electronic expertise from customers using their streaming products.

We live and learn, if we keep trying.

coiledmagnet posted:

I am touched by all the kind and thoughtful comments by members, some of which I don't understand.  It seems to me that Naim expect an awful lot of electronic expertise from customers using their streaming products.

Not quite - Naim expect their dealers to use some of their very large margins to sort out these issues, but too many dealers are lazy and or incompetent so the forum picks up the pieces. My nearest dealer is great at servicing my LP12 but I've known gerbils that know more about networks.

Streamz posted:

So you adjusted your network settings to be able to get the Naim setup to work? Well good luck for the future, you can only hope that Naim developers do not touch that part of the code ever again. 

<snip>

Yes I adjusted my router settings as the default setting were not DLNA compliant.  The new settings are DLNA compliant.  I did this to make DLNA setups to work - the Naim setup is DLNA compliant - hence it now works.

You need to face up to the fact that there are a lot of ISP supplied routers out there that aren't DLNA compliant straight out of the box, with their default settings in place.  Why do you keep denying this and insisting that all routers ARE fully DLNA compliant?

Provided Naim keep to the DLNA standards my system will now continue to work no matter how Naim change the code (assuming they keep to the DLNA protocol standards) as the rest of my system is now DLNA compliant

Streamz posted:

<snip>

You simply do not understand that this is the other way round than it should. If it works for you, fine. Apparently you accept a lot from developers. Again, fine.  

<snip>

This isn't the wrong way round.  Naim kept to the relevant standard (DLNA), the router manufacturer did not.  I adjusted the router so that it then DID comply with the standard.  Why would I want Naim to adjust their system to fit in with my non-standard router?  If they did that it may not then work with other routers that are standards compliant.

I fixed the cause of problem, not just the symptom.  Now ALL my other other DLNA compliant devices ALL work properly and ALL interact as they should.

Streamz posted:

<snip>

From a development standpoint, it's plain stupidity off course. If you do not develop your products to work on the widest range of consumer network products with their standard settings enabled, well, you will not be in business very long. 

<snip>

Surely the best way for a smaller company to stay in business is to comply with the relevant standards.  It's literally impossible for Naim to know what protocols the manufacturers of network products will choose to enable by default, and which they will block - some protocols are always going to be blocked as they represent security risks.  Best to keep to the standards rather than assume that just any old non-standard protocol will work.

Streamz posted:

<snip>

But enough of this, maybe you should explain OP how he should configure his router. 

<snip>

Now you're just being facetious.  I don't have the manual for his router nor do I have access to his network to run test tools on it.

Streamz posted:

<snip>

Re T+A guys,nothing to do with DLNA protocol. They fiddled with layer 3 or 4 protocol settings. You would have accepted it, the rest of the world not. Including me, sold the stuff, never looked back.

<snip>

What part of "This may have been the case with the T&A streamer you had", was it the 'may'?  I didn't assert that this was the case (especially as you didn't explain that the T&A were trying to operate the network outside the accepted TCP/IP network operational protocols [OSI network model layers 4 & 3 as you have just specified], hence would have needed to provide low level drivers for any OS that is to be supported).

FYI DLNA is constructed at OSI layer 6 & 7, usually implemented by aggregating (i.e. building on top of) OS services providing the lower layer functions (although for some Operating systems with limited network support, there may need to be additional code written at layer 5).

Streamz posted:

<snip>

Also, you are focussing on DLNA issues, but who says that the issue in  that space? As you said, there are no specific settings in apps. The only thing we know is that everything works, bar the Naim stuff.

Because everything works apart from the DLNA stuff!

I had similar issues with the router my ISP supolied (a Technicolor that must have cost them 50p to produce) and when it died I replaced it with a Netgear Nighthawk and all streaming issues with my Naim  Mu-So Qb, situated in another room, disappeared overnight.

Huge, have it your way. If your argument is that many routers are not compliant with DLNA standards, and that users should be able to change their settings to get Naim stuff to work, well, eh, never mind. Done with argueing.

Yes, my comment re: you helping his router settings was a bit childish. But at the same time, you don't know which exact router he has, still you're pointing towards DLNA incompatibility of his router. Strange. Or at least premature. The internet would be flooded with comments that the basic Sky router is not able to do DLNA with all streaming solutions out there. 

Anyway, done. 

Sorry for the delay.

The Dell desktop has been switched off for 3 days during which time the Naim app has functioned perfectly on either of my iPads.

I switched it back on again with the Naim app open on one iPad and, within a minute, the first app outage occurred briefly and has continued to function poorly, not recognising rooms some of the time and not allowing me to operate certain functions although it has not failed completely yet, which it usually does after a while.

I checked speeds again in case the Dell was somehow using up all that was available although it wasn't doing anything much at the time.  Download was 14 and upload 7.75.  I then checked a few apps and functions on three Ipads and they all operated smoothly and at normal speed as far as I could tell.  The old Dell continues to work in its usual infuriating pace.

This is a big relief.  Options now are either to keep the desktop switched off when using the Naim app or to investigate whether there is a way of using it in a way that filters out the interference.  Perhaps a wireless rather than a wired connection, which seems a bit silly, or some device to separate the effect of the wired devices on each other is needed.  Alternatively, perhaps it is back to the idea of a replacement router which now seems to be more logical again.

Thanks for the help and any further input would be appreciated.  The Dell is very old and has become temperamental and Windows 7 seems a bit old hat although I know that there are still folk who love it.  Maybe a new desktop should be on the horizon but I have spent so much on Naim stuff lately that it will be a long saving up process and Mrs Boss will kill me if she loses her photos or has to learn a new system for playing with them.

This is extraordinary.  I do use Windows 7 (Windows 10 mis-identifies the NIC on the Asus MB of my computer and force installs a low level driver that blue screens on boot!), but I have no incompatibilities with the anything else on my network.

There is one thing I would do on the Dell, and that is to turn off 'Media Sharing'...  <Control Panel> <Home Group> <Share media with devices> and uncheck the box.
Yo may also need to stop the service <Control Panel> <Administrative tools> <Services> | <Windows Media Player Network Sharing Service> <General (tab)> and set the <Startup Type> option to Disabled.

One final thing, if Windows 7 has become temperamental, that can usually be solved by backing up all the data (do two backups if you normally use your profile to store your data!), reinstalling Windows, then reinstalling all your applications.  On a heavily used machine this will usually be beneficial about every 4 years or so, and will usually bring it back to full working order.

Thanks, Huge.  I am really greatful for that.  I will follow those steps and see what happens.

Your comment has given me extra clarity too since Mrs B has been insistent that we shouldn't move from 7 to 10 but I thought that new must be best and the Dell must be replaced.  This has given me new heart to work on getting the existing computer operating smoothly which may be quite a task since Mrs B loves messing about with the settings and the security.  If I can't do it I know a man who can.

Of course there's another option for Windows 7...

Get a copy of Windows 7 Retail edition, install Windows 10 on a new machine, install Oracle VM VirtualBox, then install Windows 7 in a Virtual Machine!

(Of course, don't install a virtual machine manager inside a virtual machine or you'll be into Inception computing and you may never find your way out - the circle may just keep spinning for ever! )

Hi Huge, Streamz, I was catching up on some threads having been away busy with work, and I saw the assertion of some routers not being DLNA compliant... and I was really trying to understand what was meant by this as routers and DLNA don’t have much if anything to do with each other.

DLNA is simply a consumer electronics organisation that profiles guidelines for application vendors to better inter operate with other at the UPnP DLNA level... the routers are not involved here. Now UPnP can be used to open and map ports between the external and internal networks, but I don’t think this has much to do with DLNA.... so scratching my head at the DLNA compliance...

And then I thought perhaps it’s versions of IGMP being used, and the router say using IGMPv2 and some software only using v3 or v1?   Again this isn’t really router specific unless the router is faulty and not handling multicast at all even at the crude indiscriminate broadcast mode (like a mini unmanaged  Netgear switch does), more a limitation of software of the apps running on the network, and not really relevant for DLNA interoperability per se, and from what I can see DLNA makes no mention of IGMP versions that should be supported... 

So I am at a loss of what a ‘non DLNA compliant’ router is supposed to actually mean....

Simon

Simon, what would you call it when you get different results from pinging 239.255.255.250 dependant on whether the laptop is connected over WiFi or via an Ethernet cable connected to a switch port of the 'wireless router' device?

Well that sounds like possibly the version of IGMP that the software might be using  is different to what the device IGMP snooper understands on the switch/bridge on your home network... or the Wi-fi access point doesn’t procsss ICMP  packets to multicast addresses, which in itself isn’t necessarily an issue... my bet is that it is either IGMP version  issue or  a gratuitous multicast group   broadcast group poll timing issue with the Wifi bridge and the app software... neither of which is necessarily specifically UPnP DLNA related.. and is more multicast group management related which is  more prevalent than the SSDP discovery protocol used by UPnP.

Disabling IGMP snooping allowed discovery to work intermittently.

Allowing the router to dynamically reconfigure itself on the fly to allow a subset of UPnP protocols (it didn't specify which apart from DLNA which also had to be specified separately with a different switch) did sort it out however, even with IGMP snooping re-enabled.  Now pinging pinging 239.255.255.250 works.

So with those settings it is compliant with the requirements of DLNA, without them (default) it isn't.

Hi Huge, none of this is really relevant to DLNA compliance. The snooping feature is simply a case of interpreting the IGMP messages... and apps can use one of three variants and router/switches/Wi-fi access points can understand one or  more variants... so you can see the potential for interoperability issues here... which of course is why the IGMP snooping disabled feature exists (on certain devices ) ... but this has nought to do with UPnP DLNA.

Simon, I think it shouldn't be relevant to DLNA operation, but if it makes SSDP unreliable for DLNA devices (even unintentionally), then it's not really DLNA compliant.

However, looking at various forums, the default configuration of some firmware versions on this router apparently intentionally block at least some UPnP related protocols via WiFi - you have to actively set the router to allow them.  No-one seems to know why it's set this way or how comprehensive the lock-down is.  It does do SPI and it's difficult to reverse engineer all the rules it implements, so I'm not even going to try.   I'm not the only one to find this: a lot of people have had to explicitly go into the Admin pages and explicitly re-enable UPnP.

There's some debate as to whether the DLNA setting is also necessary for general DLNA operation or whether it's only there for some other version(s) that have a DLNA media server that reads data from a USB port.  However, no-one apparently has ever seen a version with a USB port!

uge, there might be some confusion here, SSDP is not really about DLNA... and even here SSDP is not the issue, it’s the switching of multicast addresses packets on to the Wi-fi bridge... this is required for many services such as Bonjour, mDNS, SSDP, ipv6 functions and many many other services:

http://www.networksorcery.com/...col/ip/multicast.htm

So as you can see this is not really about UPnP at all, but TCP/IP functionality. Now devices that don’t monitor the status of its connected multicast users will effectively indiscriminately broadcast local multicast traffic... so very basic equipment can appear to work fine... and this is what little unmanaged Netgear switches do for example. However these days multicast is far more prevalent in home networks because of IPTV, TV recorders etc, and indiscriminate broadcast of higher bandwidth multicast applications can swamp the network with unwanted traffic, which can become rather sensitive for Wi-fi, were such indiscriminate broadcasting of data could kill the Wi-fi performance. Therefore Wi-fi access points these days tend to monitor the multicast user groups by snooping on the IGMP traffic, so as to ensure multicast traffic is only being sent to devices that have requested it.

The process of registering, joining and leaving multicast groups is managed by a protocol called IGMP and this under app software control. There are three versions of it, with Version2 probably being the most common for consumer devices. However it’s use, timing and configuration is down to the apps/software driving it... remember network operation and application software are often intrinsically linked. Therefore it is possible that group management code from an app doesn’t interoperate correctly with devices snooping the IGMP...

So the work around where this happens is to have the app software made more robust or disable IGMP snooping where the performance impacts are acceptable.

Therefore you can see this has as much to do with UPnP DLNA as all those other network functions and really it’s about software / network function interoperability rather than anything DLNA related.

You refer to routers and UPnP functionality... this shouldn’t be confused with DLNA, UPnP has many  parts of its specification and some parts are nothing to do with media functions are used to map ports and addresses across a router interface under software control, so the consumer doesn’t have to manually set up their forwarding paths... this is often offered as a feature to disable for improved security, but at the expense of the user having to do manual configuration. Apple prefer to use an alternate protocol for this called NAT-PMP.

Hopefully this makes sense...

With the router I have if you disable UPnP not only does it block auto configuration of port forwarding it also blocks other services on which UPnP is built (including SSDP), and that in turn blocks protocol sets based on UPnP (such as DLNA).  Even trying to open these ports manually doesn't work (it seems that as you've decided not to enable UPnP, it won't then allow use of anything it knows to be included under the UPnP 'umbrella', I don't know if this restriction applies only via the WAP).  I'm not the only one to have found this.

Whether this is by design or a design flaw no-one seems to know.  I also know it doesn't really make sense for a 'broadband wireless router' to be designed this way, but apparently it is! (personally I suspect a miscommunication of intent somewhere).

When I have a little time and enough concentration I'll install a proper WAP and leave this box as a router/firewall/ADSL TA only.

People find the same problem with WiFi cameras and even WiFi printers.  The only successful answer in each case is to enable UPnP.

Huge, this doesn’t sound right, and only a WireShark will confirm... if the device is not handling multicast addresses and in particular 

239.255.255.250 (IPv4 site-local address)
[FF02::C] (IPv6 link-local)
[FF05::C] (IPv6 site-local)
[FF08::C] (IPv6 organization-local)

Then id say the device is faulty and I would return for a refund ... if it is doing some packet inspection of the HTTP UDP messages and filtering or dropping SSDP then that is pretty impressive capability but I doubt it.. and the correct way in my opinion would be through group management.

Blocking SSDP datagrams is going to cripple a lot of functions potentially on the home network such as NAS discovery, Home computer discovery, network printing, home automation you name it... and we haven’t got to audio functions.....   also popular consumer products like Sonos would come to a grinding halt...in fact you probably wouldn’t be able to use the router for much in the consumer world...

Yep.

They (mostly) work wired on that router, but a lot of WiFi devices don't work unless UPnP is enabled.
The response from the help lines is "Turn on UPnP.  Here's how you do it...".

Can you call the device out so potentially forum members can keep clear of it or at least be aware of its   home network crippling usability  ‘feature’

Huawei 533,  firmware 1.20t

On the other hand its ADSL TA is very good - I consistently get >17mbps downlink speed on copper that's more than 30years old (previous Linksys TA struggled giving a variable speed 11 to 15mbps, but mainly toward the lower figure).

I believe firmware 2.04 is supposed to be better, but mine is one of the ones that won't update (also another known problem!).

I am sitting feeling smug after reading & trying to understand all this.        BT & their HH6 does it all,  just plug'n'play & nothing (much) to fiddle with,    & as yet after 5 months its given faultless uninterrupted 80/20 service.    Thinking about it,  it was the same with the previous HH5 hub.      

That sounds a bit like my AirPort Extreme. It's not very flexible and so is ideal for the confused. It has no flashing lights or aerials either, which is a big plus for me.