Will check this later and come back.
I ran the arp-scan on the AP. Below is the output (arp-scan output is edited of course)
OpenWrt SNAPSHOT, r22739-bbc7de3b16
-----------------------------------------------------
root@RT3200_AP:~# arp-scan -qxdlN -I br-lan
RT3200_Router.lan c4:41:1e:
192.168.1.3 b0:be:76:
Thule.lan 10:bf:48:
192.168.1.30 b8:27:eb:
192.168.1.36 30:c6:f7:
192.168.1.67 ac:0b:fb:
192.168.1.68 ac:0b:fb:
192.168.1.69 48:55:19:
Deurbel.lan 20:4e:f6:
192.168.1.70 ac:0b:fb:
TuinhuisCam.lan 00:95:69:
Jack.lan 04:d9:f5:
Gateway02D533.lan b8:2c:a0:
Samsung.lan 54:3a:d6:
Mediabox.lan 88:71:b1:
Nintendo-1.lan 7c:bb:8a:
SqueezeboxRadio.lan 00:04:20:
Kevin-55Q70-2.lan e2:1e:33:
192.168.1.185 d8:8c:79:
Galaxy-S8.lan 24:18:1d:
root@RT3200_AP:~# nslookup 192.168.1.219
Server: 127.0.0.1
Address: 127.0.0.1:53
219.1.168.192.in-addr.arpa name = Galaxy-S8.lan
root@RT3200_AP:~# nslookup 192.168.1.219 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1:53
219.1.168.192.in-addr.arpa name = Galaxy-S8.lan
It seems that the arp-scan works. My Galaxy S8 is assigned the IP 192.168.1.219 and the name is found in both the arp-scan and nslookup.
However, the name is not shown in the overview or wireless screen in Luci.
@Jack007 Everything looks correct so I have no idea why it won't show up in luci for you. 
Same, as SSH command I cant see all the names, but not shown on Luci.
Something is wrong .
There are some ARP related issues on github:
- ARP-requests not being answered on MediaTek-chipsets #11218
- ARP requests are not forwarded to Wifi Client after some time --> devices unreachable #9555
Who knows, maybe one of them is the cause? 
Hello, I was having the same issue with my two dumb AP's and WDS. I was only getting ?.
My DHCP server is on my Opnsense, and I have disabled firewall dnsmasq odhcpd on both AP's.
The solution that fixed it for me was adding a line to /etc/sysctl.conf. I believe this is the same option that is presented in Luci under settings for your bridge, under the name
Honor gratuitous ARP.
When enabled, new ARP table entries are added from received gratuitous APR requests or replies, otherwise only preexisting table entries are updated, but no new hosts are learned.
(I'm unable to change this in Luci, so I had to ssh and edit.)
Login with ssh and edit your /etc/sysctl.conf file. Add this:
# Accept and honor arp on br-lan.
net.ipv4.conf.br-lan.arp_accept=1
Save and exit. Then type
sysctl -p
and see if Luci is resolving IP and names like it should. It might take a few seconds.
I don't know if this works for everyone and every DHCP setup. But maybe it works for you too, without using a script etc.
3 Likes
Continuing on this train of thought, I think we can do even simpler. 
Step 1: Fix in-addr.arpa look-ups
Turns out the reverse DNS queries are just blocked by the "Filter Private" option under DNS settings. If you just uncheck this everything works AFAICT and your upstream private DNS server will respond. Can also delete the /in-addr.arpa/1.2.3.4 forwarder entry since it'll naturally do this unless you need to forward to a different DNS server.
In this case my upstream DNS server is private anyways and this isn't an Internet facing OpenWRT installation as the default is intended for:
Step 2: Fill in the ARP table
Basically two options:
- Use gratuitous ARPs that happen automatically on the network by configuring it on the bridge which seems to be the default (maybe my v23.05-rc3 upgrade had bad state and I had to reset?), see here:
Less preferred, you can addnet.ipv4.conf.br-lan.arp_accept=1to/etc/sysctl.conf(test withsysctl -w net.ipv4.conf.br-lan.arp_accept=1) and just tell the kernel to accept them. This has a minor security implication, but unsolicited ARPs are probably pretty easy to overcome if someone is actually attacking your internal network with ARP spoofing. - Generate traffic periodically using
arp-scanandfping. You'll need to use both becausearp-scanwill find the devices, but since it usesRAWsockets and promiscuous mode, which means it'll by pass the kernel's networking stack and create entries in the ARP table (view withip neigh). This is why people then usefpingto then ping the same device again using the networking stack which generates the ARP entry. This is also why people witharp_accept=1can skip thefpingstep because they are already accepting gratuitous ARPs (see above).
For me personally, I'd rather not wake my sleeping battery powered IoT WiFi devices every few minutes to update a table, so I choose option (1) and don't generate any new traffic and to save battery life and save some RF air time. For security, I assume local network is inherently susceptible to someone doing bad things and depend more on higher level security (TLS) in the event someone ARP spoofs my home network.
Testing
Clear the ARP table which will cause all the host name and IP values to change to ? on reload under Associated Stations:
ip neigh flush all
The entries will then get re-populated via arp_accept, fping, or any standard traffic between the router and station.
May also need to restart dnsmasq if has cached reverse DNS lookups.
4 Likes
Just adding some information about this option. This is the boguspriv that's doing this Reject reverse lookups to private IP ranges where no corresponding entry exists in /etc/hosts. https://openwrt.org/docs/guide-user/base-system/dhcp
From the man page on arch linux: https://man.archlinux.org/man/dnsmasq.8#b,
Bogus private reverse lookups. All reverse lookups for private IP
ranges (ie 192.168.x.x, etc) which are not found in /etc/hosts or
the DHCP leases file are answered with "no such domain" rather
than being forwarded upstream. The set of prefixes affected is
the list given in RFC6303, for IPv4 and IPv6.
But what can we do then, to make it work without disabling this option? I believe this is a useful feature that should be enabled. Am I wrong?
Since openwrt is adding dhcp leases in /tmp/dhcp.leases then the "resolving" part should work? Adding sysctl setting fixed it for me tho, but I'm having some trouble resolving new clients. Hostnames does not show up, until I set a static hostname for the client MAC.
When I used Opnsense it did manage to give me some information, but I'm not sure how Opnsense does the dhcp part.
This is only useful if you're using the OpenWrt router as the main DNS server facing the Internet in which case this is the only DNS server that could answer the queries and every other response not coming from this DNS server must be bogus.
In my case I have a private DNS server upstream already doing this (could be another OpenWrt router with the option enabled). My use case for OpenWrt is to function only as a Wireless AP and bridge traffic from WiFi to my LAN. It does not function as a router and isn't directly connected to the Internet.
Yes it should. But this topic is about a "Dumb AP" in which case we're not running a DHCP or DNS server. It's just a bridge.
You are correct, I forgot. My bad 
Edit: I always disable dnsmasq on my dumb ap's, so I believe step 1 filter private does nothing then.
- I did something slightly different with DNS. I'm not running dnsmasq on my dumb AP at all. Instead, it is simply using my main lan DNS, which has all the reverse lookup info.
- Gratuitous ARPs – thanks, this works great. I only enabled it for wifi bridges. I have a separate management VLAN, where I left it disabled.
1 Like
Sorry for asking in this thread, but can you point to a guide on how to disable dnsmasq on a dumb ap? If I disable it, it can't for instance 'opkg update'...
I usually go to Network/Interfaces, edit my LAN interface, click the last tab named "DHCP Server", and enable the "Ignore Interface" checkbox.
I wouldn't expect this to disable the dnsmasq service, but it stops it from giving out IP addresses.
1 Like
Works for me
Displaying 1-100 of 7235
2 Likes