I complained in an earlier post that my NDX regularly looses its wifi connection. However, I could usually wake it up using Fing (an android app that scans networks) to send it “ping” commands.
I have a dual-boot PC and when running linux I have started to send ping commands to the NDX. I do this every day or so and it seems to be working. My next plan is to use a raspberry-pi (mini/micro computer) to run 24/7 sending a ping command every hour or so.
This is the script I use …
#!/bin/sh
while true
do
ping -c 4 192.168.1.5
echo
echo
echo “++++++++++++++++++++++++++++++++++++++++++”
echo
echo
sleep 1000
done
Basically it sends 4 ping commands (“-c 4”) and then waits for 1000 seconds before sending the next lot (“sleep 1000”).
My NDX1 regularly loses the LAN connection (or it plays music according to the display, but the sound is gone). For years I have had to reactivate the web radio or even completely restart the device to bring it back to life. These measures often didn’t help at the first attempt.
In my initial experience, the Fing app helps here: I am currently using the “wake-on-lan” function with positive results.
Thanks for the tip.
Instead of those echo’s, you could just use the date command which will display the date (of course) , but you will be able to tell if its still running, whereas with the echo, they will soon fill up the screen , and you will have to wait for 1000 seconds to see if it moves
I had not known that I could actually point a browser at the NDX. Now that I have discoverred this I have changed my ping command from ping -c4 192.168.1.5
to wget 192.168.1.5 mv index.html index.old.html
Hopefully this will improve things.
Thanks for the hint and advice.
Like wot garyi sez, what a palaver.
I’ve had NDX since 2014, it’s never lost it comms or missed a beat over anything - ever.
Just friggin’ wire it, if you can’t workout a means to get a long cable run, then get a mesh//extender and wire it to that.
Another automatic way is to ensure you have a router with an inbuilt ICMP querier like the BT Smart Hub, and those queriers will keep the IP group addresses and ports open on the wlan and Ethernet.
It also helps improve slightly the Naim app performance. You need to have UPnP media server though on your network.
If you don’t have an automatic querier in your ISP router, then many managed switched like an Cisco 2960 allow you to create one in a simple instruction in the running config.
But not sure why your wlan is timing out… something doesn’t sound right somewhere, perhaps a bug in the NDX though I can’t remember seeing this, perhaps because I have a ICMP querier.
However also there is wlan WPA2 encryption re key interval that can be shortened, by default typically one day, but you reduce down on a quality wlan access point controller to say 3600 seconds.
I had wireshark traces of broadcast traffic receiving no response from a wired 272. After a HTTP request the device started responding to broadcast traffic allowing discovery.
Network stack/state issue on device.
All ready for support (as it happened intermittently) but then we sold the 272 and stopped caring.
Discovery is not broadcast, its group addressing… and that requires your network equipment to properly respond to IGMP status events… otherwise ports can close.
I have always optimum networking that responds to group addresses and IGMP and never saw an issue on my NDX.
Yep sounds like your network equipment had incorrectly disassociated the group port going to your streamer…
Yep not arguing just saying what happens… but I use BT SmartHub and Cisco/ubiquitinswitches which correctly respond to IGMP .
Which traffic?
This should be 239.255.255.250 UDP port 1900 for UPnP discovery and correct functioning UPnP.
That is used for discovery and being active on the network for UPnP… nothing to do with port 80 tcp.
Obviously all group addressing is UDP
Honestly can’t remember. But not TCP port 80 obviously- when your device is in the situation it won’t show in app but responds to HTTP.
UDP response missing probably.
I’d have to look at the port rules on our 2960 as they will allow the traffic. Gi0/1 doesn’t allow anything the streamer doesn’t need to see. I think they were a mirror of the setup on our 3650 (although that is a far more capable device in terms of FWing).
Well the streamer has to see the simple discovery protocol … fundamental part of UPnP… if only doing web streaming then not important.
A switch is not a firewall, it can provide access control, but that is not a firewall… so you should allow all ports open on a switch for the protocols used.
If you want lock down, use a sticky MAC address and port security.
It’s not the same difference at all… I possibly understand now why younger seeing issues.
The NDX2 implemented a wider range of ICMP controls from memory.
