HEX Stripping using attr_rewrite
Hi Freeradius list :-) I am have a bit of an issue with the stripping hex values from my ADSL-Agent-Remote-ID field in my Auth packet. I am using an Alcatel-Lucent 7750SR platform and for some reason they decided when converting a DHCPv6 packet into a radius packet it appends the Enterprise ID (which is a hex number) into the ADSL-Agent-Remote-ID. I end up with a packet looking like this: User-Name = "MDR-POLT01 eth 1/1/01/01/4/1/1:10" User-Password = "" NAS-IP-Address = 60.xxx.xxx.xxx ADSL-Agent-Circuit-Id = "MDR-POLT01 eth 1/1/01/01/4/1/1:10" ADSL-Agent-Remote-Id = "\000\000\000\001CHORUS1234567894" NAS-Port-Type = Ethernet NAS-Port-Id = "pw-2:1101.104" Calling-Station-Id = "\000\000\000\001CHORUS1234567894" NAS-Identifier = "bng" Acct-Session-Id = "E1F15900F37E74538D434C" The issue I seem to be running into, since \000 is a termination value, that freeradius sees the value of attribute ADSL-Agent-Remote-Id as blank. Example below. [sql] expand: %{Orcon-User-Name} -> : User-Name = "MDR-POLT01 eth 1/1/01/01/4/1/1:10" User-Password = "" NAS-IP-Address = 60.xx.xx.xx ADSL-Agent-Circuit-Id = "MDR-POLT01 eth 1/1/01/01/4/1/1:10" ADSL-Agent-Remote-Id = "\000\000\000\001CHORUS1234567894" NAS-Port-Type = Ethernet NAS-Port-Id = "pw-2:1101.104" Calling-Station-Id = "\000\000\000\001CHORUS1234567894" NAS-Identifier = "bng1" Acct-Session-Id = "E1F15900F40272538D8D8E" +- entering group authorize {...} ++[preprocess] returns ok [suffix] No '@' in User-Name = "MDR-POLT01 eth 1/1/01/01/4/1/1:10", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [files] expand: %{ADSL-Agent-Circuit-Id} -> MDR-POLT01 eth 1/1/01/01/4/1/1:10 ++[files] returns noop [sane_dhcpv6_chorus] expand: \000\000\000\001 -> \000\000\000\001 sane_dhcpv6_chorus: Does not match: ADSL-Agent-Remote-Id = sane_dhcpv6_chorus: Could not find value pair for attribute ADSL-Agent-Remote-Id ++[sane_dhcpv6_chorus] returns ok My attr_rewrite code is: attr_rewrite sane_dhcpv6_chorus { attribute = ADSL-Agent-Remote-Id searchin = packet searchfor = "\\000\\000\\000\\001" replacewith = "" ignore_case = no new_attribute = no max_matches = 10 ## If set to yes then the replace string will be ## appended to the original string append = no } I have raised the issue with the vendor, but I am not holding my breath for a fix anytime soon. Are there any other options in freeradius to get around this?
As per the email I sent to you off-list, this should fix it: if ( ADSL-Agent-Remote-Id =~ /\\001(.*)/ ){ update request { ADSL-Agent-Remote-Id := "%{1}" } } On Wed, Jun 4, 2014 at 12:02 PM, Simon Allard < Simon.Allard@team.orcon.net.nz> wrote:
Hi Freeradius list :-)
I am have a bit of an issue with the stripping hex values from my ADSL-Agent-Remote-ID field in my Auth packet.
I am using an Alcatel-Lucent 7750SR platform and for some reason they decided when converting a DHCPv6 packet into a radius packet it appends the Enterprise ID (which is a hex number) into the ADSL-Agent-Remote-ID.
I end up with a packet looking like this:
User-Name = "MDR-POLT01 eth 1/1/01/01/4/1/1:10" User-Password = "" NAS-IP-Address = 60.xxx.xxx.xxx ADSL-Agent-Circuit-Id = "MDR-POLT01 eth 1/1/01/01/4/1/1:10" ADSL-Agent-Remote-Id = "\000\000\000\001CHORUS1234567894" NAS-Port-Type = Ethernet NAS-Port-Id = "pw-2:1101.104" Calling-Station-Id = "\000\000\000\001CHORUS1234567894" NAS-Identifier = "bng" Acct-Session-Id = "E1F15900F37E74538D434C"
The issue I seem to be running into, since \000 is a termination value, that freeradius sees the value of attribute ADSL-Agent-Remote-Id as blank. Example below.
[sql] expand: %{Orcon-User-Name} -> : User-Name = "MDR-POLT01 eth 1/1/01/01/4/1/1:10" User-Password = "" NAS-IP-Address = 60.xx.xx.xx ADSL-Agent-Circuit-Id = "MDR-POLT01 eth 1/1/01/01/4/1/1:10" ADSL-Agent-Remote-Id = "\000\000\000\001CHORUS1234567894" NAS-Port-Type = Ethernet NAS-Port-Id = "pw-2:1101.104" Calling-Station-Id = "\000\000\000\001CHORUS1234567894" NAS-Identifier = "bng1" Acct-Session-Id = "E1F15900F40272538D8D8E" +- entering group authorize {...} ++[preprocess] returns ok [suffix] No '@' in User-Name = "MDR-POLT01 eth 1/1/01/01/4/1/1:10", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [files] expand: %{ADSL-Agent-Circuit-Id} -> MDR-POLT01 eth 1/1/01/01/4/1/1:10 ++[files] returns noop [sane_dhcpv6_chorus] expand: \000\000\000\001 -> \000\000\000\001 sane_dhcpv6_chorus: Does not match: ADSL-Agent-Remote-Id = sane_dhcpv6_chorus: Could not find value pair for attribute ADSL-Agent-Remote-Id ++[sane_dhcpv6_chorus] returns ok
My attr_rewrite code is: attr_rewrite sane_dhcpv6_chorus { attribute = ADSL-Agent-Remote-Id searchin = packet searchfor = "\\000\\000\\000\\001" replacewith = "" ignore_case = no new_attribute = no max_matches = 10
## If set to yes then the replace string will be ## appended to the original string append = no }
I have raised the issue with the vendor, but I am not holding my breath for a fix anytime soon.
Are there any other options in freeradius to get around this?
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 4 Jun 2014, at 02:25, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
As per the email I sent to you off-list, this should fix it:
if ( ADSL-Agent-Remote-Id =~ /\\001(.*)/ ){ update request { ADSL-Agent-Remote-Id := "%{1}" } }
Um. Maybe... I guess you've tested that?
On Wed, Jun 4, 2014 at 12:02 PM, Simon Allard <Simon.Allard@team.orcon.net.nz> wrote: Hi Freeradius list :-)
I am have a bit of an issue with the stripping hex values from my ADSL-Agent-Remote-ID field in my Auth packet.
I am using an Alcatel-Lucent 7750SR platform
My condolences.
and for some reason they decided when converting a DHCPv6 packet into a radius packet it appends the Enterprise ID (which is a hex number) into the ADSL-Agent-Remote-ID.
*sigh* A way that doesn't rely on FR being \0 safe is to do something like: if ("%{hex:ADSL-Agent-Remote-Id}" =~ /^....([0-9a-f]+)$/) { update request { Tmp-Octets-0 := "0x%{1}" } update request { ADSL-Agent-Remote-ID := "%{string:Tmp-Octets-0}" } } But that's pretty nasty. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
But that's pretty nasty.
I guess we should modify rlm_unpack to take length specifiers and add a char/byte type. That's the nice way to solve this for v3.0.x. It's also generally useful for doing substring extraction when you're really just wanting to pull out an offset/length. Regexes work for that, but they're overkill, and less efficient that just copying the bytes. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
A way that doesn't rely on FR being \0 safe is to do something like:
if ("%{hex:ADSL-Agent-Remote-Id}" =~ /^....([0-9a-f]+)$/) { update request { Tmp-Octets-0 := "0x%{1}" } update request { ADSL-Agent-Remote-ID := "%{string:Tmp-Octets-0}" } }
But that's pretty nasty.
Hi Aaran Thank you for that. You are right, it does look nasty :) I must have missed a step somewhere, as I am seeing this in the debug when using your ulang code. ++++++? if ("%{hex:ADSL-Agent-Remote-Id}" =~ /^....([0-9a-f]+)$/) WARNING: Unknown module "hex" in string expansion "%" There doesn't seem to be a hex loadable module. I am using freeradius 2.1.8 Cheers. Simon
On 5 Jun 2014, at 02:30, Simon Allard <Simon.Allard@team.orcon.net.nz> wrote:
A way that doesn't rely on FR being \0 safe is to do something like:
if ("%{hex:ADSL-Agent-Remote-Id}" =~ /^....([0-9a-f]+)$/) { update request { Tmp-Octets-0 := "0x%{1}" } update request { ADSL-Agent-Remote-ID := "%{string:Tmp-Octets-0}" } }
But that's pretty nasty.
Hi Aaran
Thank you for that. You are right, it does look nasty :)
I must have missed a step somewhere, as I am seeing this in the debug when using your ulang code.
++++++? if ("%{hex:ADSL-Agent-Remote-Id}" =~ /^....([0-9a-f]+)$/) WARNING: Unknown module "hex" in string expansion "%"
There doesn't seem to be a hex loadable module.
Hm, your version of freeradius is too old and doesn't have the %{hex:} expansion. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
On 4 Jun 2014, at 02:25, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
I am have a bit of an issue with the stripping hex values from my ADSL-Agent-Remote-ID field in my Auth packet.
I am using an Alcatel-Lucent 7750SR platform
My condolences.
and for some reason they decided when converting a DHCPv6 packet into a radius packet it appends the Enterprise ID (which is a hex number) into the ADSL-Agent-Remote-ID.
*sigh*
Just for the record: The enterprise ID is a required part of the DHCPv6 Relay Agent Remote-ID, so I don't think you should shoot Alcatel for implementing it like that... See RFC 4649. One could of course question whether an access server translating DHCPv6 requests to RADIUS requests should do some remapping of the attribute, but there is no such requirement in RFC 4679 (which describes the ADSL-Agent-Remote-ID and the other DSL Forum attributes). But with the power of FR unlang I prefer the access servers to do as little preprocessing as possible. Getting the raw values is much much better than having each access server vendor implement their own buggy idea of how some attribute should be formatted. Bjørn
On 17 Jun 2014, at 11:33, Bjørn Mork <bjorn@mork.no> wrote:
Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
On 4 Jun 2014, at 02:25, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
I am have a bit of an issue with the stripping hex values from my ADSL-Agent-Remote-ID field in my Auth packet.
I am using an Alcatel-Lucent 7750SR platform
My condolences.
and for some reason they decided when converting a DHCPv6 packet into a radius packet it appends the Enterprise ID (which is a hex number) into the ADSL-Agent-Remote-ID.
*sigh*
Just for the record: The enterprise ID is a required part of the DHCPv6 Relay Agent Remote-ID, so I don't think you should shoot Alcatel for implementing it like that... See RFC 4649.
I just checked RFC 4679. We have the wrong types in the dictionary. They should be octets types. I'll change for v3.0.x and master, but not for v2.x.x. Guess we really shouldn't be shooting Alcatel then. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
I am using an Alcatel-Lucent 7750SR platform and for some reason they decided when converting a DHCPv6 packet into a radius packet it appends the Enterprise ID (which is a hex number) into the ADSL-Agent-Remote-ID.
it prepends the Enterprise ID from what you've shown :-) alan
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Arran Cudbard-Bell -
Bjørn Mork -
Peter Lambrechtsen -
Simon Allard