dhcp xlat for encoding DHCP options in RADIUS attributes
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. The DHCP-Vendor-URL is transmitted in the RADIUS reply as a standard RADIUS VSA which isn’t useful unfortunately, and the NAS gets a bit confused. To get around that, I’m setting those attributes in control - could strip them out later, but, this seemed less cumbersome. I’ve tried leaving them in the reply, but ERX-Dhcp-Options is still not filled and is of course not transmitted. I can encode this all manually, and doing it by hand once off I do get the effect I’m after, but it’s a bit of a chore as the strings are variable length and of course content, and constructing a TLV structure with xlat by hand seems very fragile, so would rather do this with the purpose built xlat if I can. I have had a bit of a poke around in the code, but VSAs and particularly TLVs are a bit foreign to me. Any guidance about how to use this? Happy to write up some docs for the xlat pages or something once I’ve got a handle on how to use it. Looks like the same xlat is in v4 (at the moment) so would be useful for there too I presume. The documentation (http://networkradius.com/doc/3.0.10/raddb/mods-available/dhcp.html) suggesting it was used with ALu boxes and Juniper, but I wasn’t able to find any examples or discussion other than Peter’s above - and I believe it is slightly outdated now that the dhcp xlat has been implemented along side dhcp_options? Passing DHCP-Vendor-URL, I get an error as mentioned: (6) update control { (6) DHCP-Vendor-URL = "http://blah/" (6) DHCP-Vendor-Pass = "" (6) EXPAND %{string:request:ADSL-Agent-Remote-Id} (6) --> CHORUS1636495896B01 (6) DHCP-Vendor-CPEID = CHORUS1636495896B01 (6) } # update control = noop (6) update reply { (6) ERROR: DHCP option encoding failed: Attribute "DHCP-Vendor-URL" is not a DHCP option (6) EXPAND 0x%{dhcp:control:DHCP-Vendor-URL} (6) --> 0x (6) ERX-DHCP-Options = 0x (6) } # update reply = noop Predictably, this becomes: (6) Sent Access-Accept Id 75 from 10.55.86.243:1812 to 103.241.56.191:55932 length 0 (6) Framed-IP-Address = 100.74.0.69 (6) Reply-Message := "User authenticated - " (6) ERX-Virtual-Router-Name = "default:CustomersNat" (6) Class = 0x61693a3339373463396339613133383737326133313363303335653439383237643432 (6) ERX-Dhcp-Options = 0x And passing 'DHCP-Vendor’: (9) update control { (9) DHCP-Vendor-URL = "http://blah/" (9) DHCP-Vendor-Pass = "" (9) EXPAND %{string:request:ADSL-Agent-Remote-Id} (9) --> CHORUS1636495896B01 (9) DHCP-Vendor-CPEID = CHORUS1636495896B01 (9) } # update control = noop (9) update reply { (9) EXPAND 0x%{dhcp:control:DHCP-Vendor} (9) --> 0x (9) ERX-DHCP-Options = 0x (9) } # update reply = noop Predictably, this becomes: (9) Sent Access-Accept Id 84 from 10.55.86.243:1812 to 103.241.56.191:55932 length 0 (9) Framed-IP-Address = 100.74.0.69 (9) Reply-Message := "User authenticated - " (9) ERX-Virtual-Router-Name = "default:CustomersNat" (9) Class = 0x61693a6261656232323837616639393065366636666239316333623761643536366661 (9) ERX-Dhcp-Options = 0x (9) Finished request -- Nathan Ward
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). -Arran
I wrote it in perl to encode the DHCP Option 43 TLVs. - mods-enabled/perl.dhcpoption43 perl perl.dhcpoption43 { filename = ${modconfdir}/${.:instance}/perlfunc.pl func_authenticate = perlfunc func_authorize = perlfunc } and - mods-config/perl.dhcpoption43/perlfunc.pl sub perlfunc { my $RemoteID = $RAD_REQUEST{'RemoteID'}; my $acsstring = "http://acs:80/cpe.php"; my $PackURL = convert("val" => "1", "string" => $acsstring); my $PackPass = convert("val" => "2", "string" => "voip" ); my $PackRemoteID = convert("val" => "254", "string" => $RemoteID ); my $TotalString = $PackURL . $PackPass . $PackRemoteID; my $PackTotal = pack ("H*",$TotalString); my $FinalString = convert("val" => "43", "string" => $PackTotal); # &radiusd::radlog(1, "DHCP Option 43 Final String : $FinalString"); # Add DHCP options to radius reply $RAD_REPLY{'Alc-ToClient-Dhcp-Options'} = pack ("H*",$FinalString); return RLM_MODULE_OK; } sub convert { my %argv = @_; my $val = sprintf("%02x",$argv{'val'}); my $instring = $argv{'string'}; my $hexstring = unpack ("H*",$instring); my $hexstringlength = sprintf("%02x",length($instring)); my $resultstring = $val . $hexstringlength . $hexstring; return $resultstring } Enjoy Peter On Tue, Mar 6, 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.html 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).
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
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
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.
Could it be the attribute doesn't actually exist in the control list? I just checked the code and it'll parse lists fine. Use debug_control before calling the xlat to double check. Thanks, -Arran
participants (3)
-
Arran Cudbard-Bell -
Nathan Ward -
Peter Lambrechtsen