<div dir="ltr">Thanks, for the explanation. <div><br></div><div>That change doesn't make my life any easier though. Now I can't match the session on the origin any more since my strings turned from <b>'</b>TCAU-DSLAM-01 eth 1/1/05/37' to 0x544341552d44534c414d2d30312065746820312f312f30352f3337.<div><br></div><div>I guess for now I'll override this with my own dictionary, since I know that what our vendor supplies in this field is in fact an ASCII string.</div></div><div><br></div><div>kind regards</div><div>Pshem</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 October 2014 08:52, Alan DeKok <span dir="ltr"><<a href="mailto:aland@deployingradius.com" target="_blank">aland@deployingradius.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Pshem Kowalczyk wrote:<br>
> I've noticed that encoding of these two attributes:<br>
><br>
> ADSL-Agent-Circuit-Id<br>
> ADSL-Agent-Remote-Id<br>
><br>
> has been changed from string to octets (from 3.0.3 to 3.0.4), when the<br>
> RFC (4679) states them as strings:<br>
<br>
</span>  The RFC "string" type is binary octets.  Read RFC 2865.<br>
<span class=""><br>
> What was the reason for the change?<br>
<br>
</span>  The original RFCs didn't distinguish between printable strings and<br>
binary data.<br>
<br>
  FreeRADIUS uses "strings" for printable strings, and "octets" for<br>
binary data.  Because I made that change before the RFCs were fixed.<br>
<br>
  The RFCs use "text" for printable strings and "string" for binary<br>
data.  But they use "octets" everywhere to *refer* to binary data.<br>
<br>
  It's annoying.<br>
<span class="HOEnZb"><font color="#888888"><br>
  Alan DeKok.<br>
</font></span><div class="HOEnZb"><div class="h5">-<br>
List info/subscribe/unsubscribe? See <a href="http://www.freeradius.org/list/users.html" target="_blank">http://www.freeradius.org/list/users.html</a><br>
</div></div></blockquote></div><br></div>