Hi Graham,

Is it as simple as static-IP vs reserved-IP in the DHCP server????

ASIDE I had endless problems with some otherwise-clever “smart-managed” switches that delivered 10gps over CAT-5E cabling but just didn’t understand reserved-IP (which I normally use for all infrastructure devices). I gave them static-IP and got rock-solid 10gps over crap cables for the past 3 years.

I hated the static-IP, but it worked (and maybe they fixed their firmware since).

Similarly (exactly oppositely!), persuade whatever is serving DHCP (to the network that NAS is living in) to give a reserved IP to the NAS.

If you have control over the DHCP-server, AND the DHCP-server understands reservations (we are back in the early 1990’s for this not to be totally normal).

Find the DHCP-server GUI.

Ensure your NAS address is not in DHCP-pool (change pool range and/or NAS address to suit)

**Reserve** that address for NAS with DHCP-server.

Find your NAS GUI:

Configure NAS to join the network via DHCP (not static address).

Midnight++ here: gone,

Chris

Fumbling in the dark:

arp -a

…sees my (currently sleeping) NAS (with a reserved IP)

…and a laptop with a reserved IP that is hard-OFF for the past 6 days.

NAS did not wake with the arp-tickle (of course).

NAS is a current resource on the Mac I’m typing at now, but NAS has not been accessed for over 12 hours.

ping my.nas.reserved.address

…Request timeout for icmp_seq 0 (..seq 999)

NAS sleeps: ping won’t fix it.

If t’was my problem, I might try with something like a remotely executable script to send the “magic WoL packet”…but I don’t normally play with this stuff: I wish you luck but I’m out, sorry.

Chris

Hi Graham,

Don’t wait!

This is not an officialy-monitored Swisscom forum, so you only get unofficial opinion (with rare interventions from Swisscom).

Contact Swisscom direct: they are usually pretty responsive to subscribers for simple problems (and yours is a problem that is at least simply-expressed, if not simply resolved).

regards, Chris

That’s not true, Swisscom employees monitor the forum. You see the replies in the threads.

I wouldn’t wait either. Set the DHCP reservation and see how that goes.

My statement is precisely true!

Swisscom-folk visit (and occasionally intervene).

But posting on this forum is NOT the same as me-customer telling Swisscom-supplier “Your stuff doesn’t work as advertised - fix it, or I’m gone!”.

..this never happened to me: whenever I had issues they got swiftly and professionally fixed by Swisscom.

I’ve happily lived with Swisscom’s plusses and minuses for many decades: expensive(yes); responsive(yes); works (yes - or else!!!!), future: who knows? Fibre is 20m from my home…who will offer me FTH first?

Chris

Of course, for that you have the Customer Support. This is hardly a case of “fix or else”.

@bitracer

Agreed (not an or-else!! case)…

…at least for my situation where I don’t need to access my NAS from a remote site 1,500km distant). Personally, I don’t want anybody (including sysadmin-me) accessing any part of my network from more than 15m distant (and admin-VLAN is wired-only on a couple of ports so just 2m).

If I were 1,500km distant, I might have a different opinion.

I had a look at remote-WoL this afternoon: it is Layer-2 broadcast stuff, so not obvious (to simple-minded me) how you would get the WoL magic packet safely through a Router (Swisscom or otherwise) without being “virtually inside” the LAN (VPN). Once VPN-ed into the LAN, the Swisscom router is out of the equation: not guilty; not innocent; not there as far as WoL is concerned!

The internet (as always) proposes various kludges for forwarding WoL packets, sometimes with some sort of security (a password) to deter Smurf & friends, sometimes using Arduino or R-Pi hardware. I only skimmed it since I have no interest in implementing remote-WoL myself.

IP-Directed-Broadcast seems to be blocked/off-by-default on just about everything these days (blame Smurf & friends, not Swisscom).

Good-luck to Graham, but I guess VPN is his only route.

Chris

The reserved vs static issue:

Somewhere up above, arp -a successfully finds my (sleeping) NAS: the DHCP reservation associates the NAS MAC-address with an IP-address somewhere in bowels of the DHCP-server: my NAS is there (sleeping or otherwise), but its MAC and IP addresses are both known to the network!

Contrast with assigning a static IP-address to NAS: sure it will be able to claim that IP-address (unless you screwed up and static IP is in DHCP-pool or statically given to more than one device), and sure it will have the same MAC-address (if you are still using the same ethernet port on the NAS).

…but WoL is Layer-2 (MAC-addressed, not IP-addressed)

…and doesn’t give a damn about IP-addrersses

…gimme the MAC-address!

…if the device went to sleep, nothing on the network can provide the MAC-address!

Chris

@Graham have you considered placing the files you need frequently on cloud storage service like myCloud (or iCloud, Google Drive, OneDrive, Dropbox,…).

Or just keep the NAS permanently on. It will go to sleep and spin down the drives when not in use.

It doesn’t make sense to make this list persistent. It would show every device that has ever connected to the network even if it will never be connected again. That fits your use case but it’s not really a universal solution.

Try the approach with the DHCP reservation.

Did you let it acquire that IP address or the NAS is still set to fixed IP?

Aha, ok. Then it makes sense to request this improvement. If there is a reservation and the device is not online, it should allow you to send the WOL magic packet. Regardless of the time the device is offline, if there is a DHCP reservation it should honour that.

Potentely @MichelB can help here…

Regards

Chris

Sorry for the brain-fart yesterday…I was distracted by my network where the Swisscom-box is just a modem-with-NAT. I forgot that your Swisscom box is the network router, DHCP-server, etc

.

Your original concern was, in essence, arp-table entry time-out defeating your WoL attempt.

My world is different, so what follows is speculation:

The dynamic entries in the arp-table (those generated by arp requests as the network goes about its business) DO time out-after some implementation-defined interval (for example, Cisco seems to use 14,400sec).

Manually assigning an IP-address to a device leaves it to be discovered by arp requests…a dynamic arp-table entry…that will time out.

A sleeping WoL-enabled NAS has a MAC-address “visible” to the network (else could not receive the WoL frame). [why is this “frame” called a “magic packet”???]

There may be different “phases” to dynamic arp-table entry time-out as the MAC:IP entry goes from fresh-meat to not-used-recently to timed-out, maybe with a short-circuit to don’t-work somewhere in the mix. This is probably not relevant to our discussion.

Static arp-table entries do NOT time-out, but DO get cleared on reboot.
e.g. the arp-table entry generated by:
sudo arp -s 192.168.69.70 1f:2e:3d:4c:5b:6a
does not time-out, but is cleared at reboot.

??? is this TRUE???

Wild-guess: reserving an IP in the DHCP-server does an arp -s equivalent under the hood, so DHCP-reservations do not time-out in the arp-table.

??? is this TRUE???

sudo arp -f /some/file
Can be set-up to reinstate static arp-table entries from a file

…and run automatically as the device powers up

…surviving a reboot.

I’ve seen implementations for a few Linux-species…some are not pretty.

…if the above is even close to true, it prompts an interesting question:

If the static arp-table entry disappears, it should only happen on reboot.

But reboot of what?
Swisscom-box “owns” the arp-table and the DHCP reservations so should reinstate static arp-table entries at startup using an arp -f equivalent.

So it should all “just work”.
But chez vous it doesn’t!

!!!DESUFNOC YLSUOIRES

Chris