Franklin Whole Home network behavior

I recently had a PV solar + Franklin Whole Home battery system installed. Electrically I have no complaints, working fine. However the battery connects to my WiFi, and I have complaints.

While none of these are deal-breakers, they definitely qualify as something of which I expect better for a not-inexpensive utility-certified profesionally-installed system.

The nexus of the system is the Franklin aAgate. The aGate is configured and controlled via a mobile app. Ther is no local controller, though it listens on port 9000 but not using any app protocol I know of.

Config

Confusing nomenclature

The aGate configuration app uses confusing and nonstandard network nomenclature. “Auto-connecting” and “Manual connect” is not how one normally describes configuration values. Phones and laptops have been connecting to WiFi for years, so using the same UI terms as them will reduce confusion. ‘Automatic Connection’ == ‘DHCP’ (Dynamic Network Configuration Protocol), ‘Manual Connection’ == ‘Static’.

Netmask, lack thereof

There is no place in the app to configure the network size, aka the ‘network prefix length’ aka ‘netmask’. If an aGate is installed onto a network that is using a less common (but entirely valid) prefix length it may not be able to communicate with Franklin. There is no way to calculate the the correct value, it either has to be supplied by the network via DHCP or by the user when configuring manually. I don’t know if it is honoring the DHCP-supplied value but it definitely doesn’t let me manually configure it. On a phone it shows up as Network prefix length:

Ignoring DHCP values

Devices on a network normally get their DNS server address along with the address they should use themselves from the local network via DHCP (‘automatic connect’ in the Franklin app). The aGate is ignoring that value and pointing itself at Google. Even when I perform ‘Manual Connect’ and put in the correct value I can see from the network logs that it is ignoring it and connecting to 8.8.8.8. This is poor client behavior. I could understand a fallback to that if none is supplied by the network or user, or the network supplied value doesn’t work, but outright ignoring the supplied value is improper behavior. This may cause issues if a security-conscious home network person (of which I suspect there is increased overlap with someone installing solar+battery then average) blocks random outgoing DNS; then the aGate will not be able to phone home over WiFi. I use AdGuard Home to protect the network from ads and malware (more on this below) and am disappointed that the aGate is bypassing that. I added a dst-nat rule to my local firewall to direct those requests back to AdGuard, but this is sub-optimal.

The UI orginally shows 8.8.8.8 for the Auto-Connecting DNS server, which is not what is provided by DHCP. Selecting manual mode allows specifying this value, but it is still ignored.

Mikrotik rule:

# .20 is the adGuard instance
/ip firewall nat
add action=dst-nat chain=dstnat comment="redirect google DNS to adguard" dst-address=8.8.0.0/16 to-addresses=192.168.1.20

Scammy looking hostnames

Firewall logs show the aGate is attempting connections out to fwh.wceui.top:9000. That hostname was flagged as potential malware by AdGuard, using a configuration https://adguardteam.github.io/HostlistsRegistry/assets/filter_12.txt . I submitted an exception at https://github.com/DandelionSprout/adfilt/pull/1159, but I’ve never seen a legitimate site ending in .top, and the nonsense name wceui.top does not look good. I see some internet references of some disreputable hardware (like garbage-tier dashcams) connecting back to wceui.top. Gibberish website names like that are a indicator of malware / scams, not a reputable product permanently installed in a home and operating on my network. Franklin should invest in a more reputable name. Also, at least today, whatever it is expecting to find there isn’t listening - it tries to connect but the remote end never picks up. Doesn’t look good.

Example:

forward: in:solarwifi out:bridge, connection-state:new src-mac fc:70:2e:15:25:f1, proto TCP (SYN), 192.168.128.252:52764->18.188.130.67:9000, len 60

DNS spam

Related to DNS, the aGate is the 5th chattiest device on my network, and I have multiple high-usage laptops/tablets/phones etc so that is saying something.

So far today it has made >46,000 requests, while the solar controller has only made 446. A network appliance that only has 3 static destinations should not be making that many DNS requests. Further, it is making garbage requests that do not help it connect to anything. The device is spamming requests for 0.0.0.0.in-addr.arpa and 8.8.8.8.in-addr.arpa – the answer is useless to the appliance. The remaining top entries are either local utility domains, test queries, or the multiple Alexa devices querying the mothership. Poor behavior – an appliance should not be doing this.

The legit queries being made by the aGate:

a6f63crce3ufk-ats.iot.us-east-2.amazonaws.com. A
a6f63crce3ufk-ats.iot.us-east-2.amazonaws.com. AAAA
fwh.wceui.top. A
fwh.wceui.top. AAAA
open-api.franklinwh.com. A
open-api.franklinwh.com. AAAA

The bogus queries:

0.0.0.0.in-addr.arpa
8.8.8.8.in-addr.arpa
Literally every IP address it gets back in response to a DNS request in the form  of a PTR request