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

This post is in English

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

This post is in English

@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

This post is in English

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

This post is in English

@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.

This post is in English

The Internet-Box holds a mapping of MAC to IP reservations for DHCP. This is persistent.

The only place where the WOL command appears on the Internet-Box (as far as I am aware) is in the “Not Connected” list. This list is not persistent, with entries ageing and disappearing over time. It would be convenient if those entries which had a reserved IP did not “age”. I think this is a new problem that I did not have in previous version of the software/hardware.

I do have a back door VPN which is functional, but messy - the VPN is L3 and WOL is L2…

I have found Swisscom’s Customer Service to be excellent in the past, so I am sure that when I contact them next month, I will get an excellent response. I wish other Telco’s were half as good.

Thank you for all the useful comments.

Graham

This post is in English

It did occur to me, but in today’s energy world, I would feel bad about leaving it on. It is only a few watts, but…

Graham

This post is in English

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.

This post is in English

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

This post is in English

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

This post is in English

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…

This post is in English

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.

This post is in English

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

This post is in English

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

This post is in English

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

This post is in English

Swisscom Network Engineer IP+ AS3303,
ASN3303

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

This post is in English