DHCP IP assignments and finding AP on network

Software Embedded
1

When using wizard to define device as AP as router, it sets its br0 i/f to be 192.168.1.1. When my client connects halow, it assigns the client’s wlan0 i/f 192.168.1.194.

If I setup the AP as bridge, I have to connect it to a router to get ip assignment, whose dhcp assigns the ap 192.168.1.2, for instance, and the client 192.168.1.3.

I needed the log below for this question, so I started the client running first and waited until its boot process was done so I could see what happens after I turn on the AP (using uart0 debug console). In this case, the AP is router. Then I turn on the AP. The log below is from the client and starts happening after the AP got booted, started the morse driver with sd going. In this process, halow gets connected then the AP tells the client its ip addr which sets wlan0 ipaddr to 192.168.1.194. Similar process happens if AP is bridge and connected to a router, the router assigns the ip addr’s.

In this process, if the AP is router, its ip is defined in the build as 192.168.1.1, so the client can use that when it needs to know the AP’s ip addr. However, if the AP is setup as bridge, is there any way for the client to know the AP’s ip addr?

What problem is trying to be solved: I need the AP and client to run socat. socat on each device needs to know the AP ip addr to setup the connection. Thus, if you could advise on a) how does each the AP and client know what the AP ip addr is when assigned and b) the best place to start socat with that information (and easist way to kill socat process if that happens to already be running), that would be very helpful.

Log of client when AP starts interacting with it to connect halow and set client halow ip addr:

Mon Nov 25 22:15[  778.848568] wlan0: authenticate with 1c:bc:ec:21:64:41
:55 2024 daemon.notice wpa_supplicant_s1g[4230]: wlan0: SME: Trying to authenticate with 1c:bc:ec:21:64:41 (SSID='NSAP1' chan=11)
Mon Nov 25 22:15:55 2024 kern.info kernel: [  778.848568] wlan0: authenticate with 1c:bc:ec:21:64:41
[  779.154268] wlan0: send auth to 1c:bc:ec:21:64:41 (try 1/3)
Mon Nov 25 22:15:55 2024 kern.info kernel: [  779.154268] wlan0: send auth to 1c:bc:ec:21:64:41 (try 1/3)
[  779.268364] wlan0: send auth to 1c:bc:ec:21:64:41 (try 2/3)
Mon Nov 25 22:15:55 2024 kern.info kernel: [  779.268364] wlan0: send auth to 1c:bc:ec:21:64:41 (try 2/3)
[  779.388373] wlan0: send auth to 1c:bc:ec:21:64:41 (try 3/3)
Mon Nov 25 22:15:55 2024 kern.info kernel: [  77[  779.415546] wlan0: authenticated
9.388373] wlan0:[  779.426440] wlan0: waiting for beacon from 1c:bc:ec:21:64:41
 send auth to 1c:bc:ec:21:64:41 (try 3/3)
Mon Nov 25 22:15:55 2[  779.448390] wlan0: associate with 1c:bc:ec:21:64:41 (try 1/3)
024 daemon.notice wpa_supplicant_s1g[4230]: wlan0: Trying to associate with 1c:bc:ec:21:64:41 (SSID='NSAP1' chan=-1)
Mon Nov 25 22:15:55 2024 kern.info kernel: [  779.415546] wlan0: authentic[  779.491711] wlan0: RX AssocResp from 1c:bc:ec:21:64:41 (capab=0x11 status=53 aid=0)
ated
Mon Nov 25[  779.508927] wlan0: 1c:bc:ec:21:64:41 denied association (code=53)
 22:15:55 2024 kern.info kernel: [  779.426440] wlan0: waiting for beacon from 1c:bc:ec:21:64:41
Mon Nov 25 22:15:56 2024 kern.info kernel: [  779.448390] wlan0: associate with 1c:bc:ec:21:64:41 (try 1/3)
Mon Nov 25 22:15:56 2024 kern.info kernel: [  779.491711] wlan0: RX AssocResp from 1c:bc:ec:21:64:41 (capab=0x11 status=53 aid=0)
Mon Nov 25 22:15:56 2024 kern.info kernel: [  779.508927] wlan0: 1c:bc:ec:21:64:41 denied association (code=53)
Mon Nov 25 22:15:56 2024 daemon.notice wpa_supplicant_s1g[4230]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=1c:bc:ec:21:64:41 status_code=53
Mon Nov 25 22:15:56 2024 daemon.notice wpa_supplicant_s1g[4230]: wlan0: PMKSA-CACHE-REMOVED 1c:bc:ec:21:64:41 0
Mon Nov 25 22:15:56 2024 daemon.notice wpa_supplicant_s1g[4230]: morse: disable long sleep on ifname wlan0
Mon Nov 25 22:15[  779.688501] wlan0: authenticate with 1c:bc:ec:21:64:41
:56 2024 daemon.notice wpa_supplicant_s1g[4230]: wlan0: SME: Trying to authenticate with 1c:bc:ec:21:64:41 (SSID='NSAP1' chan=11)
Mon Nov 25 22:15:56 2024 kern.info kernel: [  779.688501] wlan0: authenticate with 1c:bc:ec:21:64:41
[  779.996029] wlan0: send auth to 1c:bc:ec:21:64:41 (try 1/3)
Mon Nov 25 22:15:56 2024 kern.info kernel: [  779.996029] wlan0: send auth to 1c:bc:ec:21:64:41 (try 1/3)
Mon Nov 25 22:15[  780.223331] wlan0: authenticate with 1c:bc:ec:21:64:41
:56 2024 daemon.[  780.235911] wlan0: send auth to 1c:bc:ec:21:64:41 (try 1/3)
notice wpa_supplicant_s1g[4230]: wlan0: SME: Trying to authenticate with 1c:bc:ec:21:64:41 (SSID='NSAP1' chan=11)
Mon Nov 25 22:15:56 2024 kern.info kernel: [  780.223331] wlan0: authenticate with 1c:bc:ec:21:64:41
Mon Nov 25 22:15:56 2024 kern.info kernel: [  780.235911] wlan0: send auth to 1c:bc:ec:21:64:41 (try 1/3)
[  780.312944] wlan0: authenticated
[  780.322223] wlan0: waiting for beacon from 1c:bc:ec:21:64:41
Mon Nov 25 22:15:56 2024 daemon.notice wpa_supplicant_s1g[4230]: wlan0: PMKSA-CACHE-ADDED 1c:bc:ec:21:64:41 0
Mon Nov 25 22:15:56 2024 daemon.notice wpa_supplicant_s1g[4230]: wlan0: Trying to associate with [  780.368354] wlan0: associate with 1c:bc:ec:21:64:41 (try 1/3)
1c:bc:ec:21:64:41 (SSID='NSAP1' chan=-1)
Mon Nov 25 22:15:56 20[  780.392131] wlan0: RX AssocResp from 1c:bc:ec:21:64:41 (capab=0x11 status=0 aid=2)
24 kern.info kernel: [  780.312944] wlan0: authe[  780.414514] wlan0: associated
nticated
Mon Nov 25 22:15:56 2024 kern.info kernel: [  780.322223] wlan0: waiting for beacon from 1c:bc:ec:21:64:41
Mon Nov 25 22:15:56 2024 kern.info kernel: [  780.368354] wlan0: associate with 1c:bc:ec:21:64:41 (try 1/3)
Mon Nov 25 22:15:56 2024 kern.info kernel: [  780.392131] wlan0: RX AssocResp from 1c:bc:ec:21:64:41 (capab=0x11 status=0 aid=2)
Mon Nov 25 22:15:56 2024 kern.info kernel: [  780.414514] wlan0: associated
Mon Nov 25 22:15:56 2024 daemon.notice wpa_supplicant_s1g[4230]: wlan0: Associated with 1c:bc:ec:21:64:41
Mon Nov 25 22:15:56 2024 daemon.notice wpa_supplicant_s1g[4230]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Mon Nov 25 22:15:56 2024 daemon.notice netifd: Network device 'wlan0' link is up
Mon Nov 25 22:15:56 2024 daemon.notice netifd: Interface 'ahwlan' has link connectivity
Mon Nov 25 22:15:56 2024 daemon.notice netifd: Interface 'ahwlan' is setting up now
Mon Nov 25 22:15:56 2024 daemon.notice wpa_supplicant_s1g[4230]: wlan0: WPA: Key negotiation completed with 1c:bc:ec:21:64:41 [PTK=CCMP GTK=CCMP]
Mon Nov 25 22:15:57 2024 daemon.notice wpa_supplicant_s1g[4230]: wlan0: CTRL-EVENT-CONNECTED - Connection to 1c:bc:ec:21:64:41 completed [id=0 id_str=]
Mon Nov 25 22:15:57 2024 daemon.notice netifd: ahwlan (6507): udhcpc: started, v1.36.1
Mon Nov 25 22:15:57 2024 daemon.notice netifd: ahwlan (6507): udhcpc: broadcasting discover
Mon Nov 25 22:15:59 2024 daemon.notice netifd: ahwlan (6507): udhcpc: broadcasting discover
Mon Nov 25 22:16:02 2024 daemon.notice netifd: ahwlan (6507): udhcpc: broadcasting select for 192.168.1.194, server 192.168.1.1
Mon Nov 25 22:16:02 2024 daemon.notice netifd: ahwlan (6507): udhcpc: lease of 192.168.1.194 obtained from 192.168.1.1, lease time 43200
Mon Nov 25 22:16:02 2024 daemon.notice netifd: Interface 'ahwlan' is now up
Mon Nov 25 22:16:02 2024 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Mon Nov 25 22:16:02 2024 daemon.info dnsmasq[1]: using nameserver 192.168.1.1#53
Mon Nov 25 22:16:02 2024 daemon.info dnsmasq[1]: using only locally-known addresses for test
Mon Nov 25 22:16:02 2024 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Mon Nov 25 22:16:02 2024 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Mon Nov 25 22:16:02 2024 daemon.info dnsmasq[1]: using only locally-known addresses for local
Mon Nov 25 22:16:02 2024 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Mon Nov 25 22:16:02 2024 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Mon Nov 25 22:16:02 2024 daemon.info dnsmasq[1]: using only locally-known addresses for privlan
Mon Nov 25 22:16:02 2024 user.notice HOTPLUG: ****** 'ifup' - device:'wlan0' interface:'ahwlan' ******
Mon Nov 25 22:16:03 2024 user.notice firewall: Reloading firewall due to ifup of ahwlan (wlan0)
2

