This is what I've been trying to say. You as the network admin must manage and keep a list your own static IPs.There's no means for it to do so. The very definition of a static IP is that it is one configured manually into the stations rather than automatically allocated by some protocol.a) Raspberry Pico does not inform router of the use of static IP (set by ifconfig)and router reports a DHCP it used (later overwritten by the Pico setting)
If it somehow picks up static IP hosts then great, but it is by some other means than the usual DHCP protocol.
If you are looking at a client list this implies a client-server relationship. A host with a static IP address is not a client of the DHCP server.
You can have a network with no DHCP server and everything set static. DHCP is new, like 1997 or something, we did not use it before.
If a particular IP address is matched with a particular MAC address in the DHCP lease, it will remain so until the lease expires. This means the router expects that combo until the lease is up. How long are your leases set up for? I'm sure that's why you saw output with one IP set vs. what was "expected" by the DHCP server.
If you really want to know what might be going on with how a Pico does DHCP, turn off DHCP and run DHCP from a different computer and watch the logs in real time. Or, set up an insecure WiFi network and put your WiFi adapter in monitor mode, if it can do that.
https://wiki.wireshark.org/CaptureSetup/WLAN
As root or sudo try the arping command from a Raspberry Pi to a Pico. If you get a reply, then your Raspberry Pi is on the same subnet as your Pico. Below is an example from my Linux PC to my router:
Code:
root@ace:# arping 192.168.1.98ARPING 192.168.1.98 from 192.168.1.174 eth0Unicast reply from 192.168.1.98 [78:24:AF:79:F6:70] 0.883msUnicast reply from 192.168.1.98 [78:24:AF:79:F6:70] 0.794msUnicast reply from 192.168.1.98 [78:24:AF:79:F6:70] 0.754msUnicast reply from 192.168.1.98 [78:24:AF:79:F6:70] 0.784ms^CSent 4 probes (1 broadcast(s))Received 4 response(s)https://www.ietf.org/rfc/rfc2131.txt
Code:
Message Use ------- --- DHCPDISCOVER - Client broadcast to locate available servers. DHCPOFFER - Server to client in response to DHCPDISCOVER with offer of configuration parameters. DHCPREQUEST - Client message to servers either (a) requesting offered parameters from one server and implicitly declining offers from all others, (b) confirming correctness of previously allocated address after, e.g., system reboot, or (c) extending the lease on a particular network address. DHCPACK - Server to client with configuration parameters, including committed network address. DHCPNAK - Server to client indicating client's notion of network address is incorrect (e.g., client has moved to new subnet) or client's lease as expired DHCPDECLINE - Client to server indicating network address is already in use. DHCPRELEASE - Client to server relinquishing network address and cancelling remaining lease. DHCPINFORM - Client to server, asking only for local configuration parameters; client already has externally configured network address. Table 2: DHCP messages Server Client Server (not selected) (selected) v v v | | | | Begins initialization | | | | | _____________/|\____________ | |/DHCPDISCOVER | DHCPDISCOVER \| | | | Determines | Determines configuration | configuration | | | |\ | ____________/ | | \________ | /DHCPOFFER | | DHCPOFFER\ |/ | | \ | | | Collects replies | | \| | | Selects configuration | | | | | _____________/|\____________ | |/ DHCPREQUEST | DHCPREQUEST\ | | | | | | Commits configuration | | | | | _____________/| | |/ DHCPACK | | | | | Initialization complete | | | | . . . . . . | | | | Graceful shutdown | | | | | |\ ____________ | | | DHCPRELEASE \| | | | | | Discards lease | | | v v v Figure 3: Timeline diagram of messages exchanged between DHCP client and servers when allocating a new network addressStatistics: Posted by breaker — Tue Jan 23, 2024 5:16 am