I have two OpenWRT devices. One acts as the Router and is connected to the modem, the other device is wired to the Router (in a LAN port on both sides) and acts as a simple AP.
The Router does DHCP and has a list of all clients including hostname. The AP doesn't do DHCP, as all clients get their addresses from the Router. Everything is in a single subnet and the Router IP is set as the DNS server and the Gateway on the AP so the AP should be able to get hostnames from the Router. At least that's what I would think.
Why, though, does the 'Associated Stations' list on the AP not know the hostnames of the connected devices? At best it shows their IP address as hostname but often it only has a question mark.
I just 'unsolved' this as it turns out that it's not fully solved.
Disabling that Filter Private option means that the two IPv4 addresses are now resolved to a name but I still have a bunch of question marks and a hole bunch of fe80: addresses in the Associated Stations list instead of their hostnames.
There doesn't seem to be much of a pattern. One of the hosts that is resolved is an iPhone with an IPv4 address whereas one of the question marks is also an iPhone with an IPv4 address. Both resolve just fine in an nslookup from one of the attached clients so the DNS server is working and knows both hosts.
The fe80 addresses are link local ipv6 addresses. They are automatically generated based on the mac address of the interface, hence the dhcp server doesn't know anything about them and therefore cannot update the hosts file. What you could try is to add them manually in /etc/config/dhcp or in Luci under Network/Hostnames.
I have added those two addresses to the hosts file. It's a bit of a kludge but it works, at least Link Local addresses are stable. It's odd though that some devices are only listed by the Link Local address and not by their IPv4 address whereas as others are listed by their hostname+IPv4+LinkLocal. I have yet to find a pattern.
Any idea what's going on with those question mark host names?
I am not using the wireless functionality of OpenWrt, so I am not able to investigate any further.
My guess is it doesn't know the IP that the host has. Try to ping from the dumbAP these particular stations and see if it changes.
To do a nslookup, it should know the address first. But since it is a dumbAP, it doesn't participate in the dhcp packet exchange in any other way but forwarding the frames. Therefore it doesn't know addresses unless there is some way of communication.
Check the packages arpwatch, addrwatch, and arp-scan. Maybe they can help in automatically adding new stations in the list correctly.
Thanks, I'm working with addrwatch now. It does seem to find the hosts when started from the command line but so far it doesn't have any effect on the Associated Stations list. I need to find out how to get the right process to notice the results. Anything that addrwatch finds does not end up in the ARP cache.
Also, I've discovered why one of the iPhones does show up under its hostname and the other doesn't. I had used that iPhone to visit the web interface so obviously it got recognised as a client (and hostname). Doh!
I am trying to solve this without requiring any additional packages (and arpwatch, addrwatch, and arp-scan did not seem to work).
What I have found so far is that doing a basic ping sweep:
for i in $(seq 1 254); do ping -W1 -c1 -t 1 192.168.1.$i; done
on the local LAN works well. When devices show up in the sweep they get put in the ARP cache and that makes them show up in Associated Stations.
The challenge I haven't solved yet is that the ARP cache only holds a few dozen hosts (and even non-existent IPs are added to the ARP cache) so as the sweep progresses through the 254 addresses the earlier ones get removed again.
I now need to find a way to only have live hosts end up in the ARP cache or extend the size of the ARP cache to 255 hosts.
You could reduce the range of the scan to a smaller part of the network.You won't serve more than 20 clients on a single AP anyway.
You could omit from scanning IPs that will not connect to this AP or that are outside of the DHCP range.
Sorry for the late reply but I just added a second AP and had the same problem. Here's a more efficient fping recipe which runs faster and doesn't blow the arp cache:
I added a cron job to run this every 15 minutes. Note that as of 19.07.5, arp-scan 1.9.5 is broken; you'll need to install arp-scan 1.9.7 from snapshot (https://downloads.openwrt.org/snapshots/packages/$OPENWRT_ARCH/packages/arp-scan_1.9.7-1_$OPENWRT_ARCH.ipk).