Hi @don.baker

I’ll focus on the core questions, but if you have further questions about the modes and their applications, feel free to ask!

how does each the AP and client know what the AP ip addr is when assigned?

There’s no single “best” solution for doing this, and you’ll either need to perform some form of name resolution, or otherwise some form of service discovery.

What do I mean by this? While not always the case, particularly with some “home” access points (which may just perform dns request forwarding), a network with a central DHCP server may also implement a DNS server. If you can safely assume the network has a DNS server, then you could simply use the hostname of the devices in place of the AP. For example, I can ping the EKH03 on my desk using its hostname.

ping ekh03-68a441
PING ekh03-68a441.lan (192.168.1.100) 56(84) bytes of data.
64 bytes from ekh03-68a441.lan (192.168.1.100): icmp_seq=1 ttl=63 time=3.26 ms

If you can’t safely assume your devices will be attached to networks with DNS servers, then you may want to consider using MDNS. A type of name resolution using multicast traffic, and crossing the boundary of becoming a service discovery protocol - which I find is its primary use. OpenWrt has a small mdns server/client application package which should make this fairly straightforward.

For name resolution, it should be as straightforward as installing the umdns package. Unfortunately the usage documentation is a little difficult, but on my OpenWrt router I can then run

$ ubus call umdns query '{"question":"ekh03-68a441.local","interface":"br-lan","type":1}'
$ ubus call umdns hosts
{
        "DESKTOP-U34D84.local": {
                "ipv6": "fe80::73a1:2ce8:3fe8:2cd1",
                "ipv4": "192.168.1.20"
        },
        "ekh03-68a441.local": {
                "ipv6": "fe80::bad8:12ff:fe68:a441",
                "ipv4": "192.168.1.100"
        }
}

I would personally lean towards MDNS as it can also be used as a form of service discovery, and find more than just a single device. This means you could use it without knowing the name of the other device in advance. See the documentation on the OpenWrt wiki for how to configure that. Again, the interface will be via ubus.
By default, dropbear (the ssh daemon on OpenWrt devices) advertises an ssh service via umdns. So simply browsing for services will dump all services on the network. It looks like there is no filter on this command, unfortunately.

$ ubus call umdns browse
{
        "_ssh._tcp": {
                "ekh03-68a441": {
                        "ipv4": "192.168.1.100",
                        "ipv6": "fe80::bad8:12ff:fe68:a441",
                        "port": 22,
                        "txt": "daemon=dropbear"
                }
        }
}

Then, there are dedicated service discovery protocols, which I won’t go into yet as they may be more complicated than you require.

the best place to start socat with that information (and easist way to kill socat process if that happens to already be running), that would be very helpful.

For this, I would recommend looking at procd services, which I may have mentioned in a previous thread. These have the added benefit of making it really easy to advertise a service via umdns! For example, if you look at /etc/init.d/dropbear which is the ssh service init script, you’ll find the line

procd_add_mdns "ssh" "tcp" "$Port" "daemon=dropbear"

Have a look at [OpenWrt Wiki] Create a sample procd init script for more on creating procd init scripts.
You may not be able to start socat immediately in the init script as both ends need to start the services first to enable discovery before they can connect. You will likely need the service to start a wrapper script which loops on the discovery until it finds a relevant service.

I hope that gives you a good place to start. Feel free to shoot through any procd scripts you form.