Possible fix for Powerwall wifi drop outs (ARP issues)

[BuongiornoTexas]

This discussion summarises an issue I've had with unreliable wifi on my powerwall, and my solution to the issue.

The TLDR on this is that my powerwall wifi stops responding unless I add a permanent static ARP table entry (not the same thing as a static IP) on the client machine that is making network requests to the powerwall. This happens even when the powerwall has static IP address assigned by the router based on the powerwall MAC address.

This solution may help others with intermittent powerwall dropouts from their network. Rather than one enormous entry, I'll do this as a series of comments on this post outlining:

• Symptoms and detection and testing the solution.
• Solution on Windows.
• Solution debian.

[BuongiornoTexas]

Symptoms and detection

Preamble

For the rest of the discussion, I'll talk about the client machine, which is the machine that wants to talk to the powerwall - a windows, linux or mac machine running PWD or wanting to access the powerwall local webpage. None of the remaining discussion relates to the router, even if the router is being used to assign a static IP to the powerwall (my setup).

Also for this discussion, I'll assume the powerwall has a static IP address of 192.168.25.11 and a wifi MAC address of XX-XX-XX-XX-XX-XX. Please substitute your IP and MAC addresses as required.

Symptoms

The symptoms for this problem are pretty straightforward: The powerwall works fine on wifi for some hours or days and then stops responding, even though the Tesla app says it is still connected to the wifi network. Further reconnecting the wifi using the app gets powerwall responding again.

Unfortunately, these symptoms will be common to a number of possible wifi networking problems. To test if it is the ARP issue, first check that powerwall is not responding to pings and then check the powerwall entry in the ARP table on the client machine (preferably relatively recently after the network drops).

• On windows and probably also macos, try arp -a 192.168.25.11. The ARP issue may be affecting you if the response includes stale, e.g.:

Interface: 192.168.25.195 --- 0x14
  Internet Address      Physical Address      Type
  192.168.25.11         XX-XX-XX-XX-XX-XX     stale

• On debian try ip neighbor 192.168.25.11. Again, "STALE" may indicate the ARP issue.

192.168.25.11 dev enp3s0 lladdr XX-XX-XX-XX-XX-XX STALE

Finally, it's also possible that the ARP entry may not appear at all - this will probably only happen on machine that only contacts the powerwall infrequently. Unsurprisingly, in this case, the powerwall will also not respond to pings.

Confirmation of problem

At this point, we still only have a maybe on the ARP problem. To confirm, try adding a static ARP entry for the powerwall on the client machine. The following sections describe how to do (and undo) this. Try the appropriate method out and see if the dropouts still happen - if so, it's not the ARP problem (and you can undo the static ARP). Otherwise, your dropout problem is hopefully fixed.

[BuongiornoTexas]

Windows static ARP setup

For windows 11 and probably most other flavours, start an elevated shell and enter the following commands:

c:> netsh
netsh> interface ipv4
netsh interface ipv4> show interfaces

For me, the output looks like:

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
 20          20        1500  connected     Ethernet 3

Get the interface name from this. "Ethernet 3" in my case, as my windows machine connects to the router by ethernet, which then connects to to the powerwall by wifi (this is an insidious issue!).

Now add the static ARP for your interface (using Ethernet 3 below). Watch out for spelling of neighbor in the next bits!

netsh interface ipv4> add neighbors interface="Ethernet 3" address=192.168.25.11 neighbor="XX-XX-XX-XX-XX-XX"

Hopefully your powerwall becomes available immediately.

To delete the static ARP, do the following commands:

c:> netsh
netsh> interface ipv4
netsh interface ipv4> delete neighbors name="Ethernet 3" address=192.168.25.11

I know all of this should also be possible using the ARP command, but the above approach is the recommended windows style.

[BuongiornoTexas]

macos static ARP setup

I'm still looking into this. I'll update when I've done a bit more reading, but I'm expecting this will be done using the arp command.

[BuongiornoTexas]

Debian and other systems using NetworkManager

Use the ip neighbor show command to get the interface name - for me this is in the third column, and I have only one active device/interface - again wired ethernet to the router with an interface name of enp3s0.

You can test if you have the static ARP problem by using the following command, which adds the static ARP until next reboot (replacing the IP address, MAC address and interface name as required).

ip neighbor replace 192.168.25.11 lladdr XX:XX:XX:XX:XX:XX nud permanent dev enp3s0 

If this does work, you can make it permanent using this hacky approach:

• Create a dispatcher script in /etc/NetworkerManager/dispatcher.d. In my case 50-static-arp. This file needs to be owned by root with rwx perms and rx for others.

• The file contents look like this (make edits as above).

#!/bin/sh
# Extremely hacky method to get permanent arp entry added each time interface comes up
if [ "$1" = "enp3s0" ]; then
  if [ "$2" = "up" ]; then
     ip neighbor replace 192.168.25.11 lladdr XX:XX:XX:XX:XX:XX nud permanent dev enp3s0 
  fi
fi

Reboot and you should be away. To delete the static ARP, remove the dispatcher file.