encoding of ADSL-Agent-Circuit-Id

[Pshem Kowalczyk]

Thanks, for the explanation.

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 *'*TCAU-DSLAM-01
eth 1/1/05/37' to 0x544341552d44534c414d2d30312065746820312f312f30352f3337.

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.

kind regards
Pshem

On 9 October 2014 08:52, Alan DeKok <aland at deployingradius.com> wrote:

> Pshem Kowalczyk wrote:
> > I've noticed that encoding of these two attributes:
> >
> > ADSL-Agent-Circuit-Id
> > ADSL-Agent-Remote-Id
> >
> > has been changed from string to octets (from 3.0.3 to 3.0.4), when the
> > RFC (4679) states them as strings:
>
>   The RFC "string" type is binary octets.  Read RFC 2865.
>
> > What was the reason for the change?
>
>   The original RFCs didn't distinguish between printable strings and
> binary data.
>
>   FreeRADIUS uses "strings" for printable strings, and "octets" for
> binary data.  Because I made that change before the RFCs were fixed.
>
>   The RFCs use "text" for printable strings and "string" for binary
> data.  But they use "octets" everywhere to *refer* to binary data.
>
>   It's annoying.
>
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20141009/a1b1b227/attachment.html>