Question regarding multiple group assignments for same clients

[yubiuser]

@rossc719

In v5.0 It seems to be acting as though it is finding the 192.168.2.0/24 client mapping first, and stopping there, ignoring the 192.168.2.1 entry completely.

You're right.

Carefully reading the other topic I linked above revealed that only the first matching client mapping applies.

@mgg

As I saw, in the selection from the database the first matching record is taken.
See line 278-279 in get_client_groupids (gravitiy-db.c). The Select is limited to 1.
Maybe there must be evaluated if there are more than 1 matching entry. If there is only one everything works great.

@rossc719

Is there a good way to debug what's happening?

You can add DEBUG_DATABASE=true to /etc/pihole/pihole-FTL.conf and restart pihole. You should see in /var/log/pihole-FTL.log

[2020-06-11 10:05:15.352 28624] SQL: Comparing 127.0.0.1 vs. 10.0.1.0/16 (subnet 255.255.0.0) - NO MATCH
[2020-06-11 10:05:15.352 28624] SQL: Comparing 127.0.0.1 vs. 10.0.10.1/24 (subnet 255.255.255.0) - NO MATCH
[2020-06-11 10:05:15.353 28624] Querying gravity database for client 10.0.20.198 (getting best match)
[2020-06-11 10:05:15.353 28624] SQL: Comparing 10.0.20.198 vs. 10.0.1.0/16 (subnet 255.255.0.0) - !! MATCH !!
[2020-06-11 10:05:15.353 28624] SQL: Comparing 10.0.20.198 vs. 10.0.1.0/16 (subnet 255.255.0.0) - !! MATCH !!
[2020-06-11 10:05:15.353 28624] SQL: Comparing 10.0.20.198 vs. 10.0.10.1/24 (subnet 255.255.255.0) - NO MATCH
[2020-06-11 10:05:15.353 28624] SQL: Comparing 10.0.20.198 vs. 10.0.1.0/16 (subnet 255.255.0.0) - !! MATCH !!
[2020-06-11 10:05:15.353 28624] Querying gravity database for client 10.0.20.198 (getting groups)
[2020-06-11 10:05:15.354 28624] Querying gravity database for client 10.0.10.182 (getting best match)
[2020-06-11 10:05:15.354 28624] SQL: Comparing 10.0.10.182 vs. 10.0.1.0/16 (subnet 255.255.0.0) - !! MATCH !!
[2020-06-11 10:05:15.354 28624] SQL: Comparing 10.0.10.182 vs. 10.0.1.0/16 (subnet 255.255.0.0) - !! MATCH !!
[2020-06-11 10:05:15.354 28624] SQL: Comparing 10.0.10.182 vs. 10.0.10.1/24 (subnet 255.255.255.0) - !! MATCH !!
[2020-06-11 10:05:15.354 28624] SQL: Comparing 10.0.10.182 vs. 10.0.10.1/24 (subnet 255.255.255.0) - !! MATCH !!
[2020-06-11 10:05:15.355 28624] SQL: Comparing 10.0.10.182 vs. 10.0.10.1/24 (subnet 255.255.255.0) - !! MATCH !!
[2020-06-11 10:05:15.355 28624] Querying gravity database for client 10.0.10.182 (getting groups)
[2020-06-11 10:05:15.355 28624] Querying gravity database for client 10.0.1.3 (getting best match)
[2020-06-11 10:05:15.356 28624] SQL: Comparing 10.0.1.3 vs. 10.0.1.0/16 (subnet 255.255.0.0) - !! MATCH !!
[2020-06-11 10:05:15.356 28624] SQL: Comparing 10.0.1.3 vs. 10.0.1.0/16 (subnet 255.255.0.0) - !! MATCH !!
[2020-06-11 10:05:15.356 28624] SQL: Comparing 10.0.1.3 vs. 10.0.10.1/24 (subnet 255.255.255.0) - NO MATCH
[2020-06-11 10:05:15.356 28624] SQL: Comparing 10.0.1.3 vs. 10.0.1.0/16 (subnet 255.255.0.0) - !! MATCH !!
[2020-06-11 10:05:15.356 28624] Querying gravity database for client 10.0.1.3 (getting groups)
[2020-06-11 10:05:15.357 28624] Querying gravity database for client 10.0.1.4 (getting best match)
[2020-06-11 10:05:15.357 28624] SQL: Comparing 10.0.1.4 vs. 10.0.1.0/16 (subnet 255.255.0.0) - !! MATCH !!
[2020-06-11 10:05:15.357 28624] SQL: Comparing 10.0.1.4 vs. 10.0.1.0/16 (subnet 255.255.0.0) - !! MATCH !!
[2020-06-11 10:05:15.357 28624] SQL: Comparing 10.0.1.4 vs. 10.0.10.1/24 (subnet 255.255.255.0) - NO MATCH
[2020-06-11 10:05:15.357 28624] SQL: Comparing 10.0.1.4 vs. 10.0.1.0/16 (subnet 255.255.0.0) - !! MATCH !!
[2020-06-11 10:05:15.357 28624] Querying gravity database for client 10.0.1.4 (getting groups)

Unfortunately it will not tell you which group was assigned in the end. That's why I wrote in the other topic

Subnetting is not working with most relevant entry

While playing with subnet assignment I came across the fact that there is no output to which groups a client belongs if different (non-identical) subnets are defined. I created "subnet clients" /16 and /24 and assigned different groups to them. Connecting a device in both ranges, only the /24 should apply. But there is no indication (on cli and web interface) to which group the client was assigned in the end. [2020-06-09 17:57:29.578 3137] SQL: Comparing 10.0.10.136 vs. 10.0.1.0/16 (subnet 25…

Note: There is an PR which greatly enhances the possible client definitions which has a debug output which client got which group ID. But the commit has not been backported.

@rossc719

Shouldn't the whitelist win?

Yes it will win if it is assigned to the client. That's the reason

@rossc719

If I add 192.168.2.0/24 to Group2, so that it is a member of all three, then the whitelist takes effect for 192.168.2.1.

workes.

As a crude workaround you could try to delete 192.168.2.0/24 as a client and re-add it so that the client ID is greater than for 192.168.2.1 and pihole will assign the right group for it.

If it doesn't work and you don't want to wait for v5.1 you could checkout the development branch of ftl which should fix the subnet assignments. But be aware that this code is still under development und could fail in other circumstances.