The problem is that we would like to be able to detect if there is more than one DHCP server on the lan handing out ip addresses. Today the unum agent captures DHCP request packets to help us fingerprint a device. It should be possible using that as an example to add a function to capture DHCP offer packets and pass those to the server for analysis. This exercise will allow you to build the unum agent for a particular target - the gl.inet router and add functionality based on a rudimentary understanding of how the dhcp network protocol works. This will give you a sense of what it is like working in our code base and solving network based problems in our agent/server architecture.
Bonus: Does this new code belong in the fingerprinting section? How would you reorganize the DHCP packet capture utility and where would you put it given this new functionality?
Capture the DHCP offer packets using a packet processing entry callback and persist that information in a DHCP information table to be sent with other device telemetry upon a configurable interval, clearing the table as needed.
The current pull request is incomplete and contains comments in the code indicating as such. The current functionality is only satisfying some of the problem statement's requirements, indicated as completed with an check below:
- Capture DHCP offer packets
- Log to stdout or file
- Detect if there is more than one DHCP server on the LAN
- Move functionality to more appropriate space
Notes on the general approach that was taken with respect to the problem statement.
The first part of any project undertaking is to gather information. I began by resisting the urge to dive directly into the code and instead ensured I had the necessary information to successfully implement the challenge. This included things such as skimming RFCs for relevant information, understanding the DHCP protocol negotiation, and gathering information about the hardware spec I was building for.
Continuing to resist the urge to write or read code, ensuring there is a proper working baseline of functionality to progress from or return to is essential to testing and examining changes. I spent a tremendous amount of time in this area of the challenge for a number of reasons:
- General unfamiliarity with the GL.Inet1300
- Complications trying to reset and flash OpenWrt on device
- Build instructions and proper process steps were unclear
- Version on device versus developer version differed
- Building only packages changes vs. entire OpenWrt stack
- Could not run the process in the foreground (still an issue)
- Could not run the tests (still an issue)
The last two bullets are the most unfortunate of the list, as these are the most straight forward ways of establishing a functional baseline. That being said, there were alternative ways of establishing a feedback loop, i.e. logging to a file, thus debugging the foreground and test mode issues were time boxed.
Once the build and installation work flow was established, it was finally time to start writing some code. Given I had not written C in any production system I started by following function executions through the code base. It was nice to have a pointer on where to look for DHCP packets as 'fingerprinting' would not have been my first guess.
After reading through things I then attempted to merely replicate the logging mechanisms provided by the macros in the http section, given I could not get the proc to run in the foreground. Once I was able to log some information I needed a way to garner feedback and did so by renewing various device's DHCP leases. From there, I was then able to build, deploy, and examine changes.
Overall, this is a perfect challenge and I thoroughly enjoyed diving into it. I would offer the following as merely suggestions for improvement, should you decide to issue this challenge to others:
What Could be Improved: Consider allowing the candidate to complete the challenge on any of the supported target devices or to build for a currently unsupported platform and offer the GL.Inet b1300 if they do not already own a device to use.
Reasoning: This might help to save debugging issues specific to the device. In the case of this challenge specifically, the version differences between what came on the router and what I built absorbed significant cycles. Also, given the build that was supplied did not include tcpdump (either by built-in or module), it could not be installed via opkg. Maybe it is possible through the UI? Either way, it is not clear for someone unfamiliar with the ecosystem on how to get a package which was not included on to the device and the challenge suggests it's use.
What Could be Improved: External facing documentation could use a bit of attention.
Reasoning: For someone coming to the tools and ecosystem from an unfamiliar space, it is challenging to find the proper way to build and deploy code. Specific to this challenge, it would be nice to have specific build steps for the target and to have known the target system in OpenWrt was (i.e. Qualcomm Atheros IPQ40XX).
What Went Well: There was exposure to the real issues of working in this code base and building changes for devices which is far more representative of day to day employment versus some arbitrary and isolated coding exercise.
What Went Well: I'm significantly more familiar with DHCP protocol now.
What Went Well: Alec and the team were available for questions.