D7000 - WoL - PERM ARP entry

[Greebo]

Hello,

So, I really need to enable wake-on-WAN functionalty on my D7000. I logged in via telnet and created a permanent ARP cache entry:

ip neigh change 192.168.0.3 lladdr xx:xx:xx:xx:xx:xx nud permanent dev group1

This works fine and WoL seems to work, which is an excellent news (so Netgear people cannot claim that the router cannot support it!).

Now, the problem is - as you would expect - that the ARP cache is exactly what the name suggests - cache memory. Each time the device is reseted or ip is accessed from the admin panel (eg show connected devices) the permanent arp entry reverts back to a temporary one. /etc/ethers does not exist, and even if it existed the entire content of /etc would be erased on reboot and replaced with a default template so it doesn't really make sense to edit it. Also D7000 does not appear to run cron, so it is impossible to automate the ip neigh command.

Did anyone find a way to make this work?

[antinode]

> my D7000 [...]

   D7000 or D7000v2?  Firmware version?

> Did anyone find a way to make this work?

   Not I, but if a set of shell commands will do the job ("I logged in
via telnet [...]"), then you should be able to use a Kermit script to
log in (from some local computer or other) and issue those commands.
And then run it periodically (or when needed).

[Greebo]

D7000

Firmware 1.0.1.74_1.0.1

The solution that works for me is as follows:

1. login to the router using telnet

2. have a look what’s connected:

arp

3. identify the IP, MAC, and device name of the PC I want to WoL-enable

4. use ip

ip neigh change xxx.xxx.xxx.xxx lladr yy:yy:yy:yy:yy:yy nud permanent dev name

In my particular example:

ip neigh change 192.168.0.3 lladdr 18:31:bf:2b:a7:29 nud permanent dev group1

and voila. The connection will show with a PERM status and the computer will wake when a magic packet is sent from the external Internet. I also forwarded ports 7 and 9 (UDP) to the particular IP using the Netgear panel. This is all tested and works fine.

However, when the router is reseted for any reason, or when the Netgear control panel is being accesseed (attached devices is the main offender) the ARP cache defaults back to temporary entries.

Scripts do not work as there is no way to run them. The router OS does not have CRON, or rc.local files. Also, if the config is changed in /etc/rcS - the whole content of the /etc folder is being re-written at reboot (I haven’t figured out yet where is the source).

So the only way appears to be to have another machine on the local network that is constantly turned on and invokes the terminal commands - which defeats the purpose for having a high tech router in the first place. If I had to run a PC constantly, I could equally use it as a router (and configure it the way I want). I really don’t get the Netgear’s philospohy on this.

[antinode]

> Scripts do not work as there is no way to run them. [...]

   "I don't know how" and "there is no way" are spelled differently for
a reason.

   Which part of "use a Kermit script" was unclear?  When you did a Web
search for "Kermit script", did you find nothing interesting?

> So the only way appears to be to have another machine on the local
> network that is constantly turned on and invokes the terminal commands
> [...]

   That's true for this scheme, but it could be something as simple (and
low-power, and cheap) as a Raspberry Pi.

> [...] which defeats the purpose for having a high tech router in the
> first place.

   You lost me.  Your "high tech router" was designed as an appliance,
not as a user-programable general-purpose computer with router features.

> [...] If I had to run a PC constantly, I could equally use it as a
> router (and configure it the way I want). [...]

   Sure, if your "a PC" also included an Ethernet switch, and similar
wireless-network capabilities.  If that's what you want, then you
certainly have my permission.

> [...] I really don't get the Netgear's philospohy on this.

   Really?  It seems pretty simple to me.  Why waste resources on
features which very few potential customers will ever want?  Especially
when letting a user play around in the low-level OS of the router is
very likely to generate more support problems than sales.

> The solution that works for me is as follows: [...]

   I'll admit that automating that (not-very-clearly-defined) procedure
might require some work, but I don't immediately see anything which
would be impossible.

   As a very simple example, the following is quick Kermit script (from
a DCL script) which logs in via Telnet (port 23), and issues a "reboot"
command.  The DCL script runs on a VMS system, so I'd guess that the
"sys$input" notation/syntax would need to be adjusted on any other OS.

$! <--- (DCL comment delimiter.  "dsl" refers to my D7000.)
$!                    %1      %2         %3
$!                   User    Password   Command
$ kermit + sys$input "admin" "password" "reboot"
set input echo on
set host dsl 23 /raw-socket
input 2 login:
if failure exit 5  LOGIN
output \%1\10
input 2 Password:
if failure exit 6  PASS
output \%2\10
input 2 \#
if failure exit 7  SHELL
output \%3\10
input 10 \#
exit