UNIQUE constraint failed: network.hwaddr in insert_netDB_device - FTL v6.6

[CMDR-Sloma]

Versions

• Pi-hole Core: v6.4.1
• FTL: v6.6
• Web: v6.5

Platform

• OS: Raspberry Pi OS (Debian Bookworm)
• Platform: Raspberry Pi (native install, not Docker)

Expected behaviour:

FTL should update existing network device records without errors.

Actual behaviour / bug:

FTL logs the following error every minute, cycling through different devices:

ERROR: SQLite3: statement aborts at 23: UNIQUE constraint failed: network.hwaddr;
[INSERT INTO network (hwaddr,interface,firstSeen,lastQuery,numQueries,macVendor)
VALUES (?1,'N/A',?2,?3,?4,?5);] (2067)
ERROR: insert_netDB_device("4c:17:44:f1:dd:5b",<timestamp>, <timestamp>, <count>,
"Amazon Technologies Inc."): Failed to step (error 19): constraint failed

The error cycles through multiple devices (different MAC addresses). It appears
immediately after FTL starts, even on a completely fresh database.

Steps to reproduce the behaviour:

1. Run Pi-hole FTL v6.6 with active DHCP clients on the network
2. Wait approximately 1-2 minutes after FTL starts
3. Observe error in /var/log/pihole/FTL.log repeating every ~60 seconds

Debug Token

• URL: https://tricorder.pi-hole.net/6EIDFC92/
  

Additional context

• The error occurs even after deleting the entire pihole-FTL.db database
• FTL appears to INSERT a new record for a device, then attempt to INSERT again
  instead of UPDATE when the device is seen again
• DNS resolution and ad blocking continue to work normally
• The issue did not occur before upgrading to v6.6
• Pi-hole is configured with a single upstream DNS server (local CoreDNS instance)

[rdwebdesign]

I don't know exactly what is happening.

Can you please try setting resolver.macNames to true using this command?

pihole-FTL --config resolver.macNames true

Then check the logs again. Does it fix the error messages?

Also, why did you set this option to false?

[CMDR-Sloma]

This error was flooding the logs regardless of the flag true or false. Weird... I must have left it on false just before I posted. Anyway, after I changed it to true again the errors disappeared... Looks settled now...

[DL6ER]

Thanks for the report — this is a confirmed bug. Fix is in #2846

Setting macNames back to true masks the bug because the lookup function then queries the database properly, finds the existing device, and takes the UPDATE path instead of INSERT.

The macNames setting is meant to control whether FTL resolves client names from MAC addresses — it should have no effect on whether FTL can find existing devices in the network table. The fix removes the early-return guard from the device lookup function. The name-resolution gating (in getNameFromMAC and the gravity-db MAC lookup) is separate and unaffected, so macNames = false will continue to work as documented for its intended purpose.