Avalon FMS 3.3.2 only displays one original Avalon Nano 3 because all devices report DNA = 0000000000000000 - The fix to work with Avalon Nano 3 (the original) - bug: is deduplicating using the DNA value - fix: change to the IP or something else

[raccoon3capri2DIXIE]

I got FMS working on Debian 13. Since I have miners on its own physical separate network, I just wanted a small and light web browser so I could have a means to manage the miners if/when needed. So, I spun up a lightweight VM to run Debian so I could run Firefox and the VM is on the same network segment.

I believe the Nano 3 was released after this FMS core was last developed, so no one should expect it to even run or work, but it does. ChatGPT led me to this project as a means to manage a bunch of Nano 3. So, I went with it.

Problem:
FMS would scan a subnet and find multiple Nano 3 miners, but then only show 1 miner. Apparently, FMS is using the DNA number as a deduplication mechanism, which is all zeros on the Nano 3 - every miner uses all zeros, so they all have the same DNA number. Which is why it would only show one miner. I used ChatGPT to help me troubleshoot, and it worked and fixed the issues.

Fix:
Change the deduplication key in the sqlite database. Amazingly, ChatGPT was able to rework the sqlite queries and reset it and it works.

Here is the summary I had ChatGPT write up for me:
Subject: AvalonFMS 3.3.2 only displays one original Avalon Nano 3 because all devices report DNA = 0000000000000000

Summary:
AvalonFMS 3.3.2 for Ubuntu/Linux appears to deduplicate Avalon Nano 3 miners by the "DNA" field in the local SQLite database. Original Avalon Nano 3 units all appear to report the same DNA value of 0000000000000000, even though each unit has a unique HDNA value and unique IP address.

As a result, when multiple original Avalon Nano 3 miners are scanned, AvalonFMS only displays one miner in the dashboard. The miners are reachable, respond correctly on port 4028, and return unique HDNA values, but FMS collapses them into one record because of a unique database index on the dna column.

Environment:

• AvalonFMS version: 3.3.2 for Ubuntu/Linux
• OS tested: Debian 13 64-bit
• VM: VMware ESXi VM
• CPU/RAM: 2 vCPU, 4 GB RAM
• Miners: Original Canaan Avalon Nano 3 units
• Miner model reported by API: nano3
• Miner API: cgminer 4.11.1, API 3.7
• Miner port: 4028/tcp open
• Web UI port: 80/tcp open

Issue:
Multiple original Avalon Nano 3 miners are discovered at the network level and respond correctly to cgminer API commands. However, AvalonFMS only shows one miner after scanning multiple known-good miner IPs.

Expected behavior:
AvalonFMS should show each Nano 3 as a separate miner, using a unique identifier such as IP address, MAC address, or HDNA when DNA is missing or zero.

Actual behavior:
AvalonFMS only shows one miner because all original Nano 3 units report:

DNA[0000000000000000]

The local SQLite database contains a unique index on the dna field:

CREATE UNIQUE INDEX tb_machine_log_dna_idx on tb_machine_log (dna);

Because all miners report the same DNA value, FMS treats all Nano 3 units as the same machine.

Evidence:
All tested Nano 3 units respond correctly to:

printf '{"command":"version"}' | nc -w 5 <miner_ip> 4028

Example response:

{
"STATUS":[{"STATUS":"S","Msg":"CGMiner versions","Description":"cgminer 4.11.1"}],
"VERSION":[{
"CGMiner":"4.11.1",
"API":"3.7",
"PROD":"Avalonnano",
"MODEL":"nano3",
"HWTYPE":"PMMv1_X1",
"SWTYPE":"MM318_X2",
"VERSION":"24071801_42c628d",
"HVERSION":"24071801_b906c52_6223725",
"UPAPI":"2"
}],
"id":1
}

All tested miners also respond correctly to:

printf '{"command":"stats"}' | nc -w 5 <miner_ip> 4028

The stats output shows the same DNA value on all units, but unique HDNA values:

