<div class="gmail_quote">On Tue, Apr 16, 2013 at 8:59 AM, Arran Cudbard-Bell <span dir="ltr"><<a href="mailto:a.cudbardb@freeradius.org" target="_blank">a.cudbardb@freeradius.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 15 Apr 2013, at 00:59, Peter Lambrechtsen <<a href="mailto:peter@crypt.co.nz">peter@crypt.co.nz</a>> wrote:<br>
<br>
> On Mon, Apr 15, 2013 at 8:45 AM, Arran Cudbard-Bell <<a href="mailto:a.cudbardb@freeradius.org">a.cudbardb@freeradius.org</a>> wrote:<br>
> ><br>
> ><br>
> > 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.<br>

> ><br>
><br>
> 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.<br>
><br>
> 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.<br>

<br>
</div>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.<br></blockquote><div><br>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 :)<br>
But I am now working fine with the %{string: to convert the octet value.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> ++[files] returns ok<br>
>         DHCP-Message-Type += DHCP-Discover<br>
>         DHCP-Client-Identifier += 00:19:c7:f9:fb:df<br>
>         DHCP-Vendor-Class-Identifier += "<a href="http://dslforum.org" target="_blank">dslforum.org</a>"<br>
>         DHCP-DHCP-Maximum-Msg-Size += 576<br>
>         DHCP-Parameter-Request-List += DHCP-Subnet-Mask<br>
>         DHCP-Parameter-Request-List += DHCP-Router-Address<br>
>         DHCP-Parameter-Request-List += DHCP-Domain-Name-Server<br>
>         DHCP-Parameter-Request-List += DHCP-Hostname<br>
>         DHCP-Parameter-Request-List += DHCP-Domain-Name<br>
>         DHCP-Parameter-Request-List += DHCP-Broadcast-Address<br>
>         DHCP-Parameter-Request-List += DHCP-NTP-Servers<br>
>         DHCP-Parameter-Request-List += DHCP-Vendor<br>
>         DHCP-Parameter-Request-List += DHCP-TFTP-Server-Name<br>
>         DHCP-Relay-Circuit-Id = "WN-POLT01 eth 1/1/01/05/5/14/1:10"<br>
>         DHCP-Relay-Remote-Id = "CHORUS1634567895"<br>
>         expand: %{dhcp_options:ERX-Dhcp-Options} -> 15<br>
> ++[request] returns ok<br>
><br>
> Which is brilliant :)<br>
<br>
</div>Yeah it's a fun hack.<br>
<div class="im"><br>
> 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.<br>

><br>
> IE going from:<br>
><br>
>         DHCP-Vendor-ACS = "<a href="http://sip.config.co.nz:8080/openacs/acs" target="_blank">http://sip.config.co.nz:8080/openacs/acs</a>"<br>
>         DHCP-Vendor-User = "USR1"<br>
>         DHCP-Vendor-Password = "USR1"<br>
><br>
> With this in the dictionary.dhcp:<br>
><br>
> # N Vendor Specific Information<br>
> ATTRIBUTE       DHCP-Vendor                             43      tlv<br>
> BEGIN-TLV       DHCP-Vendor<br>
> ATTRIBUTE       DHCP-Vendor-ACS                         1       string<br>
> ATTRIBUTE       DHCP-Vendor-User                        2       string<br>
> ATTRIBUTE       DHCP-Vendor-Password                    254     string<br>
> END-TLV         DHCP-Vendor<br>
><br>
><br>
> Using something like:<br>
><br>
>         update reply {<br>
>                 ERX-Dhcp-Options := "%{encode_dhcp_options:DHCP-Vendor-ACS,DHCP-Vendor-User,DHCP-Vendor-Password}"<br>
>         }<br>
><br>
> Or just specify the top level VSA so the encode knows to take all the TLVs underneath so:<br>
><br>
>         update reply {<br>
>                 ERX-Dhcp-Options := "%{encode_dhcp_options:DHCP-Vendor}"<br>
>         }<br>
><br>
> Would suffice and end up with something like:<br>
><br>
> ERX-Dhcp-Options := 0x2b360128687474703a2f2f7369702e636f6e6669672e636f2e6e7a3a383038302f6f70656e6163732f616373020455535231fe0455535231<br>
><br>
> That would be handy :)<br>
<br>
</div>The best way to do it would probably be "0x%{dhcp_option:<attribute ref>}%{dhcp_option:<attribute ref>}".<br>
<br>
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.<br>
<br>
vp->attribute ~> code (DHCP and RADIUS both use 8bit attribute/option identifiers)<br>
vp->length ~> length<br>
vp->vp_octets ~> data<br>
<br>
You may need specific encoding for some options, but I think the ones you're interested in should be ok.<br></blockquote><div><br>I'm still working on how best I can hack this... I suspect perl may be an easier & more supportable option.<br>
<br>Thanks for all your help :)<br></div></div><br>