Alan T. DeKok [Tue, 27 Mar 2018 19:03:38 +0000 (15:03 -0400)]
clean up dynamic client expiry
- we now have idle_timeout, not lifetime
- this is because dynamic clients can't be connected (for now)
- simplify and unify the "clean up packet" code
- don't have an "expired" flag in the socket.
- don't have an "expired" flag in the client.
- track client->outstanding only for dynamic clients
- decrement client->outstanding only when the packet is cleaned up
nchaigne [Mon, 26 Mar 2018 18:24:44 +0000 (20:24 +0200)]
A few fixes in fr_dhcpv4_packet_decode
1) Options 26 and 57 are short => use vp_uint16
2) Field "opcode" is byte => use vp_uint8
3) Value 3 does not exist for field "Opcode". Client request is 1.
Option 63 should have been 60 (Vendor Class Identifier).
That said, I don't think this "MSFT 98" code ever worked - unless MS does some really weird stuff with DHCP. So maybe it's worth considering removing this altogether ? I'll let you decide. :)
Matthew Newton [Sat, 24 Mar 2018 23:59:14 +0000 (23:59 +0000)]
Correctly nul-terminated empty strings have length 1
This would trip up regex compares where the subcapture didn't
match anything, so had length 0. Then trying to assign it to an
attribute the RHS was FR_TYPE_INVALID as fr_value_box_strsteal
exited early and never set it to FR_TYPE_STRING.
Alan T. DeKok [Sat, 24 Mar 2018 17:50:02 +0000 (13:50 -0400)]
iline number is not order.
The "users" file may have multiple $INCLUDES.
We DON'T want a "user" entry at line 266 of "$INCLUDE 1" to conflict
with a "DEFAULT" entry at line 266 of "$INCLUDE 2".
So we add an "order", which tracks the entry number. The "lineno"
is no longer used for ordering comparisons. Instead, it's only
used for debugging.
If values need to be zero padded they should be fed into the padding expansions
It's not ok to mess with the underlying data type just to get a particular presentation format.
The whole point of reworking the xlat code to take discreet boxed values is that upstream consumers of the output can use real types to make proper casting and comparison decisions.
By forcing these values to strings there's a high chance that they'll be fed into a lexicographic comparison function instead of the server just using integer comparisons (they would be now anyway, but we're moving towards something better).
nchaigne [Tue, 20 Mar 2018 17:36:41 +0000 (18:36 +0100)]
Do not encode htype and hlen by default for DHCPv4
DHCP fields "htype" and "hlen" should not be encoded to 1 and 6 (respectively) by default.
They don't need to, because they are automatically set if there is an Ethernet address in field "chaddr".
For a Lease Query request, as described in RFC 4388, it is possible to query: 1) by IP address, 2) by MAC address, 3) by Client-identifier option.
In cases 1) and 3) "The values of htype, hlen, and chaddr MUST be set to zero.".
So I think that if no "chaddr" is provided, it's better to leave "htype" and "hlen" to 0.
This proposed pull request implements this change.
Reorganise attribute adding/validation functions and add support for internal dictionary references.
References allow one attribute to internally reference another TLV or a dictionary root.
This allows us to create "group" attributes which allow any attribute to be encoded within the group and foreign protocol attributes which allow RADIUS to be encoded within DHCP (for example).
Attribute references are also needed to mix protocols in the same virtual server, as the template validation functions can retrieve the foreign dictionary context from the talloc hierarchy.