[masked with XXXXXXX] HDNA is unique on every miner

Miner 1:
DNA[0000000000000000]
HDNA[02010000XXXXXXX6]

Miner 2:
DNA[0000000000000000]
HDNA[02010000XXXXXXXd]

Miner 3:
DNA[0000000000000000]
HDNA[02010000XXXXXXX1]

Miner 4:
DNA[0000000000000000]
HDNA[02010000XXXXXXX2]

Miner 5:
DNA[0000000000000000]
HDNA[02010000XXXXXXXd]

Miner 6:
DNA[0000000000000000]
HDNA[02010000XXXXXXXc]

Miner 7:
DNA[0000000000000000]
HDNA[02010000XXXXXXXe]

Miner 8:
DNA[0000000000000000]
HDNA[02010000XXXXXXX6]

Miner 9:
DNA[0000000000000000]
HDNA[02010000XXXXXXX5]

Miner 10:
DNA[0000000000000000]
HDNA[02010000XXXXXXX5]

SQLite schema issue:
AvalonFMS creates the following unique index:

CREATE UNIQUE INDEX tb_machine_log_dna_idx on tb_machine_log (dna);

This prevents multiple Nano 3 records from existing when all units report DNA = 0000000000000000.

Temporary workaround:

1. Start AvalonFMS.
2. After the app opens, drop the unique DNA index from the local SQLite database.
3. Then run the scan.

Command used:

DB=$(find /root/.local/share -type f -name 'machine_log_table.db' | head -n 1)
sqlite3 "$DB" "DROP INDEX IF EXISTS tb_machine_log_dna_idx;"
sqlite3 "$DB" "PRAGMA index_list(tb_machine_log);"

After dropping the index while AvalonFMS is already open, scanning multiple Nano 3 miners works and multiple miners appear in the dashboard.

Important note:
AvalonFMS recreates the tb_machine_log_dna_idx unique index on application startup. Therefore, the index must be dropped after AvalonFMS opens and before scanning.

Launcher workaround:
This script starts AvalonFMS, waits for the database to initialize, then drops the bad unique DNA index automatically.

#!/bin/bash

cd "$(dirname "$0")" || exit 1

APP="./AvalonFMS"

if [ ! -x "$APP" ]; then
chmod +x "$APP"
fi

echo "Starting AvalonFMS..."
"$APP" 2>&1 | tee "$HOME/avalonfms-error.log" &

APP_PID=$!

echo "Waiting for AvalonFMS database to initialize..."

for i in {1..10}; do
sleep 1

DB=$(find "$HOME/.local/share" /root/.local/share -type f -name 'machine_log_table.db' 2>/dev/null | head -n 1)

if [ -n "$DB" ]; then
echo "Found DB: $DB"
echo "Dropping bad unique DNA index..."
sqlite3 "$DB" "DROP INDEX IF EXISTS tb_machine_log_dna_idx;"
break
fi
done

if [ -n "$DB" ]; then
echo
echo "Current machine_log indexes:"
sqlite3 "$DB" "PRAGMA index_list(tb_machine_log);"
echo
echo "AvalonFMS is ready. You can scan now."
else
echo "WARNING: Could not find AvalonFMS database."
fi

wait "$APP_PID"

Suggested fix:
AvalonFMS should not use DNA alone as the unique identifier when DNA is blank, null, or 0000000000000000.

Suggested logic:

• If DNA is valid and non-zero, use DNA as the unique machine ID.
• If DNA is 0000000000000000, use HDNA instead.
• If HDNA is unavailable, fall back to MAC address.
• If MAC is unavailable, fall back to placeId + IP address.

A safer database index would be based on one of these:

• placeId + ip
• placeId + hdna
• placeId + mac
• or a computed unique device identifier that handles zero DNA values correctly.

Impact:
This bug prevents AvalonFMS from being useful as a central dashboard for multiple original Avalon Nano 3 miners. The devices are reachable and API-compatible, but the dashboard collapses them into one machine due to duplicate DNA values.