Two questions,
-
What kind of background is needed to contribute to Pi-Hole’s development?
-
Is there a way to add a feature request for one of the future Pi-Hole releases?
Ad 1.
That is a broad question.
In general, you'd need some experience for just the bits of artifacts you intend to improve. That could be any of the languages used (including e.g. C, Shell, PHP, JS, Docker, Markdown, to name a few), but depending on the actual change, you certainly don't need to be an expert in any of those.
I guess anyone could correct a spelling mistake.
However, a common requirement would be familiarity with handling GitHub, or willingness to learn that.
(That can be daunting at first, but our developer's have been observed guiding first-time contributors towards acceptance of their pull requests on occasions. 
)
For the specific feature you request, I'd guess that would touch quite a few elements (new UI elements, database extensions, shell scripts, perhaps even C for pihole-FTL), so it would require more of an extensive set of skills, and certainly a thorough understanding of the existing codebase.
Ad 2.
Just open a new Topic in the Feature Requests category.
Note that you'd need a certain Discord trust level to do so.
FRs are not tied to specific releases.
Any FR may be considered for any release, given interest, time and opportunity to implement it.
Do you want this topic to be converted to a Feature Request?
2 Likes
For the specific feature you request, I'd guess that would touch quite a few elements (new UI elements, database extensions, shell scripts, perhaps even C for pihole-FTL)
That's doable, considering I did dabble here and there with shell scripting, to begin with.
certainly a thorough understanding of the existing codebase.
Could you please point out any resource/documentation to understand how Pi-Hole works, as a starting point, I would like to spend my spare time during weekends to delve into this topic.
Just open a new Topic in the Feature Requests category.
Note that you'd need a certain Discord trust level to do so.
Do you want this topic to be converted to a Feature Request?
If this topic can be converted into feature request, considering I don't have the discord trust level, it would be much appreciated.
Thanks.
Sounds good - we'd be happy to review your submission.
However, as yubiuser has mentioned, you should be aware that we are moving towards Pi-hole v6, which will introduce some major changes, including the way how UI is rendered (it won't be PHP anymore, nor will lighttpd a dependency requirement).
Also, it seems that your request could be addressed via different implementation alternatives, so it may well be worth some prior discussion (which the developers would likely have more time to spend on once v6 is out).
You may want to consider to stall your effort until v6 is released.
(Would be a pity of you'd created a full blown PHP UI that Pi-hole v6 wouldn't package anymore, wouldn't it?)
In the meantime, I've converted your topic into a FR.
I fear there is no single point of resource/documentation. I guess you already found our documentation at https://docs.pi-hole.net/?
However, the underlying code is more complex. We have the central C-Binary FTL which does all the DNS resolution and group management. It includes the dnsmasq core. The FTL repo is at GitHub - pi-hole/FTL: The Pi-hole FTL engine.
We webinterface is located at GitHub - pi-hole/web: Pi-hole Dashboard for stats and more.
Both are glued together via bash scripts - they scripts provide the installer and the pihole command including all subcommands. Located at GitHub - pi-hole/pi-hole: A black hole for Internet advertisements
What you want is already possible!
There is a misunderstanding here (see past tense in the "so far, ..." sentence) and what follows immediately afterwards in the same post you are quoting here:
All your VPN clients have been given an entry in the network table with a "mock-MAC" used by FTL to treat IP-only devices as it they were known by their hardware address (this relies on a certain stability of the IP<->client relation which is most often given in VPNs).
The rest of the quoted post gives an example how to do this, you can use that without the extra checkout step. The hardware address for your Wireguard devices will be the IP, prefixed by ip-, so, e.g.,
ip-10.66.66.57
or
ip-fd42:42:42::57
2 Likes
So, as of this writing, my FTL version is 5.23
network table has an extra column at the end: alias client_id (referencing the aliasclient table's IDs). I'm gonna write down all the steps, for anyone else in future, who might stumble upon this issue, and wanna figure a way around it.
Load up the pihole-FTL database
sudo pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db
Now, you can run .tables command, and it should return you the following,
For our solution, we are gonna focus on two tables, namely network and aliasclient. To see the content of network table, we are gonna use the following command,
.mode column
.headers ON
SELECT * FROM network;
This, for example, gave me client details on my Pi-Hole network, as follows,
A device, say an iphone, has been assigned 10.66.66.62 IPv4 and fd42:42:42::62 IPv6 address on a VPN network (in my case Wireguard). @DL6ER pointed out that since this iphone is connected to VPN network with only IPv4 and IPv6 assignment, it's been given a mock-MAC by FTL, which in case is ip-10.66.66.62 and ip-fd42:42:42::62.
So, what we gotta do is assign each of these devices i.e. iphone with mock-MACK address ip-10.66.66.62 and ip-fd42:42:42::62 a common identifier, which will reside in the column aliasclient_id.
Before we can even give a common value aliasclient_id for ip-10.66.66.62 and ip-fd42:42:42::62, we need to first declare it in the table aliasclient. So, in my case, I'll be choosing value 0 as aliasclient_id. This would be declared in aliasclient table as follows,
INSERT INTO aliasclient (id,name,comment) VALUES (0,'iphone',NULL);
Now that I've declared 0 as aliasclient_id for my device iphone, I'm gonna use it in the network table,
UPDATE network SET aliasclient_id = 0 WHERE hwaddr = 'ip-10.66.66.62';
UPDATE network SET aliasclient_id = 0 WHERE hwaddr = 'ip-fd42:42:42::62';
This is from the Pi-hole dashboard,
So, why does it still have two entries for device/client iphone?
Well, you wanna ask FTL to import the new aliasclient(s),
sudo pkill -RTMIN+3 pihole-FTL
And now, the dashboard looks like this,
You need to repeat this every ever pair of IPv4 and IPv6 mock-MAC assigned for a given device/client in your network table (ensuring that the aliasclient_id is declared in aliasclient table).
On a side-note, there's a bug. Even after assigning aliasclient_id to a single device have two distinct IPv4 and IPv6 mock-MAC, when you click on the new aliasclient (context - this example) on dashboard, it does perform the following query,
http://pi.hole/admin/queries.php?client=aliasclient-0&type=blocked
But that leads to an empty list,
Is this a bug?
There is no need to install it. Pi-hole has a built-in sqlite support via
pihole-FTL sqlite3
Kind of. I guess there were no recent queries (as in: within the last 100 queries Pi-hole received) queries made by this client. It's the same as in Query log shows less than 100 entries when only blocked/permitted queries are shown · Issue #2535 · pi-hole/web · GitHub
But there is a real cosmetic bug: "blocked" is doubled within the header
I saw you edited your comment, but the correct command need the database file:
sudo pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db
Gotcha. Corrected.
Kind of. I guess there were no recent queries (as in: within the last 100 queries Pi-hole received) queries made by this client. It's the same as in Query log shows less than 100 entries when only blocked/permitted queries are shown · Issue #2535 · pi-hole/AdminLTE · GitHub
But there is a real cosmetic bug: "blocked" is doubled within the header
Well, there were queries. It's just neither client=10.66.66.62 nor client=aliasclient-0 returns a null table. However, query log has retained all logs of DNS requests made by client iphone i.e. 10.66.66.62.
I'm running a similar configuration myself.
I have no issues with telling clients apart, but I've arrived their via different road.
For once, I am only propagating Pi-hole's IPv4 address as DNS resolver.
As clients are only aware of an IP4v4 DNS resolver, they'll send their DNS traffic via IPv4.
And for the Wireguard connection, PiVPN keeps track of wg client hostnames in /etc/pivpn/hosts.wireguard, using pivpn as a separate local domain (e.g. my iPhone.fritz.box is registered as iPhone.pivpn).
I personally wouldn't want those requests to be merged - I like that I can tell whether a device connected locally or via Wireguard by looking at the names.
But this is just my personal preference.
I saw you edited your comment, but the correct command need the database file:
Ah. I was running my commands straight up from /etc/pihole/ command. Now fixed it. Thanks for pointing it out!
As clients are only aware of an IP4v4 DNS resolver, they'll send their DNS traffic via IPv4.
So what happens when, let's say, an app makes IPv6 DNS queries? Don't you think there would be DNS leak, in the sense that IPv6 DNS queries would be resolved outside of Wireguard+PiHole Tunnel? Hope this makes sense.
Where would that app send its DNS query via IPv6?
My home network’s router has IPv6 routing disabled. However, WireGuard assigns both IPv4 and IPv6 addresses to its clients. Now, I checked my Pi-Hole dashboard (WireGuard + Pi-Hole) and found that there were IPv6 requests in the Query Log, even when my home network has IPv6 is disabled. This makes me conclude that at WireGuard’s client, there’s some sorta Tunnel like 6to4/6in4/6rd happening, to rush IPv6 packets via IPv4 route g vs is WireGuard.
My question is - what would happen to those IPv6 DNS requests? (since Pi-Hole is only configured as IPv4 DNS resolver)
How did you configure your Wireguard connection?
If you do configure a full IPv4/IPv6 tunnel wireguard tunnel, and an IPv6 DNS server along with it, clients would use it.
As you see IPv6 clients in your Pi-hole's log, that would imply that you did configure one of your Pi-hole's IPv6 addresses as DNS server.
Now, if you would not do so:
As client's are not aware of an IPv6 DNS server address, they would use the remaining IPv4 address for DNS.
Now, a malicious app could send DNS requests to some hard-coded IPv6 DNS servers.
Such misbehaviour would have to be addressed by other means than DNS, e.g. by the gateway's firewall (and of course, that would just as well be true for hard-coded IPv4 addresses).
How did you configure your Wireguard connection?
I used this
If you do configure a full IPv4/IPv6 tunnel wireguard tunnel, and an IPv6 DNS server along with it, clients would use it.
As far as I can tell, it isn't full tunnel. The Wireguard peers (and firewall rules) are configured to only forward DNS queries between peers and the server.
As you see IPv6 clients in your Pi-hole's log, that would imply that you did configure one of your Pi-hole's IPv6 addresses as DNS server.
Yes. Every peer's (i.e. client's) config file has their DNS servers set to server's IPv4 and IPv6 address.
As client's are not aware of an IPv6 DNS server address, they would use the remaining IPv4 address for DNS.
I think the clients are aware of server's IPv6 address. Unless Pi-Hole isn't configured to be used as DHCP server + workaround, there's no easy way for clients (let's say one of the clients is a smartphone, and there are two apps: one of the apps uses IPv6 routing i.e. backlinks and DNS requests made via this app is solely via IPv6, while the other app hasn't adopted IPv6 standard yet, which means all the DNS queries would be IPv4 in nature) ... ... ... between the DNS queries made by these two apps from the same client, both the Query Log and Dashboard would treat them as two different devices.
If one is not to use Pi-Hole as DHCP server, the only other way is this, which is a bit broken, but it still does the job.
On a side-note: I'm gonna try and answer my own question,
My question is - what would happen to those IPv6 DNS requests? (since Pi-Hole is only configured as IPv4 DNS resolver)
At least when my home router was configured as DHCP server, and I had both PPPoE IPv4 and IPv6 routing, even when the router's DHCP server was IPv4, all IPv6 DNS queries were forwarded to the DNS server configured for IPv4 (DHCP LAN settings). Maybe this might being some insight to others, who would be fumbling with a similar experience.
My usage of 'full' in 'full IPv4/IPv6 tunnel' refers to connectivity rather than routing.
If you would only configure an IPv4 tunnel, then your system may configure IPv6 connectivity as it sees fit, including acquiring an IPv6 DNS server address.
This may lead to IPv6 traffic by-passing Wireguard and thus Pi-hole.
If you configure a tunnel for full IPv4 and IPv6 connectivity, the Wireguard software would configure your system's DNS resolvers as provided by the wireguard connection configuration, for both IPv4 as well as IPv6.
Of course they are, as you've configured them to be.
If you abstain from configuring an IPv6 DNS resolver for Wireguard, but otherwise keep a full IPv4/IPv6 tunnel, then the OS would only be aware of an IPv4 DNS server address.
So in that configuration, even if some software somehow would try to send DNS requests via IPv6:
It is not been configured to use any IPv6 DNS servers by the network (i.e. your Wireguard VPN).
Consequently, all DNS requests your Pi-hole peer would see would originate from a client's IPv4 address.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.