On 6/03/2018, at 6:33 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Mar 6, 2018, at 9:06 AM, Nathan Ward <lists+freeradius@daork.net> wrote:
Hi,
I did a bit of digging around in the archives, I’m trying to do effectively what Peter was doing in this thread: http://lists.freeradius.org/pipermail/freeradius-devel/2013-April/007974.htm... Actually not effectively, quite literally, for literally the same service offered by the same provider in the same market :)
I am aware of dhcp_options xlat for *decoding* DHCP options. I am looking to encode DHCP options for transmitting to the NAS.
I note that Arran has implemented an xlat called ‘dhcp’ since then, looks like it’s based on discussions from that thread, but I’m not sure how it should be used. I’ve defined some attributes similar to the thread above, but with the ‘dot notation’ format rather than the ‘BEGIN TLV’ type format. Additionally, I changed the type of ‘DHCP-Vendor’ to ‘tlv’. It was set to “octets # tlv”.. which I’m not sure how to interpret, but FreeRADIUS refused to start when it was set to that as the sub options expect it to be a TLV, which seems reasonable. This is in my dictionary.dhcp, in amongst everything else - the first lines is modified as I describe above, the others are new. ATTRIBUTE DHCP-Vendor 43 tlv ATTRIBUTE DHCP-Vendor-URL 43.1 string ATTRIBUTE DHCP-Vendor-Pass 43.2 string ATTRIBUTE DHCP-Vendor-CPEID 43.253 string
If I do ‘ERX-Dhcp-Options = “0x%{dhcp:DHCP-Vendor-URL}”’ after setting DHCP-Vendor-URL, it tells me that it’s not a DHCP option, and I get an empty option. If I try set it to “0x%{dhcp:DHCP-Vendor}”, it gets set to empty, and it doesn’t get transmitted in the RADIUS packet. I have also tried things like %{dhcp:&DHCP-Vendor} and so on, but same result.
You have the usage right, but the options need to be defined inside the DHCP dictionary (share/dictionary.dhcp) inside the vendor block. The vendor block was a hack to avoid implementing protocol specific dictionaries (which are a lot of effort).
Hi Arran, I’ve got a couple of different syntaxes there - which is best - or are all OK? A) ERX-Dhcp-Options = "0x%{dhcp:DHCP-Vendor-URL}%{dhcp:DHCP-Vendor-Pass}" B) ERX-Dhcp-Options = "0x%{dhcp:DHCP-Vendor}" C) ERX-Dhcp-Options = "0x%{dhcp:&DHCP-Vendor-URL}%{dhcp:&DHCP-Vendor-Pass}" D) ERX-Dhcp-Options = "0x%{dhcp:&DHCP-Vendor}” (A and C I’ve extrapolated a bit from the above, to what I presume is required for multiple options in one field, based on the original discussion for this feature in the referenced thread) Re. The dictionary, that’s where I’ve got it.. if I understand what you mean by vendor block - I replaced the original DHCP-Vendor line with the above, and put the TLVs in immediately below it… so with a few lines of context above and below I’ve got: VENDOR DHCP 54 format=2,1 BEGIN-VENDOR DHCP … deleted lines ... ATTRIBUTE DHCP-NIS-Domain-Name 40 string ATTRIBUTE DHCP-NIS-Servers 41 ipaddr array ATTRIBUTE DHCP-NTP-Servers 42 ipaddr array # N Vendor Specific Information ATTRIBUTE DHCP-Vendor 43 tlv ATTRIBUTE DHCP-Vendor-URL 43.1 string ATTRIBUTE DHCP-Vendor-Pass 43.2 string ATTRIBUTE DHCP-Vendor-CPEID 43.253 string ATTRIBUTE DHCP-NETBIOS-Name-Servers 44 ipaddr array ATTRIBUTE DHCP-NETBIOS-Dgm-Dist-Servers 45 ipaddr array ATTRIBUTE DHCP-NETBIOS-Node-Type 46 byte … deleted lines … END-VENDOR DHCP <eof> What I’ve found, is that I get a not a DHCP attribute error if I try: ERX-Dhcp-Options = "0x%{dhcp:control:DHCP-Vendor-URL}” But not if I try: ERX-Dhcp-Options = "0x%{dhcp:DHCP-Vendor-URL}” OR ERX-Dhcp-Options = "0x%{dhcp:control:DHCP-Vendor}” Obviously, I set them in the relevant correct places before these lines. I don’t understand why this is the case - it only seems like it doesn’t like control being there if it’s the TLV attributes, but the top level TLV works fine.. very odd. You know what though, as I’m going through looking at this now, it looks as though this particular server is on 3.0.13, so let me correct that embarrassing oversight and get back you… Looking at the diffs between 3.0.13 and 3.0.16 I don’t see much difference related to this, but… let’s find out for sure. -- Nathan Ward