Static addressed devices disappear from not connected list

[Graham]

It does have a DHCP reservation. It is in "Assign static IP address automatically".    There is no WOL command in that list.

The WOL command is in the "Not Connected" list.  I would expect that if a device was in the DHCP reservation list, it should be excluded from dropping off that list.

I agree that if nothing timed out the list would be very unmanageable... very...

Despite this, I think that the Internet-Box 3 is an excellent router.  The features list is very good.  I wish I could achieve the same with a UK based Telco - in particular, the VOIP side.

Thanks

Graham

[bitracer]

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

[Graham]

The NAS is set to DHCP and always acquires the correct IP address (192.168.1.4) given out by the router whenever it is powered on.

The problem is that if it has been off for a few weeks, there is no way for the router to issue the WOL frame to power it on and I am at a distance...

[bitracer]

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.

[ChristianEb]

Potentely @MichelB can help here...

Regards

Chris

[Tchris]

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

[Graham]

Thanks Chris,

I used to have Cisco routers there, but Swisscom kept upgrading the service faster than I could buy new routers.  With the Cisco very little was obscured and you could make them do almost anything.  However I am very happy to live with the minor Internet Box issue, but would welcome a fix - I have a messy workaround.

Thanks for your help.  I'll take it up with Swisscom in a few weeks.

Graham

[ChristianEb]

i think (my personal view) to go with a CPE/Switch/Router/Firewall where you can configure what you like to have, is sometimes not a bad thing. 

Regards and best wishes

Chris 

[Tchris]

Additional internal router has been my preference for well over 2 decades: 

• Downside: you must set it up correctly to get the results you want
• Upside: you get the results you want after you set it up correctly

Tread carefully!

I have no desire for inbound connections (VPN or otherwise) to my private double-NAT-net, but I read that additional care is needed (configuring the internal router) to make it work. 

The other direction (VPN outbound connections originating from my double-NAT-net to corporate-net) "just worked" for me.

Chris