dhcp_options xlat with ERX-Dhcp-Options
Howdy This is a bit of a -users question rather than -devel but the rlm_dhcp is still proto but I am trying to figure out the best approach to my current issue. I've seen this mail thread: https://lists.freeradius.org/pipermail/freeradius-devel/2012-November/007267... I am trying to take a Radius Request from a Juniper MX which is receiving a DHCP request from the CPE including Option 82 Circuit & Remote IDs in the request. It comes through in the Juniper VSA 55 ERX-Dhcp-Options as a big octet stream something like this. 3501013d07010019c7f9fbdf3c0c64736c666f72756d2e6f72673902024037090103060c0f1c2a2b4252350121574e2d504f4c5430312065746820312f312f30312f30352f352f31342f313a3130021043484f52555331363334353637383935 The ADSL RFC attributes are at the end: 52350121574e2d504f4c5430312065746820312f312f30312f30352f352f31342f313a3130 Option 82, Length 35 Type 01 length 21 Circuit ID: And end out with: WN-POLT01 eth 1/1/01/05/5/14/1:10 Then the Remote ID 02 length 10 021043484f52555331363334353637383935 CHORUS1634567895 I was then looking to map them to the RFC 4679 attributes ADSL-Agent-Circuit-Id and ADSL-Agent-Remote-Id. Then I need to return the ACS Vendor Specific Information DHCP Option 43 with the ACS TR-069 URL and a few other variables. Something like this: 2b360128687474703a2f2f7369702e636f6e6669672e636f2e6e7a3a383038302f6f70656e6163732f616373020455535231fe0455535231 With 01 being the ACS URL, and 02 as USR1 and 254 also as USR1 variables I need to return I suspect I may need to fully re-write the PROTO_DHCP module to get it to complie without too much drama onto FreeRadius 2.1.12 as that's the version we are running due to it being supported by RHEL 6.3. Or hack it with a rlm_perl script. Any suggestions on the best way to manipulate the octet string? Cheers Peter
I suspect I may need to fully re-write the PROTO_DHCP module to get it to complie without too much drama onto FreeRadius 2.1.12 as that's the version we are running due to it being supported by RHEL 6.3. Or hack it with a rlm_perl script.
V2 head also has the xlat function, see xlat.c. Bundle it and its dependencies in a new module if you're intent on using 2.1.12.
Any suggestions on the best way to manipulate the octet string?
Regex with capture groups. Binary attributes get converted to hex strings for the purpose of regex. When you assign a hex string (prefixed with 0x) to an attribute of type octets FreeRADIUS will do the conversion for you. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On Mon, Apr 15, 2013 at 8:45 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
I suspect I may need to fully re-write the PROTO_DHCP module to get it
to complie without too much drama onto FreeRadius 2.1.12 as that's the version we are running due to it being supported by RHEL 6.3. Or hack it with a rlm_perl script.
V2 head also has the xlat function, see xlat.c. Bundle it and its dependencies in a new module if you're intent on using 2.1.12.
Cheers, I have managed to hack something together which seems to work, and I am getting the decode I expect after I modified the dictionary.dhcp to have the DHCP-Relay-Circuit-Id and DHCP-Relay-Remote-Id to be string rather than octet. ++[files] returns ok DHCP-Message-Type += DHCP-Discover DHCP-Client-Identifier += 00:19:c7:f9:fb:df DHCP-Vendor-Class-Identifier += "dslforum.org" DHCP-DHCP-Maximum-Msg-Size += 576 DHCP-Parameter-Request-List += DHCP-Subnet-Mask DHCP-Parameter-Request-List += DHCP-Router-Address DHCP-Parameter-Request-List += DHCP-Domain-Name-Server DHCP-Parameter-Request-List += DHCP-Hostname DHCP-Parameter-Request-List += DHCP-Domain-Name DHCP-Parameter-Request-List += DHCP-Broadcast-Address DHCP-Parameter-Request-List += DHCP-NTP-Servers DHCP-Parameter-Request-List += DHCP-Vendor DHCP-Parameter-Request-List += DHCP-TFTP-Server-Name DHCP-Relay-Circuit-Id = "WN-POLT01 eth 1/1/01/05/5/14/1:10" DHCP-Relay-Remote-Id = "CHORUS1634567895" expand: %{dhcp_options:ERX-Dhcp-Options} -> 15 ++[request] returns ok Which is brilliant :) Now I just need to figure out how to re-encode into the hex string from the TLVs of Option 43.
Any suggestions on the best way to manipulate the octet string?
Regex with capture groups. Binary attributes get converted to hex strings for the purpose of regex. When you assign a hex string (prefixed with 0x) to an attribute of type octets FreeRADIUS will do the conversion for you.
I think this may be the only way. Ideally I would like to reverse what the decode is doing, and be able to set TLV VSAs and have the regex preform the opposite. But my c fu isn't that strong so I am going to hunt down someone who may be able to help. IE going from: DHCP-Vendor-ACS = "http://sip.config.co.nz:8080/openacs/acs" DHCP-Vendor-User = "USR1" DHCP-Vendor-Password = "USR1" With this in the dictionary.dhcp: # N Vendor Specific Information ATTRIBUTE DHCP-Vendor 43 tlv BEGIN-TLV DHCP-Vendor ATTRIBUTE DHCP-Vendor-ACS 1 string ATTRIBUTE DHCP-Vendor-User 2 string ATTRIBUTE DHCP-Vendor-Password 254 string END-TLV DHCP-Vendor Using something like: update reply { ERX-Dhcp-Options := "%{encode_dhcp_options:DHCP-Vendor-ACS,DHCP-Vendor-User,DHCP-Vendor-Password}" } Or just specify the top level VSA so the encode knows to take all the TLVs underneath so: update reply { ERX-Dhcp-Options := "%{encode_dhcp_options:DHCP-Vendor}" } Would suffice and end up with something like: ERX-Dhcp-Options := 0x2b360128687474703a2f2f7369702e636f6e6669672e636f2e6e7a3a383038302f6f70656e6163732f616373020455535231fe0455535231 That would be handy :)
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 15 Apr 2013, at 00:59, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
On Mon, Apr 15, 2013 at 8:45 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
I suspect I may need to fully re-write the PROTO_DHCP module to get it to complie without too much drama onto FreeRadius 2.1.12 as that's the version we are running due to it being supported by RHEL 6.3. Or hack it with a rlm_perl script.
V2 head also has the xlat function, see xlat.c. Bundle it and its dependencies in a new module if you're intent on using 2.1.12.
Cheers, I have managed to hack something together which seems to work, and I am getting the decode I expect after I modified the dictionary.dhcp to have the DHCP-Relay-Circuit-Id and DHCP-Relay-Remote-Id to be string rather than octet.
You can use %{string:} to expand a binary attribute to a string. They're octets because that's what the RFCs say they should be.
++[files] returns ok DHCP-Message-Type += DHCP-Discover DHCP-Client-Identifier += 00:19:c7:f9:fb:df DHCP-Vendor-Class-Identifier += "dslforum.org" DHCP-DHCP-Maximum-Msg-Size += 576 DHCP-Parameter-Request-List += DHCP-Subnet-Mask DHCP-Parameter-Request-List += DHCP-Router-Address DHCP-Parameter-Request-List += DHCP-Domain-Name-Server DHCP-Parameter-Request-List += DHCP-Hostname DHCP-Parameter-Request-List += DHCP-Domain-Name DHCP-Parameter-Request-List += DHCP-Broadcast-Address DHCP-Parameter-Request-List += DHCP-NTP-Servers DHCP-Parameter-Request-List += DHCP-Vendor DHCP-Parameter-Request-List += DHCP-TFTP-Server-Name DHCP-Relay-Circuit-Id = "WN-POLT01 eth 1/1/01/05/5/14/1:10" DHCP-Relay-Remote-Id = "CHORUS1634567895" expand: %{dhcp_options:ERX-Dhcp-Options} -> 15 ++[request] returns ok
Which is brilliant :)
Yeah it's a fun hack.
Ideally I would like to reverse what the decode is doing, and be able to set TLV VSAs and have the regex preform the opposite. But my c fu isn't that strong so I am going to hunt down someone who may be able to help.
IE going from:
DHCP-Vendor-ACS = "http://sip.config.co.nz:8080/openacs/acs" DHCP-Vendor-User = "USR1" DHCP-Vendor-Password = "USR1"
With this in the dictionary.dhcp:
# N Vendor Specific Information ATTRIBUTE DHCP-Vendor 43 tlv BEGIN-TLV DHCP-Vendor ATTRIBUTE DHCP-Vendor-ACS 1 string ATTRIBUTE DHCP-Vendor-User 2 string ATTRIBUTE DHCP-Vendor-Password 254 string END-TLV DHCP-Vendor
Using something like:
update reply { ERX-Dhcp-Options := "%{encode_dhcp_options:DHCP-Vendor-ACS,DHCP-Vendor-User,DHCP-Vendor-Password}" }
Or just specify the top level VSA so the encode knows to take all the TLVs underneath so:
update reply { ERX-Dhcp-Options := "%{encode_dhcp_options:DHCP-Vendor}" }
Would suffice and end up with something like:
ERX-Dhcp-Options := 0x2b360128687474703a2f2f7369702e636f6e6669672e636f2e6e7a3a383038302f6f70656e6163732f616373020455535231fe0455535231
That would be handy :)
The best way to do it would probably be "0x%{dhcp_option:<attribute ref>}%{dhcp_option:<attribute ref>}". There are examples of xlats processing attribute references in xlat.c, you could probably just snprintf fields from the VP to the buffer as hex. vp->attribute ~> code (DHCP and RADIUS both use 8bit attribute/option identifiers) vp->length ~> length vp->vp_octets ~> data You may need specific encoding for some options, but I think the ones you're interested in should be ok. -Arran
On Tue, Apr 16, 2013 at 8:59 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On 15 Apr 2013, at 00:59, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
On Mon, Apr 15, 2013 at 8:45 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
I suspect I may need to fully re-write the PROTO_DHCP module to get it
to complie without too much drama onto FreeRadius 2.1.12 as that's the version we are running due to it being supported by RHEL 6.3. Or hack it with a rlm_perl script.
V2 head also has the xlat function, see xlat.c. Bundle it and its dependencies in a new module if you're intent on using 2.1.12.
Cheers, I have managed to hack something together which seems to work, and I am getting the decode I expect after I modified the dictionary.dhcp to have the DHCP-Relay-Circuit-Id and DHCP-Relay-Remote-Id to be string rather than octet.
You can use %{string:} to expand a binary attribute to a string. They're octets because that's what the RFCs say they should be.
Cheers, that works fine for what I am looking to do. Seems a bit strange that RFC 4679 for the ADSL-Agent-Remote-ID does specify string, whereas RFC 3046 for the DHCP-Agent-Remote-ID is octets... How silly is that :) But I am now working fine with the %{string: to convert the octet value.
++[files] returns ok DHCP-Message-Type += DHCP-Discover DHCP-Client-Identifier += 00:19:c7:f9:fb:df DHCP-Vendor-Class-Identifier += "dslforum.org" DHCP-DHCP-Maximum-Msg-Size += 576 DHCP-Parameter-Request-List += DHCP-Subnet-Mask DHCP-Parameter-Request-List += DHCP-Router-Address DHCP-Parameter-Request-List += DHCP-Domain-Name-Server DHCP-Parameter-Request-List += DHCP-Hostname DHCP-Parameter-Request-List += DHCP-Domain-Name DHCP-Parameter-Request-List += DHCP-Broadcast-Address DHCP-Parameter-Request-List += DHCP-NTP-Servers DHCP-Parameter-Request-List += DHCP-Vendor DHCP-Parameter-Request-List += DHCP-TFTP-Server-Name DHCP-Relay-Circuit-Id = "WN-POLT01 eth 1/1/01/05/5/14/1:10" DHCP-Relay-Remote-Id = "CHORUS1634567895" expand: %{dhcp_options:ERX-Dhcp-Options} -> 15 ++[request] returns ok
Which is brilliant :)
Yeah it's a fun hack.
Ideally I would like to reverse what the decode is doing, and be able to set TLV VSAs and have the regex preform the opposite. But my c fu isn't that strong so I am going to hunt down someone who may be able to help.
IE going from:
DHCP-Vendor-ACS = "http://sip.config.co.nz:8080/openacs/acs" DHCP-Vendor-User = "USR1" DHCP-Vendor-Password = "USR1"
With this in the dictionary.dhcp:
# N Vendor Specific Information ATTRIBUTE DHCP-Vendor 43 tlv BEGIN-TLV DHCP-Vendor ATTRIBUTE DHCP-Vendor-ACS 1 string ATTRIBUTE DHCP-Vendor-User 2 string ATTRIBUTE DHCP-Vendor-Password 254 string END-TLV DHCP-Vendor
Using something like:
update reply { ERX-Dhcp-Options := "%{encode_dhcp_options:DHCP-Vendor-ACS,DHCP-Vendor-User,DHCP-Vendor-Password}" }
Or just specify the top level VSA so the encode knows to take all the TLVs underneath so:
update reply { ERX-Dhcp-Options := "%{encode_dhcp_options:DHCP-Vendor}" }
Would suffice and end up with something like:
ERX-Dhcp-Options := 0x2b360128687474703a2f2f7369702e636f6e6669672e636f2e6e7a3a383038302f6f70656e6163732f616373020455535231fe0455535231
That would be handy :)
The best way to do it would probably be "0x%{dhcp_option:<attribute ref>}%{dhcp_option:<attribute ref>}".
There are examples of xlats processing attribute references in xlat.c, you could probably just snprintf fields from the VP to the buffer as hex.
vp->attribute ~> code (DHCP and RADIUS both use 8bit attribute/option identifiers) vp->length ~> length vp->vp_octets ~> data
You may need specific encoding for some options, but I think the ones you're interested in should be ok.
I'm still working on how best I can hack this... I suspect perl may be an easier & more supportable option. Thanks for all your help :)
On 04/14/2013 10:56 AM, Peter Lambrechtsen wrote:
to complie without too much drama onto FreeRadius 2.1.12 as that's the version we are running due to it being supported by RHEL 6.3.
FWIW I think this is a misguided approach. We run RHEL and use their supported packages where appropriate, but where we need a newer version of the package (FreeRADIUS, bind, exim, etc.) we build it ourselves. You don't *have* to use their packages, but if you insist on doing so, you should harrass *them* to backport fixes you need - you are, after all, paying them for this service.
On 15/04/13 09:20, Phil Mayers wrote:
On 04/14/2013 10:56 AM, Peter Lambrechtsen wrote:
to complie without too much drama onto FreeRadius 2.1.12 as that's the version we are running due to it being supported by RHEL 6.3.
FWIW I think this is a misguided approach. We run RHEL and use their supported packages where appropriate, but where we need a newer version of the package (FreeRADIUS, bind, exim, etc.) we build it ourselves.
You don't *have* to use their packages, but if you insist on doing so, you should harrass *them* to backport fixes you need - you are, after all, paying them for this service.
Sorry, just to clarify - you should *also* harass RedHat. It's fine to ask here, but it's important that paying customers give suppliers feedback as to their needs.
On Mon, Apr 15, 2013 at 10:23 PM, Phil Mayers <p.mayers@imperial.ac.uk>wrote:
On 15/04/13 09:20, Phil Mayers wrote:
On 04/14/2013 10:56 AM, Peter Lambrechtsen wrote:
to complie without too much drama onto FreeRadius 2.1.12 as that's the
version we are running due to it being supported by RHEL 6.3.
FWIW I think this is a misguided approach. We run RHEL and use their supported packages where appropriate, but where we need a newer version of the package (FreeRADIUS, bind, exim, etc.) we build it ourselves.
You don't *have* to use their packages, but if you insist on doing so, you should harrass *them* to backport fixes you need - you are, after all, paying them for this service.
Sorry, just to clarify - you should *also* harass RedHat. It's fine to ask here, but it's important that paying customers give suppliers feedback as to their needs.
I thoroughly agree with you bugging RedHat. I've already had a few patches applied and supported by RH, so this will just be another one. I also agree that we should build and run the latest and greatest stable release. However our change management and operational support folks look on that somewhat differently than I do. Once FR has been in place in production for a bit longer and has a proven track record in my employer then I am sure they will see it differently. It's just when you're trying to get through production readyness gates and end to end solution designs get reviewed sometimes tough questions get asked. RH were more than happy when I gave the patches on a plate including their updated RPM spec file that builds fine to add it into their supported version.
participants (3)
-
Arran Cudbard-Bell -
Peter Lambrechtsen -
Phil Mayers