On 10 Dec 2013 17:45, "Patrik Flykt" <<a href="mailto:Patrik.Flykt@linux.intel.com">Patrik.Flykt@linux.intel.com</a>> wrote: > > On Tue, 2013-12-10 at 02:46 +0100, Lennart Poettering wrote: > > > + uint32_t ciaddr; > > > + uint32_t yiaddr; > > > + uint32_t siaddr; > > > + uint32_t giaddr; > > > > Hmmm, why uin32_t? Shouldn't this be32_t? THis is network byte order, > > right? which is just synoymous to big endian... > > > > Or even, if you now use "struct in_addr" elsewhere anyway, why not > > just use that here too? > > be32_t seems reasonable, the 'struct in_addr' was deemed to add slightly > too much cruft without being particularly useful in internal code. What > if we figure out whether this patch set is otherwise reasonable and fix > this and add the remaining parts of DHCP in a coming patch set? > Meanwhile Tom could take the code for an official test spin... Sounds reasonable to me. I'm mostly afk this week, but should be able to get it done next week. Do you have a public got repo I could easily pull from? Cheers, Tom