3.0.1 / error in unlang when using attribute 3GPP-IMSI
Hello, I have the following error when I try to use 3GPP-IMSI attribute in unlang : (0) ERROR: %{proxy-reply:3GPP-IMSI} (0) ERROR: ^ Unknown attribute If I hack the dictionary entry 3GPP-IMSI -> X3GPP-IMSI, it works fine. Looks like there is a problem with attributes starting with a digit. Maybe this issue has already been fixed in 3.0.x ? I don't know where to look in the code... Thanks, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On Wed, Mar 12, 2014 at 03:55:31PM +0000, Chaigneau, Nicolas wrote:
I have the following error when I try to use 3GPP-IMSI attribute in unlang :
(0) ERROR: %{proxy-reply:3GPP-IMSI} (0) ERROR: ^ Unknown attribute
If I hack the dictionary entry 3GPP-IMSI -> X3GPP-IMSI, it works fine. Looks like there is a problem with attributes starting with a digit.
Maybe this issue has already been fixed in 3.0.x ? I don't know where to look in the code...
It was fixed a few months ago. Should be in both v3.0.x HEAD and v2.x.x HEAD IIRC. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
OK, thanks! I'll wait for release of 3.0.2, since it is imminent. Regards, Nicolas.
-----Message d'origine----- De : freeradius-devel- bounces+nchaigne=capgemini.fr@lists.freeradius.org [mailto:freeradius- devel-bounces+nchaigne=capgemini.fr@lists.freeradius.org] De la part de Matthew Newton Envoyé : mercredi 12 mars 2014 17:01 À : FreeRadius developers mailing list Objet : Re: 3.0.1 / error in unlang when using attribute 3GPP-IMSI
On Wed, Mar 12, 2014 at 03:55:31PM +0000, Chaigneau, Nicolas wrote:
I have the following error when I try to use 3GPP-IMSI attribute in unlang :
(0) ERROR: %{proxy-reply:3GPP-IMSI} (0) ERROR: ^ Unknown attribute
If I hack the dictionary entry 3GPP-IMSI -> X3GPP-IMSI, it works fine. Looks like there is a problem with attributes starting with a digit.
Maybe this issue has already been fixed in 3.0.x ? I don't know where to look in the code...
It was fixed a few months ago. Should be in both v3.0.x HEAD and v2.x.x HEAD IIRC.
Matthew
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Hello again, I migrated to 3.0.2, but the problem is still here : (0) update control { (0) ERROR: %{proxy-reply:3GPP-IMSI} (0) ERROR: ^ Unknown attribute (0) } # update control = fail (0) } # post-proxy = fail Could you look into this ? Thanks, Nicolas.
-----Message d'origine----- Envoyé : mercredi 12 mars 2014 17:07 À : FreeRadius developers mailing list Objet : RE: 3.0.1 / error in unlang when using attribute 3GPP-IMSI
OK, thanks!
I'll wait for release of 3.0.2, since it is imminent.
Regards, Nicolas.
-----Message d'origine----- Envoyé : mercredi 12 mars 2014 17:01 À : FreeRadius developers mailing list Objet : Re: 3.0.1 / error in unlang when using attribute 3GPP-IMSI
On Wed, Mar 12, 2014 at 03:55:31PM +0000, Chaigneau, Nicolas wrote:
I have the following error when I try to use 3GPP-IMSI attribute in unlang :
(0) ERROR: %{proxy-reply:3GPP-IMSI} (0) ERROR: ^ Unknown attribute
If I hack the dictionary entry 3GPP-IMSI -> X3GPP-IMSI, it works fine. Looks like there is a problem with attributes starting with a digit.
Maybe this issue has already been fixed in 3.0.x ? I don't know where to look in the code...
It was fixed a few months ago. Should be in both v3.0.x HEAD and v2.x.x HEAD IIRC.
Matthew
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
I've fixed this by modifying main/util.c as follows: In function radius_list_name(...): /* * We couldn't determine the list if: * * A colon delimiter was found, but the next char was a * number, indicating a tag, not a list qualifier. * * No colon was found and the first char was upper case * indicating an attribute. * */ q = strchr(p, ':'); //NCH: this is wrong, we may have "proxy-reply:3GPP-IMSI" for instance... //if (((q && (q[1] >= '0') && (q[1] <= '9'))) || // (!q && isupper((int) *p))) { if (!q && isupper((int) *p)) { return unknown; } The comment says "the next char was a number, indicating a tag, not a list qualifier". I don't know what this means. I there a risk this fix breaks something else ?
-----Message d'origine----- De : freeradius-devel- bounces+nchaigne=capgemini.fr@lists.freeradius.org [mailto:freeradius- devel-bounces+nchaigne=capgemini.fr@lists.freeradius.org] De la part de Chaigneau, Nicolas Envoyé : lundi 24 mars 2014 15:33 À : FreeRadius developers mailing list Objet : RE: 3.0.1 & 3.0.2 / error in unlang when using attribute 3GPP- IMSI
Hello again,
I migrated to 3.0.2, but the problem is still here :
(0) update control { (0) ERROR: %{proxy-reply:3GPP-IMSI} (0) ERROR: ^ Unknown attribute (0) } # update control = fail (0) } # post-proxy = fail
Could you look into this ?
Thanks, Nicolas.
-----Message d'origine----- Envoyé : mercredi 12 mars 2014 17:07 À : FreeRadius developers mailing list Objet : RE: 3.0.1 / error in unlang when using attribute 3GPP-IMSI
OK, thanks!
I'll wait for release of 3.0.2, since it is imminent.
Regards, Nicolas.
-----Message d'origine----- Envoyé : mercredi 12 mars 2014 17:01 À : FreeRadius developers mailing list Objet : Re: 3.0.1 / error in unlang when using attribute 3GPP-IMSI
On Wed, Mar 12, 2014 at 03:55:31PM +0000, Chaigneau, Nicolas wrote:
I have the following error when I try to use 3GPP-IMSI attribute in unlang :
(0) ERROR: %{proxy-reply:3GPP-IMSI} (0) ERROR: ^ Unknown attribute
If I hack the dictionary entry 3GPP-IMSI -> X3GPP-IMSI, it works fine. Looks like there is a problem with attributes starting with a digit.
Maybe this issue has already been fixed in 3.0.x ? I don't know where to look in the code...
It was fixed a few months ago. Should be in both v3.0.x HEAD and v2.x.x HEAD IIRC.
Matthew
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
A somewhat better fix which does not break "<attribute>:<tag>": In function radius_list_name(...): q = strchr(p, ':'); if (((q && (q[1] >= '0') && (q[1] <= '9'))) || (!q && isupper((int) *p))) { //NCH: this is wrong, we may have "proxy-reply:3GPP-IMSI" for instance... //return unknown; if ( (q) && (0 != strncmp(q+1, "3GPP", 4)) ) { return unknown; } } It's still bad, though. There should be a way to make this generic (same issue with 3com and 3GPP2 dictionaries).
-----Message d'origine-----
I've fixed this by modifying main/util.c as follows:
In function radius_list_name(...):
/* * We couldn't determine the list if: * * A colon delimiter was found, but the next char was a * number, indicating a tag, not a list qualifier. * * No colon was found and the first char was upper case * indicating an attribute. * */ q = strchr(p, ':'); //NCH: this is wrong, we may have "proxy-reply:3GPP-IMSI" for instance... //if (((q && (q[1] >= '0') && (q[1] <= '9'))) || // (!q && isupper((int) *p))) { if (!q && isupper((int) *p)) { return unknown; }
The comment says "the next char was a number, indicating a tag, not a list qualifier". I don't know what this means. I there a risk this fix breaks something else ?
-----Message d'origine----- De : freeradius-devel- bounces+nchaigne=capgemini.fr@lists.freeradius.org [mailto:freeradius- devel-bounces+nchaigne=capgemini.fr@lists.freeradius.org] De la part de Chaigneau, Nicolas Envoyé : lundi 24 mars 2014 15:33 À : FreeRadius developers mailing list Objet : RE: 3.0.1 & 3.0.2 / error in unlang when using attribute 3GPP- IMSI
Hello again,
I migrated to 3.0.2, but the problem is still here :
(0) update control { (0) ERROR: %{proxy-reply:3GPP-IMSI} (0) ERROR: ^ Unknown attribute (0) } # update control = fail (0) } # post-proxy = fail
Could you look into this ?
Thanks, Nicolas.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Hello, There is an issue with 3.0.2 rlm_perl.c When I try to access the hash value pair lists in the perl script, I've got complete garbage. For instance (output produced by Dumper):
'User-Name' [ 'query=proxy-stat"@DªàCª@Dª ×ag1 °Kª@Dª0!×aàCªPKªP ×aº1 °KªÞþ0!×a Á@@;×a$c ("°KªhDª@DªhDª°Kª¸KªÀÀ¥1,,îøh= àyÑ}©Çh=,ðÑ}FëÈ93p z® sñÉ93÷zá °Y~`N ±ªP îøh=ðÑ}p z®÷zá ~AòÉ93ûþÈ93÷zá ðÑ}@«¡Ë93 "3pþ Hk¥Ú} {á ðÑ} {á ~{á þÊ930 ZÅ93{á ',
(...) I checked the differences between 3.0.1 code. In function perl_store_vps, I reverted the following lines to prior code: Line 633: //av_push(av, newSVpv(buffer, truncate_len(len, sizeof(buffer)))); //NCH:fix. av_push(av, newSVpv(buffer, len)); Line 643: //(void)hv_store(rad_hv, name, strlen(name), newSVpv(buffer, truncate_len(len, sizeof(buffer))), 0); //NCH fix: (void)hv_store(rad_hv, name, strlen(name), newSVpv(buffer, len), 0); Now it works again. Seems there's an issue with truncate_len, or how it's used. Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Chaigneau, Nicolas wrote:
When I try to access the hash value pair lists in the perl script, I've got complete garbage. For instance (output produced by Dumper):
I've pushed a fix which reverts the "truncate_len" changes to rlm_perl. Please test it. We'll investigate other ways of achieving the same goal. Alan DeKok.
Thanks. I've tested the fix to rlm_perl.c, it works. Thanks also for the fix to util.c for 3GPP, I'll test it tomorrow. Regards, Nicolas.
-----Message d'origine----- De : freeradius-devel- bounces+nicolas.chaigneau=capgemini.com@lists.freeradius.org [mailto:freeradius-devel- bounces+nicolas.chaigneau=capgemini.com@lists.freeradius.org] De la part de Alan DeKok Envoyé : lundi 24 mars 2014 17:57 À : FreeRadius developers mailing list Objet : Re: 3.0.2 / new bug in rlm_perl.c - perl script gets garbage in hv lists
Chaigneau, Nicolas wrote:
When I try to access the hash value pair lists in the perl script, I've got complete garbage. For instance (output produced by Dumper):
I've pushed a fix which reverts the "truncate_len" changes to rlm_perl. Please test it.
We'll investigate other ways of achieving the same goal.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On 24 Mar 2014, at 17:30, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
Thanks.
I've tested the fix to rlm_perl.c, it works.
Ok, i've pushed the proper fix, can you make sure that's ok too. The other one, whilst fixing the symptoms, would still allow a buffer overflow if the returned value from vp_prints_value() was > 1023 bytes. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hello, I don't see your fix, it seems rlm_perl.c was simply reverted to the previous version in 3.0.x branch ?
-----Message d'origine----- Objet : Re: 3.0.2 / new bug in rlm_perl.c - perl script gets garbage in hv lists
On 24 Mar 2014, at 17:30, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
Thanks.
I've tested the fix to rlm_perl.c, it works.
Ok, i've pushed the proper fix, can you make sure that's ok too.
The other one, whilst fixing the symptoms, would still allow a buffer overflow if the returned value from vp_prints_value() was > 1023 bytes.
-Arran
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On 25 Mar 2014, at 09:13, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
Hello,
I don't see your fix, it seems rlm_perl.c was simply reverted to the previous version in 3.0.x branch ?
Unsurprisingly, it was the one just before the commit which reverts Alan's commit https://github.com/FreeRADIUS/freeradius-server/commit/a4f60a57ac1a47f818480... Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
OK, I reverted to using truncate_len in rlm_perl, with this version of libradius.h. It works fine now. Regards, Nicolas.
-----Message d'origine----- Objet : Re: 3.0.2 / new bug in rlm_perl.c - perl script gets garbage in hv lists
On 25 Mar 2014, at 09:13, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
Hello,
I don't see your fix, it seems rlm_perl.c was simply reverted to the previous version in 3.0.x branch ?
Unsurprisingly, it was the one just before the commit which reverts Alan's commit
https://github.com/FreeRADIUS/freeradius- server/commit/a4f60a57ac1a47f818480b10a4e73009bbe0ae1a
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On 26 Mar 2014, at 09:11, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
OK, I reverted to using truncate_len in rlm_perl, with this version of libradius.h.
It works fine now.
Thanks for confirming. -Arran
I've tested the fix, it works. Thanks again. Regards, Nicolas.
-----Message d'origine----- De : freeradius-devel- bounces+nchaigne=capgemini.fr@lists.freeradius.org [mailto:freeradius- devel-bounces+nchaigne=capgemini.fr@lists.freeradius.org] De la part de Alan DeKok Envoyé : lundi 24 mars 2014 17:44 À : FreeRadius developers mailing list Objet : Re: 3.0.1 & 3.0.2 / error in unlang when using attribute 3GPP- IMSI
Chaigneau, Nicolas wrote:
A somewhat better fix which does not break "<attribute>:<tag>":
I've pushed a fix, and added regression tests for 3GPP attributes.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Chaigneau, Nicolas -
Matthew Newton