Find IPs of clients connected to bridged interface

Hi,
I am trying to find out how to enumerate IPs of clients connected to bridged interface. I have an wifi interface, which is bridged with particular VLAN. Let's say that our bridge interface is br-vlan11 and does not have any IP assigned. So there are not by any chance arp records for any client in the arp table.
Everything works fine - clients connected to this wifi interface are getting their IP addresse from some upstream DHCP server which belongs to VLAN.
But how can I (from OpenWrt box, do not have access to upstream DHCP server to read assignments) sniff the client's IP by some automated manner?
I can see the IPs in traffic dumped by tcpdump -i br-vlan11, but it does not look like elegant solution to be ran 24/7.
I can also "ping" the devices with arp-scan -I br-vlan11 192.168.11.0/24 but this works only because 1. I know the IP range and 2. the range is not that huge - cannot imagine arp-scanning 16M of 10.0.0.0/8.

Any ideas, how to approach this? Do I really need to dive in some L7 inspection? If so, any guidance, where to start?

Thank you or help.
Robert

Why not?

The problem would be more so that the traffic never passes that ARP table. Nonetheless the APR table keeps track of MACs (Layer 2) anyway.

Yes, to find out Layer 3 IPs on a network which you don't know it's numbering, you would need some Layer 7 method.

Isn't that the risk of scanning any network where you don't know the address range?

  • And actually, if you didn't know the range, you'd have to scan 0.0.0.0/0
  • Also, if you genuinely didn't know the IP range, you won't get a reply from a Layer 3 scanner anyway; so a tool like tcpdump would be necessary

Because the kernel (AFAIK) populates the arp table only with the mac/ip pairs that are relevant to its interfaces. And I think (unsure, but probable) that the arp table is populated only by answers to arp requests initiated from this device, not by any bridge passing traffic. As we are trying to watch L2 traffic and the whole machine does not have even any IPs from the bridge-passing traficc's range, I see no way how the arp table could get those.
EDIT: not sure whether you have asked why not or the post was more-like answer - this point from me was not mentioned as a question, sorry for misunderstanding :slight_smile:

Do you have any direction where to start? The reason I started to ask here was that I would like to avoid any CPU intensive packages, looking for more like simple module that would populate "something like" arp table with traffic passing the bridge...

It wasn't meant that I want to do this - contrary, it was the only simple way I found so far. And wasn't happy with that :slight_smile:

Anyway, thank you for your thoughts.

Is there any reason why you cannot assign an IP address to the bridged interface? Can't you just configure it as just another DCHP client?

1 Like

Two reasons

  1. I don't need it for anything than this and I don't want to pollute the address space. There might be many access points with OpenWrt. Maybe sound silly but it is not a clean way
  2. Of course I tried this approach :slight_smile: The issue was that there is dnsmasq running on this machine to handle other interfaces and whenever I set dhcp to this bridge (and of course used the notinterface option for dnsmasq to ignore the bridged interfaces), the clients were not able to receive any IP address from upstream dhcp server (no traffic passed through, tcpdumped). If I omitted the notinterface option I got error from dnsmasq that there is no ip address for client's dhcp request. When I added the notinterface list, the error vanished but still no dhcp traffic passed the bridge. Either stoppping dnsmasq of setting static with no IP to the bridged interface resolved the issue.

I am aware of that the point 2 may have its solution (it is weird indeed, should work IMHO) but it still does not resolve the point 1 - it is not clean :slight_smile:

Maybe I should elaborate wider picture what am I trying to achieve to put my question into some context:

I am trying to do a WiFi ap management system that is able to give the admin some insight on whats going on in his wifi. The OpenWrt APs may work in two modes (interchangeable and simultaneously for varois SSIDs): SSID might be either NATed and then internal dnsmasq hadles the dhcp and so, or SSID might be bridged (either to LAN or particular VLAN) and in such case (obviously) the dhcp is handled by upstream.
What I want to achieve is to give admin an insight on which clients are connected on each ssid. The data I need are MAC, IP and hostname triplet. Easy to get from the arp table and dhcp.leases in the first case, a pain in the latter.
I omitted the hostname issue from the initial question just not to be too broad. I am looking for approaches or ideas, not expecting any kind of pre-baked solution, even though it would be fine - but the world is not ideal, I know.

Thank you for the time thinking of the problem guys!
Rob

My two cents:

  • Your second point is only an issue if you configure the interface as a DHCP server, not a client. Anyway, you do not want an IP address there, ok.

  • If you only want info about the wireless clients connected to each AP (as you comment on your last post), then you need to look at the wireless information and use it's specific tools. It does not matter that the interface is bridged, if you do not need info about the whole network (as I understood from your first post).

Not sure how can I get the IP and hostname. I am already using iw dev ap0_0 station dump to get the list of mac addresses connected, or did you have something other in mind?

A layer 2 network system only tracks the MAC addresses of the clients since that is all that is necessary for switching operations. If you want to show or log additional client details related to IP address or hostname you have to collect it out of band. The most obvious way would be to integrate with the layer 3 DHCP server upstream. It would also work to intercept and parse DHCP packets.

The kernel ARP table is only populated on a need to know basis -- that is the kernel has had some layer 3 interaction with another machine such as routing its packet at layer 3 or communicating directly to it.

1 Like

To obtain hostnames you need to query a DNS, and you are going to need an IP address for that.

1 Like

There are a variety of ways to log packets from either iptables (standard in openwrt) or nftables (not yet standard but the future of firewalls). You can enable bridge firewalling, and then send say 1% of all packets passing the bridge to an aggregator/analyzer running on a separate machine... keywords to look up are ipfix, sflow, netflow, ulogd2, ntopng and whatnot.

you could use smart switches with the flow/sampler in the switch and aggregate the info at a collector running on a lightweight machine, like an RPi or other small SBC.

Thank you, will probably pursue this path :slight_smile: