Relayed dhcp packets should be kept as is, validation and proper generation should be up to the server.
So, only radius part needs handling.
Yes, douple loop over radius attrs might seem to be suboptimal from the first look, but it was done intentionally.
There can be multiple array radius attributes in any order, so if use preallocated buffers for gathering the data, it would be somewhat unknown how many buffers is required, worst case ~40 (known) * max buff size. Taking into accoung default buf size 4k (can be radius packet size, okay), we need 160k in worst case or ~20k in best case (512 max size for dhcp options).
Still too much for static/dynamic allocation per session.
So, doube loop 1) allows get rid from buffers 2) is faster than moving dhcp option data & structs pointers, I believe.
As improvement, it's possible to teach dhcp reply generation func to gather suboptions instead and move obsolete dhcp options free from the clone function into dhcp packet destructor.
Feel need to a short explanation here.
Relayed dhcp packets should be kept as is, validation and proper generation should be up to the server. So, only radius part needs handling.
Yes, douple loop over radius attrs might seem to be suboptimal from the first look, but it was done intentionally. There can be multiple array radius attributes in any order, so if use preallocated buffers for gathering the data, it would be somewhat unknown how many buffers is required, worst case ~40 (known) * max buff size. Taking into accoung default buf size 4k (can be radius packet size, okay), we need 160k in worst case or ~20k in best case (512 max size for dhcp options). Still too much for static/dynamic allocation per session. So, doube loop 1) allows get rid from buffers 2) is faster than moving dhcp option data & structs pointers, I believe.
As improvement, it's possible to teach dhcp reply generation func to gather suboptions instead and move obsolete dhcp options free from the clone function into dhcp packet destructor.