A few weeks ago I wrote a practical guide for people running an old Android phone as a camera on a router they cannot log into: Every Guide Says "Reserve the Address on Your Router." What If the Router Is Not Yours?. Its advice boiled down to: read the address off the phone, keep the phone connected, and set a manual address only last.
A reader replied that the static-IP step felt risky if you can't see the whole network, and that the lease-renewal part sounded solid. Both instincts are right, and the reason is in the protocol itself. This is the companion piece: the actual exchange between the phone and the router, read from RFC 2131, with a camera that never moves in mind.
The lease is a clock with three marks on it
When the router lends your phone an address, it lends it for a fixed duration. The phone does not wait for that duration to run out. RFC 2131 gives the client two earlier deadlines:
"T1 is the time at which the client enters the RENEWING state and attempts to contact the server that originally issued the client's network address. T2 is the time at which the client enters the REBINDING state and attempts to contact any server."
And it gives defaults for both:
"T1 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease)."
Those are defaults. The router can send its own values, and the RFC also asks for some random "fuzz" around them so that every device on the network does not renew at the same moment. But the shape is fixed: halfway through, try the router that gave you the address; most of the way through, ask anyone; at the end, let go.
Halfway: the quiet renewal
At T1 the phone sends a single, ordinary request to the router it already knows:
"At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address."
Note what this message is not. It is not "please give me an address." It is "I am already using this one; extend it." If the router answers, the clock starts again, and nothing about the phone's address changes.
If the router does not answer, the phone does not panic. It waits "one-half of the remaining time until T2 (in RENEWING state) and one-half of the remaining lease time (in REBINDING state), down to a minimum of 60 seconds, before retransmitting." It keeps asking, politely, at shrinking intervals.
This is why "keep the phone on the network" works. A device that stays connected starts asking to extend at the halfway mark. It has the entire second half of the lease to get a single yes. A camera that never leaves the room is about the best-behaved DHCP client there is.
The end: when the address really is gone
The failure case is stated just as plainly:
"If the lease expires before the client receives a DHCPACK, the client moves to INIT state, MUST immediately stop any other network processing and requests network initialization parameters as if the client were uninitialized."
From that point the phone is a stranger again. It starts the full request over, and nothing obliges the router to hand back the old address. This is the path that breaks your bookmark, and it needs the phone to have gone the whole second half of the lease without one successful renewal. On a phone that stays connected to a working router, that should not happen.
The other path: rejoining after being away
For a camera that stays put, the riskier moment is not the halfway renewal. It is the phone dropping off — Wi-Fi toggled, a power cut, the router restarting — and then coming back. Rejoining uses a shorter exchange the RFC calls INIT-REBOOT. In it, the "requested IP address" option is a MUST: the phone names the address it had and asks to keep it.
The router has three ways to respond:
- Yes. It sends an acknowledgement and the address is unchanged. This is the common case.
- No. If the phone's idea of its address is wrong, "the server SHOULD send a DHCPNAK message to the client." The phone then has to start over and take whatever it is given.
- Nothing. This is the interesting one. The RFC says: "If the DHCP server has no record of this client, then it MUST remain silent."
Think about what case 3 means for a router that lost its lease table when the power went out. The phone asks for its old address. The router has no record of the phone, so — by the specification — it says nothing at all.
The phone retransmits; the RFC's example is "four times, for a total delay of 60 seconds." Then, if it still hears nothing, "the client MAY choose to use the previously allocated network address and configuration parameters for the remainder of the unexpired lease."
So after a router reboot, the phone is allowed to keep its old address for a while without any router having agreed to it. Often that is harmless, and the address survives. What happens later depends on how that particular router handles the next request, and the RFC leaves room for different implementations there. This is exactly why the anchor article suggests reading the address again after the next real power cut: it is the one situation where your router's behaviour is not predictable from the specification alone.
How the router knows it is the same phone
All of this depends on the router recognising the phone. The RFC says the lease "is implicitly identified by the 'client identifier' or 'chaddr' and the network address." chaddr is the client hardware address.
Modern Android presents a randomized hardware address by default, which sounds as though it should break this. On a normal network it does not, because the default type is persistent per network. The anchor article quotes the Android Open Source Project documentation on that in detail, including the developer setting that changes it. The short version: unless that developer setting is switched on, the phone shows the router the same identity each time, and the requests above work as intended.
Why the manual address is the step to be careful with
DHCP has a conflict check built in. After being given an address, the client "SHOULD perform a check on the suggested address to ensure that the address is not already in use," for example with an ARP request. If the address is taken, "the client MUST send a DHCPDECLINE message to the server," and the server must then "mark the network address as not available."
That check, and the router's bookkeeping, belong to DHCP. When you type an address into the phone's Wi-Fi settings, you leave DHCP for that network. The router's pool does not know you have claimed that address, and DHCP's decline-and-mark step is not part of what happens. If you cannot see the router's pool, you are picking a number without any of the bookkeeping that normally keeps two devices off the same one. That is the reader's instinct, stated in protocol terms.
What to take from it
- A phone that stays connected renews its address from the halfway point of the lease, by unicast, to the same router. Continuous connection is the strongest tool you have that needs nothing from the router.
- The rejoin path is where the address is at risk, not the renewal path, and a router that forgot its table is required to stay silent.
- A manual address gives up DHCP's own conflict handling. Use it last, and only if your two readings show the address really moves.
The practical steps, including the two-reading test, are in the original guide: Every Guide Says "Reserve the Address on Your Router." What If the Router Is Not Yours?
Background Camera RemoteStream records with the screen off, keeps footage on the device rather than in anyone's cloud, and serves a live view from a built-in web server to any browser on your own network.
Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Site: https://superfunicular.com
Sources
- RFC 2131, Dynamic Host Configuration Protocol — R. Droms, March 1997. §4.4.5 (T1/T2, RENEWING, REBINDING, expiry, retransmission), §4.3.2 (INIT-REBOOT; silence when the server has no record), §3.2 (reusing a previous address; retransmission and continued use), §3.1 and §4.4.1 (address-in-use check and DHCPDECLINE), §4.3.3 (server marks a declined address not available).
- MAC randomization behavior — Android Open Source Project, as quoted in the original guide.
Top comments (1)
tr.ee/dev-to