Re: Freeradius 2.2.0 - binaries not being installed ???
On 05/09/2013 22:31, Alan Buxey wrote: But if you'd installed the debian/Ubuntu package version then it is 'freeradius' ;) alan Indeed, and that was the source of my problem. I had spent the best part of the day troubleshooting the older Ubuntu packaged version. So when I threw in the towel and uninstalled it and compiled from source, I didn't realise that FreeRadius's real name was not freeradius ;-) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Get errors with radtest on ip address
etc/hosts file below : 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.17.9 linux-mail.amber.com linux-mail From: Alan Buxey a.l.m.bu...@lboro.ac.uk To: Patricia Julien pljulie...@yahoo.com; FreeRadius users mailing list freeradius-users@lists.freeradius.org Sent: Thursday, September 5, 2013 5:36 PM Subject: Re: Get errors with radtest on ip address No problem with radiusd at this point. It's not received a single packet. You've got a problem with your local network environment on the host. Care to share /etc/hosts? alan- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Segmentation Fault on [pap] Normalizing SSHA1-Password from base64 encoding
Hi, I'm getting the same errors as these messages: http://lists.freeradius.org/pipermail/freeradius-devel/2013-May/008046.html http://lists.freeradius.org/pipermail/freeradius-users/2013-May/066440.html I also did everything that Stefan Winter did - gdb live server, valgrind, look at the source, compare with 3.0 - and got the same results. In the -devel thread Alan DeKok says there won't be any patches or development on the 2.2.x branch anymore, and I tested with 3.0 with success. So I ask: is there any way to backport the fix to 2.2.x branch? I don't know C very well but if it's not so hard, I might try talking to people who knows how to code and create a unnoficial patch. I saw that the base64 is now using a brave new approach on 3.0. And also, if keeping this bug forever in the 2.2.x branch, what is, in your opinions, the best way to store the encrypted passwords? I'm using SSHA-Passwords attribute, salted with the uuidgen command. And I was thinking, if I use a salt with only 16 characters instead of 32+, is there any chance for this bug to happen? It'll be easier for me to fix the salts instead of the code. I can't migrate to 3.0 right now because the system is in production state. (Please, don't say Cleartext-Passwords are the solution :P) The following hash generates the crash: 42A9cqWnI8QAyQLsy7+iZDNKkrwzYzZlMjFiMC00YWFlLTQyN2QtOTdlNC0zNjIyYTZmYjhjNDk= Thanks! -- []'s Hugo www.devin.com.br - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[ANN] Version 3.0.0-rc1
We are in feature freeze for 3.0. The configuration format and behaviour for
3.0 will be stable between now and the final release (as it was with
release_3_0_0_rc0).
If you are planning on deploying 3.0 and have an existing 2.x.x configuration
you were planning to migrate when the 3.0 is released, now would be a good time
to try that, and to report any issues or problematic behavior changes you
notice.
To provide a single point to test against, the release_3_0_0_rc1 tag has been
created.
Behaviour changes since release_3_0_0_rc0:
* Fixed many more compiler warnings.
* LDAP schemas to load dynamic clients from LDAP
* the control socket is now marked stable
* Added RFC 6929 dictionary, along with a few others
* Clean up proxy ID allocation / re-allocation
* pairbasicfree() has been replaced by talloc_free()
* Added %{debug_attr:LIST} to print out at attributes in LIST
* The PAP module can now configurably *not* normalize passwords
* Remove support for %{#}, and add %{strlen:} expansion
Bug fixes:
* Corrected more documentation to match the new behavior and config
* Corrected many minor typos and spelling mistakes in documentation
and config files
* If the installation directory exists, don't re-install files
* add crlDistributionPoints to certificates for Windows phones.
* Use documentation IP addresses everywhere (192.0.2/24)
* Build fixes for clang related to the -rdynamic flag
* Allow update sections to update outer.reply
* Re-write module handler to work, the code is significantly cleaner,
and priority overrides work correctly in all cases, #404, #424
* CUI SQL fixes, #412
* Don't die in RB tree re-allocation of proxy ID
* Do a second pass over pre-compiled conditions, #421, #423
* Add delete order to rbtree, #416
Also used by the proxy ID re-allocation code
* Fixed TCP socket close handlers to be simpler and more robust
* Allow ${..} expansion in `strings`
* moved EAP destructors to talloc, which wasn't done in -rc0
* Fix LDAP group comparisons, and other pair comparisons
* NULL terminate strings copied between VALUE_PAIRs correctly
* Fix !* when used with non-string attributes
* Fix `` exec in update sections
* Load libpython within rlm_python to ensure all required symbols are available
* Don't SEGV printing IPv6 Interface ID
* Don't SEGV evaluating dates in rlm_expiration
* Fix ./configure --with-shared-libs=no
* Fix crashes related to opaque request data and regular expressions
* Fix heimdal krb5 build
The tarball is available here:
https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_rc1.tar.gz
Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Segmentation Fault on [pap] Normalizing SSHA1-Password from base64 encoding
Hi, http://lists.freeradius.org/pipermail/freeradius-devel/2013-May/008046.html http://lists.freeradius.org/pipermail/freeradius-users/2013-May/066440.html I also did everything that Stefan Winter did - gdb live server, valgrind, look at the source, compare with 3.0 - and got the same results. In the -devel thread Alan DeKok says there won't be any patches or development on the 2.2.x branch anymore, and I tested with 3.0 with success. So I ask: is there any way to backport the fix to 2.2.x branch? I don't know C very well but if it's not so hard, I might try talking to people who knows how to code and create a unnoficial patch. I saw that the base64 is now using a brave new approach on 3.0. And also, if keeping this bug forever in the 2.2.x branch, what is, in your opinions, the best way to store the encrypted passwords? I'm using SSHA-Passwords attribute, salted with the uuidgen command. And I was thinking, if I use a salt with only 16 characters instead of 32+, is there any chance for this bug to happen? It'll be easier for me to fix the salts instead of the code. I can't migrate to 3.0 right now because the system is in production state. (Please, don't say Cleartext-Passwords are the solution :P) You should read the (entire!) thread on -devel titled 2.x.x (and earier?): yet another decoding SSHA issue during which at some point the 2.x.x branch code got fixes for the bulk of the issue. This will be in 2.2.1; but you can safely grab current branch, it's running stable on my production systems for a long time now. The fix still needs config changes with a bit of a hackish workaround - read the thread til the end to get all the goodness. Greetings, Stefan Winter The following hash generates the crash: 42A9cqWnI8QAyQLsy7+iZDNKkrwzYzZlMjFiMC00YWFlLTQyN2QtOTdlNC0zNjIyYTZmYjhjNDk= Thanks! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: [ANN] Version 3.0.0-rc1
I shall try a RHEL6/CentOS6 compatible build tomorrow or Monday.
Shouldn't be a problem. John D, I'll update my tag, you guys will probably do
the same.
Regards
Stefan
From: freeradius-users-bounces+stefan.paetow=diamond.ac...@lists.freeradius.org
[freeradius-users-bounces+stefan.paetow=diamond.ac...@lists.freeradius.org] on
behalf of Arran Cudbard-Bell [a.cudba...@freeradius.org]
Sent: Friday, September 06, 2013 4:55 PM
To: FreeRadius users mailing list
Subject: [ANN] Version 3.0.0-rc1
We are in feature freeze for 3.0. The configuration format and behaviour for
3.0 will be stable between now and the final release (as it was with
release_3_0_0_rc0).
If you are planning on deploying 3.0 and have an existing 2.x.x configuration
you were planning to migrate when the 3.0 is released, now would be a good time
to try that, and to report any issues or problematic behavior changes you
notice.
To provide a single point to test against, the release_3_0_0_rc1 tag has been
created.
Behaviour changes since release_3_0_0_rc0:
* Fixed many more compiler warnings.
* LDAP schemas to load dynamic clients from LDAP
* the control socket is now marked stable
* Added RFC 6929 dictionary, along with a few others
* Clean up proxy ID allocation / re-allocation
* pairbasicfree() has been replaced by talloc_free()
* Added %{debug_attr:LIST} to print out at attributes in LIST
* The PAP module can now configurably *not* normalize passwords
* Remove support for %{#}, and add %{strlen:} expansion
Bug fixes:
* Corrected more documentation to match the new behavior and config
* Corrected many minor typos and spelling mistakes in documentation
and config files
* If the installation directory exists, don't re-install files
* add crlDistributionPoints to certificates for Windows phones.
* Use documentation IP addresses everywhere (192.0.2/24)
* Build fixes for clang related to the -rdynamic flag
* Allow update sections to update outer.reply
* Re-write module handler to work, the code is significantly cleaner,
and priority overrides work correctly in all cases, #404, #424
* CUI SQL fixes, #412
* Don't die in RB tree re-allocation of proxy ID
* Do a second pass over pre-compiled conditions, #421, #423
* Add delete order to rbtree, #416
Also used by the proxy ID re-allocation code
* Fixed TCP socket close handlers to be simpler and more robust
* Allow ${..} expansion in `strings`
* moved EAP destructors to talloc, which wasn't done in -rc0
* Fix LDAP group comparisons, and other pair comparisons
* NULL terminate strings copied between VALUE_PAIRs correctly
* Fix !* when used with non-string attributes
* Fix `` exec in update sections
* Load libpython within rlm_python to ensure all required symbols are available
* Don't SEGV printing IPv6 Interface ID
* Don't SEGV evaluating dates in rlm_expiration
* Fix ./configure --with-shared-libs=no
* Fix crashes related to opaque request data and regular expressions
* Fix heimdal krb5 build
The tarball is available here:
https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_rc1.tar.gz
Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
This e-mail and any attachments may contain confidential, copyright and or
privileged material, and are for the use of the intended addressee only. If you
are not the intended addressee or an authorised recipient of the addressee
please notify us of receipt by returning the e-mail and do not use, copy,
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not
necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments
are free from viruses and we cannot accept liability for any damage which you
may sustain as a result of software viruses which may be transmitted in or with
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and
Wales with its registered office at Diamond House, Harwell Science and
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Segmentation Fault on [pap] Normalizing SSHA1-Password from base64 encoding
On Fri, Sep 6, 2013 at 3:57 PM, Stefan Winter stefan.win...@restena.lu wrote:
So I ask: is there any way to backport the fix to 2.2.x branch? I
don't know C very well but if it's not so hard, I might try talking to
people who knows how to code and create a unnoficial patch. I saw that
the base64 is now using a brave new approach on 3.0.
You should read the (entire!) thread on -devel titled
2.x.x (and earier?): yet another decoding SSHA issue
during which at some point the 2.x.x branch code got fixes for the bulk
of the issue. This will be in 2.2.1; but you can safely grab current
branch, it's running stable on my production systems for a long time now.
That's nice to hear! Thanks! I just tested the 2.x.x branch and it's
working for me.
The fix still needs config changes with a bit of a hackish workaround -
read the thread til the end to get all the goodness.
I tested some of the hashes that were giving me trouble and they all
worked with the current branch version. I also read all the thread,
and some things were not so clear for me (sorry for the noobiness).
Could you explain your final configuration state?
I saw the unlang:
update reply {
SSHA1-Password := 0x%{base64tohex: %{control:RESTENA-SSHA1-Password1}}
}
And the SQL syntax:
SELECT id, username, 'RESTENA-SSHA1-Password', value, op FROM
check_smtp_ssha1 WHERE username='%{SQL-User-Name}
Is these configurations obligatory? I'm using the standard radcheck
table (id,username,attribute,op,value) and query that comes with
freeradius. From what I understood, I need to create a VSA, assign my
SSHA1-Password attribute to it and convert it to hex format using the
unlang and xlat?
Without these extra configuration, the messages from authorization are now:
[pap] login attempt with password senhasecreta
[pap] Using SSHA encryption.
[pap] User authenticated successfully
++[pap] = ok
So the Normalizing error and segmentation fault isn't happening anymore.
Thanks!
[]'s
Hugo
www.devin.com.br
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
