Open f3rn0s opened 2 months ago
the options are put into a hashmap https://github.com/bluecatengineering/dhcproto/blob/master/src/v4/options.rs#L158 which does not maintain any ordering of elements, so it's likely that when you write out to a buffer the result is not exactly the same byte for byte between encodes.
You don't need to explicitly add the End
option, it will be written by the library. It's possible that by manually inserting it, the encode is short-circuiting because as I said, the options are iterated at random from the hashmap. If you could try not inserting the End
option, the bytes will still not match but you should see all options written to the buffer. Perhaps we should add a guard so that End
can't be inserted
Is the ordering of options important to you? We could switch to a B-Tree map, which maintains order (an order but not the insert order), but it would be a breaking change I think because some HashMap internals are exposed in various iterators.
I'm using this package to build a DHCP packet that gets sent over the wire. I was observing that the packet would be different over different executions. I'm trying to determine why this is the case. chaddr is always the same.
For example, if I do some testing:
I get:
In my case, I can observe this in wireshark because in some requests MessageType isn't being set: