or run what @technicalpyro suggested but you'll need to re-checkout web and FTL afterwards, so the first command is preferred.
Well, interesting, this killed the system-provided function inet_pton. I was expecting this to be robust against invalid input but this doesn't seem to hold true. I will implement a check for IP addresses before calling this kernel function. You triggered an edge-case with an empty CIDR. Thanks for trying exactly this. It is now fixed. Please try further things to break it
The idea is to do two things:
Try to obtain a host name for clients newly added to the table which are unknown to FTL
Re-resolve all host names from all addresses once an hour.
No. 2 wasn't working because I wrapped everything into a single transaction and forgot to actually commit the changes to the database. This is now fixed as well. Please see if they populate after some time (as said, it may take up to the next full hour).
Can confirm. Took some time, but now I see all names for clients where Local DNS Records exist.
What I get now might be normal debug output.
[2020-05-19 19:00:00.677 17215] Res: no more rows available
[2020-05-19 19:00:00.678 17215] Res: no more rows available
[2020-05-19 19:00:00.679 17215] Res: no more rows available
[2020-05-19 19:00:00.679 17215] Res: no more rows available
[2020-05-19 19:00:00.680 17215] Res: no more rows available
[2020-05-19 19:00:00.681 17215] Res: no more rows available
[2020-05-19 19:00:00.682 17215] Res: no more rows available
[2020-05-19 19:00:00.683 17215] Res: no more rows available
[2020-05-19 19:00:00.684 17215] Res: no more rows available
[2020-05-19 19:00:00.685 17215] Res: no more rows available
[2020-05-19 19:00:00.688 17215] Res: no more rows available
[2020-05-19 19:00:00.689 17215] Res: no more rows available
[2020-05-19 19:00:00.690 17215] Res: no more rows available
[2020-05-19 19:00:00.691 17215] Res: no more rows available
[2020-05-19 19:00:00.692 17215] Res: no more rows available
[2020-05-19 19:00:00.693 17215] Res: no more rows available
You should now also see interface names being populated for devices added to the network table for devices more than one hop away. There are three restrictions for when they can be obtained:
The said device has do at least one query after you update to the most recent FTL
The query must be made over UDP (interface information isn't available for TCP queries at the moment)
You may not use the option bind-interfaces.
I'll put some more thoughts in relaxing 2 & 3, however, getting the interface for them is way trickier than one would have thought.
edit Restriction no. 2 is solved, no. 3 will likely stay.
192.168.4.3 is my phone connected through Wireguard. We get both the interface as well as the host name. The latter is defined through local DNS records. It shows the interface wg0 as my config file is /etc/wireguard/wg0.conf. If you'd name your wireguard interface differently, then you may see other things here (like home or work).
Note: For OpenVPN connections you'd see tun0 etc.
We also get interface and host name of 127.0.0.1.
The third device actually exists physically. Its record was complete even before my changes.
I know, I can already hear it ... Client selection by interface...
There we go, per-Interface is now supported as well. To keep interface names separate from host names, we will prepend interface names with a colon like :eth0 in order to rule out accidental matches.
The client column does now support the following for client selection:
Type
Example
IP address
192.168.2.12
IP subnet
192.168.2.0/24
MAC address
AA:BB:CC:DD:EE:FF
host name
localhost
interface
:eth0
edit The first match (from top to bottom) will be used to define the groups of a client.
I think we're on a good way here and definitely need more testing of all the new possibilities.
Your pace is awesome. Soon there will be no features left to be implemented....
It get fairly complicated with all the possibilities now. What is the order clients will be assigned? IP, MAC, Hostname, Interface. The moment one property fits all the others are skipped? Although the explanation is long already this might be worth putting there.
What is missing now is the "interface" in the explanation and tooltip hint.
And the "warning" only says "IP" and "MAC".
I can already here it... support wildcards......and vendor
So I have a device connected from a different source using Pihole as dns server on a VPN. I assume I would probably see my interface as eth0 since the interface is not directly connected to the pi.
Yes. The table I put from top to bottom. The first hit counts. IP is more important than MAC address which is more important than hostname which is more important than interface.
Yeah, I did not update the web interface at all for this. Still do be done.
wildcards: Already implemented with IP/CIDR. I don't think wildcards will be needed for MACs, host names or interfaces.
vendor: Why would I add rules for a specific vendor to be blocked? I see no reasoning here. If you want to block specific, e.g., Samsung domains to prevent Samsung devices from talking home ... you should probably just block them for all devices.
edit I think what I added in here can be very useful. If we go ahead and allow more and more, then users will use it even when they should not. Because a lot of users tend to overcomplicate things when there is no need to. It takes a lot of experience to see the simple solution, sometimes.
I will edit the priority into my table above.
Another, rather small update to this experimental branch: As the ip address is a UNIQUE field in the network_addresses table, new assignments of a previously seen IP address will automatically move an already known old address to the new device. This makes removing old entries somewhat less important. However, the new possibility to specify clients by host names may make it more important to be able to remember devices not seen for longer so they can get recognized sooner.
Hence, we disable the automated removal for now, but leave the FTL config option MAXNETAGE so users can re-enable this if they feel a need for it (setting it to a positive value will re-enable automatic removal of entries).
We'll have to see how this goes.
Automated rescanning of client groups a certain time after their first query (if their host names are only known a few minutes later, etc.) is still a to-do.
I can see one use case: on most modern Android devices you can't change the hostname without root access. But they usually contain android. One could group all android devices easily with wildcard hostnames.
I know. I only need the default group myself but I can see the need for fine-grained group assignments in some cases.
I may go very far but I assume the number of Android devices in the household should be fairly manageable. Especially is their host names stay constant over the life-time of these devices.
One question: Why would you black- or whitelist something exclusively for all Android devices? Whay is this a thing that should not apply to all other devices in the network as well? I do see reasons for per-device settings (like parents/kids) but defining rules for an entire range of devices still feels strange.
As you see, I'm just collecting ideas here, trying to get justifications for adding something as we should not do it for the sole reason of that we're able to do it (if that's the question we could even have fully fledged regex support here!...).
I have no good reason. I don't need that feature but tried to imagine what others might want to use it for. Just wanted to bring it up so it is discussed now before the whole branch gets public one day and users might want to see this (they might then provide a good reason).
I can't even see the need for per interface grouping in a small network environment.
It was removed after 24 hours. I meanwhile figured this is an too aggressive cleaning mechanism and disabled auto-cleaning a few days ago:
However, data already wiped out at this point obviously stays lost.
Yes, this will very likely be the device with no IP address in your network table. The IP address of devices not on the local network is coded into the MAC address so it can be regenerated for the client suggestion. However, as it is less meaningful for users, the network table just shows N/A as hardware address for these devices. When you're already running the latest version (I assume so) no IP addresses should get lost any longer.
