encoding of ADSL-Agent-Circuit-Id
Hi, 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: Vendor-Type 1 for Agent-Circuit-Id Vendor-Length <= 65 String and Vendor-Type 2 for Agent-Remote-Id Vendor-Length <= 65 String What was the reason for the change? kind regards Pshem
Because string != text, rfc string is a binary string. The dictionaries were wrong. -Arrab
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.
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@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
On 8 Oct 2014, at 21:20, Pshem Kowalczyk <pshem.k@gmail.com> wrote:
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.
Just use "%{string:ADSL-Agent-Circuit-ID}" as the left hand side of the expression. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Pshem Kowalczyk