DHCP is set up so that IP addresses are fixed assigned to mac addresses of allowed clients. There is no freely allocated address. In Pakon statistics, one client identified only by a MAC address is registered. I can assume that this is a client in guest wifi network. If I saw the allocated IP in the guest range (10.111.222.100-105) I would be sure. That’s how I have my doubts. How do I find the truth?
Is this solvable in Luci-Hostnames by assigning names for the specified IP range of Guest ?
the solution is to assign names even for guest IP range in Luci-DHCP and DNS- Static Leases settings. It will be reflected immediately in the Pakon output
===>> Pakon
According to https://www.wireshark.org/tools/oui-lookup.html that MAC address (f0:43:47:df:10:64) is from:
F0:43:47 Huawei Technologies Co.,Ltd
Might it be a mobile phone in the guest network, perhaps?
This is already documented in our documentation. Take a look here:
https://docs.turris.cz/basics/apps/pakon/#is-it-possible-to-have-client-names-instead-of-their-mac-addresses
What is the purpose "hostname" of the Luci - Network - Hostnames … section?
How is it different from "hostname" from Luci - Network - DHCP and DNS - Static Leases ?
This puts hostname IP-address tuples into the system, which will only be useful if the IP addresses are statically assigned. I believe this effectively allows to query dnsmasq for those hostnames.
This allows to identify hosts by their MAC addresses, and then assign a static DHCP lease which in turn will result in statically assigned IP addresses, making them suitable to be injected into the domain name resolution.
Pakon requires the MAC to name mapping from the latter, as far as I understand, given that otherwise pakon returns raw MAC addresses.
I use only fixed IP - these are displayed in Pakon.
Furthermore, I have set different hostnames defined in Luci - Network - Hostnames … do not manifest themselves to me anywhere (Pakon) and their Function meaning is incomprehensible to me.
Well, add something to hostnames and the query the dns server and compare with pakon:
Here is the content of LuCI->Network->Hostnames:
Hostnames IP address
voip 192.168.42.61
and here is what is in LuCI-> Network → DHCP and DNS → static leases:
Hostname MAC-Address IPv4-Address
C610A-IP AA:BB:CC:DD:EE:FF 192.168.42.61
Querying the omnia’s DNS from a client returns:
client:~ user$ nslookup voip.lan
Server: 192.168.42.1
Address: 192.168.42.1#53
Non-authoritative answer:
Name: voip.lan
Address: 192.168.42.61
client:~ user$ nslookup C610A-IP.lan
Server: 192.168.42.1
Address: 192.168.42.1#53
Non-authoritative answer:
Name: C610A-IP.lan
Address: 192.168.42.61
So both defined names are resolved by the domain name service.
But in foris’ pakon all I see is C610A-IP, so both hostnames and static leases will be injected into the omnia’s DNS, but onlt static leases offer the required MAC to hostname mapping that pakon seems to require. Which makes sense, as it is far easier to change an IP address of an endhost (and DHCP might do that automatically anyways for non-static address assignments) than the MAC address. Sure, dedicated opponents will also be able to spoof the MAC address, if they realize that MAC addresses are monitored, but as always security is never absolute.
I have different results
Hostsnames - bad answer
root@turris:~# nslookup FujistuH.lan
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find FujistuH.lan: NXDOMAIN
** server can't find FujistuH.lan: NXDOMAIN
root@turris:~#
Static leases - good answer
root@turris:~# nslookup Fujitsu_kuchyn.lan
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: Fujitsu_kuchyn.lan
Address 1: 192.168.2.120
*** Can't find Fujitsu_kuchyn.lan: No answer
root@turris:~#
=== >> But it doesn’t really matter… the meaning of hostsname is not clear. If I cancel these records " LuCI->Network->Hostnames:… What’s going to happen? Something will be wrong ?
Are you sure you clicked “Save&Apply” in LuCI, otherwise you see the entries on the web page, but they are not applied…
This is benign, if you call nslookup Fujitsu_kuchyn.lan not from the turris router but from a different host it will resolve just fine, as far as I can both hostnames and static leases will be added to /tmp/kresd/hints.tmp. See cat /tmp/kresd/hints.tmp to confirm.
I keep repeating it, hostname really is just a method to inject hostnames into the routers domain name server, just note that the local network top level domain (by degault .lan) will be added.
They will not resolve any more… BUT if you also assigned static lease entries in DHCP and DNS then these are still auto added to kresd and will keep working, assuming you enabled the “Enable DCHP clients in DNS” checkbox in foris’ DNS tab.
As far as I can tell the hostnames mechanism is older, and the fancy have the DHCP server tell the DNS server option developed only later. I prefer the fancy option, but I understand why the other mechanism exists as well…
1 - yes, save and apply … and router restart – Other station results
root@turris:~# nslookup Tab_JiriH.lan
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: Tab_JiriH.lan
Address 1: 192.168.2.115
*** Can't find Tab_JiriH.lan: No answer
root@turris:~# nslookup Tabl_Jirina.lan
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: Tabl_Jirina.lan
Address 1: 192.168.2.115
*** Can't find Tabl_Jirina.lan: No answer
root@turris:~#
2 - root@turris:~# cat /tmp/kresd/hints.tmp
192.168.2.101 HP_mini.lan
192.168.2.102 Router_WNR612.lan
192.168.2.104 Pokoj.lan
192.168.2.106 Tabl_Jarda.lan
192.168.2.108 Rezerva_1xxx.lan
192.168.2.110 Synology_NAS.lan
192.168.2.112 Popcorn_C-200.lan
192.168.2.114 Rezerva_2xxx.lan
192.168.2.116 Rezerva_3xxx.lan
192.168.2.118 Epson_XP-700_print.lan
192.168.2.120 Fujitsu_kuchyn.lan
192.168.2.103 Rezerva_4xxx.lan
192.168.2.105 Sony_mobil.lan
192.168.2.107 Rezerva_5xxx.lan
192.168.2.109 HP_mini_wifi.lan
192.168.2.111 Topfield_SRP2411.lan
192.168.2.113 TV-Philips.lan
192.168.2.115 Tabl_Jirina.lan
192.168.2.117 Rezerva_6xxx.lan
192.168.2.119 Fujitsu_wifi.lan
10.111.222.100 Guest_0_Iva.lan
10.111.222.101 Guest_1.lan
10.111.222.102 Guest_2.lan
10.111.222.103 Guest_3.lan
10.111.222.104 Guest_4.lan
10.111.222.105 Guest_5.lan
192.168.2.110 SynologyH.lan
192.168.2.118 EpsonH.lan
192.168.2.111 TopfieldH.lan
192.168.2.120 FujitsuH.lan
192.168.2.112 PopcornH.lan
10.109.54.193 GatewayH.lan
192.168.2.101 HP_minH.lan
192.168.2.102 R-0H.lan
192.168.2.104 PokojH.lan
192.168.2.106 Tab_JarH.lan
192.168.2.108 R-2H.lan
192.168.2.114 R-7H.lan
192.168.2.116 R-3H.lan
192.168.2.103 R-1H.lan
192.168.2.105 SonyMobilH.lan
192.168.2.107 R-6H.lan
192.168.2.113 PhilipsH.lan
192.168.2.115 Tab_JiriH.lan
192.168.2.117 R-3H.lan
192.168.2.109 HP_min_wifiH.lan
192.168.2.1 RouterH.lan
10.111.222.100 Guest_0H.lan
10.111.222.101 Guest_1H.lan
10.111.222.102 Guest_2H.lan
10.111.222.103 Guest_3H.lan
10.111.222.104 Guest_4H.lan
10.111.222.105 Guest_5H.lan
root@turris:~#
3 - Hostnames is therefore a useless function for me, I will delete the records
Well, nslookup returns exactly the address listed in hints.tmp. The error " Can’t find Tabl_Jirina.lan:" is related to calling nslookup on the router if you do the same on a different host in your network this error will probably not show, I believe this is benign but might be somethingvfor team turris to look into.
Yes, as I said if static leases are in use and kresd/Foris/TOS is configured to inject DHCP names into DNS the hostname mechanism is redundant. But I have the feeling I failed to convey that message, but am happy you figured it out by yourself in spite of my confusing posts.