You'd want to run
uhdcpc with the
--quit option, so it quits after obtaining a releases. Check the return value of the programm for != 0 to exclude errors.
The moment it returns successfully, you got your lease.
If you need to run
udhcpc as a daemon (seems strange, you're the one managing the interface, not
udhcpc, so you could just as well renew the lease when it's time manually), I'd honestly just
pcap the appropriate UDP packet, and look inside.
Also, run with
--syslog to at least be able to check when something goes horribly wrong.
Thought: If you're writing a network management framework, you're kind of reinventing the wheel for the millionth time. I'd avoid doing that – doing network configuration has enough corner cases, hostile or hard-to-recover-from situations that you will discover during usage. Other people have solved the same problem before.
To me what you're doing sounds like you're tasked with rewriting
ConnMan, which is meant for exactly this kind of embedded device network control. Its README might be quite interesting, even if just as inspiration for how you write your thing. (ConnMan of course does more than you need, but you can just disable unused features before compilation.)
I'd argue that it does the right thing – the daemon handling DHCP is inherently so tightly coupled to managing the overall network management daemon that they need to either directly talk to each other (as you noticed due to your problem getting lease time and probably also duration!), or be the same process altogether. Have a look at the
connmanctl(1) man page for how an interface to a network control system like you're writing might look like.