# Question regarding multiple group assignments for same clients

**URL:** https://discourse.pi-hole.net/t/question-regarding-multiple-group-assignments-for-same-clients/34184
**Category:** Help
**Created:** [June 9, 2020, 11:07am UTC](https://discourse.pi-hole.net/t/question-regarding-multiple-group-assignments-for-same-clients/34184 "2020-06-09T11:07:32Z")
**Posts on this page:** 1
**Showing post:** 10

<div class="post-metadata">

### Author: ![yubiuser](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/yubiuser/32/12100_2.png) [@yubiuser](https://discourse.pi-hole.net/u/yubiuser)
#### Post date: [June 11, 2020, 8:14am UTC](https://discourse.pi-hole.net/t/question-regarding-multiple-group-assignments-for-same-clients/34184/10 "2020-06-11T08:14:14Z")

</div>

> [@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.

> [@Subnetting is not working with most relevant entry](https://discourse.pi-hole.net/t/subnetting-is-not-working-with-most-relevant-entry/31482/1):
>
> 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`

```auto
[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](https://discourse.pi-hole.net/t/subnetting-is-not-working-with-most-relevant-entry/31482/25):
>
> 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](https://discourse.pi-hole.net/t/feedback-for-allow-defining-clients-by-their-mac-address-host-name-and-networking-interface/32324) 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.

---

_[View the full topic](https://discourse.pi-hole.net/t/question-regarding-multiple-group-assignments-for-same-clients/34184)._