Yet another Wake on Lan/Wan static ARP question

I've recently updated to a MT-6000 from an old TP-Link router, running the stock fimware (21.02-SNAPSHOT) while i familiarize myself with OpenWrt.

I've been using a shortcut on my phone for a few years that wakes my server remotely, over wan or lan, all i had to do was enable mac binding on the router.

I initially assumed it should be easily able to adapt my solution to the Flint2. For the better part of a week I've scoured the internet looking for a way, and while I've come across the exact issue loads of times, it's often a few years old and there never seems to be a solution.

Eventually, i managed to wake the PC with a magic packet to the WAN but only after I run:

ip neigh replace 192.168.0.100 lladdr 68:05:ca:7f:10:c2 dev br-lan nud permanent

As I've found, PERMANENT static arp doesn't mean immutable. If device is off it stays permanent until i wake it, switching to reachable, stale and failed within 30 minutes of being powered off again.

What I'm thinking is a script that checks the ARP table for the reachable/stale state and just runs the ip neigh command.

Since i can't code and this being a relatively simple script, i thought it safe to use AI to do:

#!/bin/sh

# Configuration
TARGET_MAC="68:05:ca:7f:10:c2"
TARGET_IP="192.168.0.100"
TARGET_DEV="br-lan"
CHECK_INTERVAL=30  # seconds

LOG_TAG="arp-monitor"

log_msg() {
    logger -t "$LOG_TAG" "$1"
}

make_permanent() {
    ip neigh replace "$TARGET_IP" lladdr "$TARGET_MAC" dev "$TARGET_DEV" nud permanent
    if [ $? -eq 0 ]; then
        log_msg "Made $TARGET_IP ($TARGET_MAC) permanent"
    else
        log_msg "Failed to make $TARGET_IP permanent"
    fi
}

log_msg "Starting ARP monitor for $TARGET_IP ($TARGET_MAC)"

while true; do
    # Get the current state of the target IP
    STATE=$(ip neigh show "$TARGET_IP" | grep -i "$TARGET_MAC" | awk '{print $NF}')
    
    if [ -n "$STATE" ]; then
        case "$STATE" in
            REACHABLE|STALE)
                log_msg "Detected state: $STATE for $TARGET_IP"
                make_permanent
                ;;
            PERMANENT)
                # Already permanent, do nothing
                :
                ;;
            *)
                # Other states: INCOMPLETE, DELAY, PROBE, FAILED
                log_msg "Current state: $STATE for $TARGET_IP"
                ;;
        esac
    fi
    
    sleep "$CHECK_INTERVAL"
done

And the startup script /etc/init.d/arp-monitor

   #!/bin/sh /etc/rc.common

   START=99
   STOP=10

   USE_PROCD=1

   start_service() {
       procd_open_instance
       procd_set_param command /root/arp-monitor.sh
       procd_set_param respawn
       procd_set_param stdout 1
       procd_set_param stderr 1
       procd_close_instance
   }

Before i go ahead, Is there a reason this is a bad ideea or would not work as I expect it to?

Thanks

as long as you're using gl.inet's firmware, you should post your questions over at their forum.


It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

1 Like

Granted, not using an official build so I'm not going to blame anyone if I brick my device based on advice given here, although from my (limited) experience and what I've read it's not really that different.

In my case, it shouldn't really matter if I'm running a fork or an older build as I'm mostly interested if anyone sees any issue with the logic behind it, and perhaps if the code would work as intended on stock OpenWrt.

It is a heavily modified and outdated fork so yes it is really different. :frowning:

even if the script looks fine/sane here, there's no guarantee it'll work for you, since you're not running a firmware based on the same code.

our blessing means nothing.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.