0

I have a buildroot embedded Linux where I change the ethernet port settings (i.e. disabled, static or DHCP) from a C++ program. When switching to DHCP, it would be nice to determine when (i.e. timestamp) the device actually gets the DHCP lease.
How can I determine that?

Polling the current IP address and waiting for a chanage is not an option.

4
  • 1
    It depends on the DHCP client used. udhcpc for example can use a hook. Apr 28 at 6:37
  • 1
    And, DHCP client logs all leases to a logfife Apr 28 at 6:42
  • It seems that the device is using udhcpc. udhcpc prints "udhcpc: started, v1.33.1". When switching the port to DHCP, the command udhcpc -t 5 -A 3 -i eth0.1 -x hostname:$(hostname) is executed, and I'm a bit lost, because that doesn't match the man page of the program (e.g. commandlinux.com/man-page/man1/busybox.1.html) How do I find out where that log file is located on my device?
    – Niko O
    Apr 28 at 8:50
  • you could run your uhdcpc with strace, look for the point where you write to a file (which has a fd, i.e., a number), and then look for where you open(at) and get that number. Apr 28 at 9:51

1 Answer 1

1

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.

3
  • "If you're writing a network management framework" I just provide a little settings window in my application (note the "embedded" tag) to "set this device's ethernet port to use DHCP" or "... to use these static settings". Our hardware manufacturer provided us with a script that applies the settings. Among other stuff it does, it executes udhcpc as per my comment. When changing from static to DHCP, it would be nice to see when the device actually gets the lease. They don't know how, so I'm asking here.
    – Niko O
    May 2 at 8:08
  • I failed to mention that the command is udhcpc -t 5 -A 3 -i eth0.1 -x hostname:$(hostname) &> /dev/null & specifically, so udhcpc is put in the background. I can't reasonably change this script. And I don't see how that would help if I plug the device into a different network and get a new lease from there. I was hoping for a solution that avoids changing the existing system. And I'm very surprised that this information isn't just available to query somewhere.
    – Niko O
    May 2 at 8:14
  • Well, that's on your vendor's script then :) The fact that it doesn't log using --syslog AND redirectos to /dev/null instead of a log file basically means "good luck". As said, if that's the case, sniff that DHCP reply packet, parse, be done with it. May 2 at 8:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .