Dumb AP - Associated Stations Resolver

Installing and Using OpenWrt Network and Wireless Configuration
42

Will check this later and come back.

43

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.

image
image951×119 7.77 KB

44

@Jack007 Everything looks correct so I have no idea why it won't show up in luci for you. :frowning:

45

Same, as SSH command I cant see all the names, but not shown on Luci.
Something is wrong .

46

There are some ARP related issues on github:

Who knows, maybe one of them is the cause? :confused:

47

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
48

Continuing on this train of thought, I think we can do even simpler. :thinking: :thinking: :keyboard:

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:

image
image1790×780 77.4 KB

Step 2: Fill in the ARP table

Basically two options:

  1. 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:
    image
    image1343×1113 89.7 KB
    Less preferred, you can add net.ipv4.conf.br-lan.arp_accept=1 to /etc/sysctl.conf (test with sysctl -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.
  2. Generate traffic periodically using arp-scan and fping. You'll need to use both because arp-scan will find the devices, but since it uses RAW sockets and promiscuous mode, which means it'll by pass the kernel's networking stack and create entries in the ARP table (view with ip neigh). This is why people then use fping to then ping the same device again using the networking stack which generates the ARP entry. This is also why people with arp_accept=1 can skip the fping step 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.

3 Likes
49

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.

50

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.

52

You are correct, I forgot. My bad :slightly_smiling_face:

Edit: I always disable dnsmasq on my dumb ap's, so I believe step 1 filter private does nothing then.

53
  1. 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.
  2. Gratuitous ARPs – thanks, this works great. I only enabled it for wifi bridges. I have a separate management VLAN, where I left it disabled.