Josip Rodin wrote:
On Wed, May 09, 2012 at 01:55:10PM +1200, Jasen Betts wrote:
the file /usr/share/freeradius/dictionary.mikrotik
is not included from /usr/share/freeradius/dictionary
This problem is fixed in 2.1.12.
also the file /usr/share/freeradius/dictionary.mikrotik
is missing
Josip Rodin wrote:
To avoid a memory leak, the pointers should be initialized before they
are used. I've committed a change to the v2.1.x branch which fixes this.
This didn't seem to end up in 2.1.12, why is that?
2.1.12 came out before the patch was done. The patch went in on
November
The configuration file for the module, raddb/modules/passwd says:
# hashsize - hashtable size. If 0 or not specified records are not
#stored in memory and file is read on every request.
#This configuration is *not* recommended, as it can be
#very slow. The
Josip Rodin wrote:
That just doesn't seem safe enough when an analogous bit of parsing code in
cf_section_parse() does:
..
and cf_item_parse() can fail, so it stands to reason that *data can
remain unwritten, and should not be free()'d.
The solution is to write to data. The reason is that
Josip Rodin wrote:
% sudo strace freeradius -X
[...]
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 5
getsockname(5, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
::, sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
setsockopt(5, SOL_IPV6, IPV6_PKTINFO, [1], 4) = -1
Josip Rodin wrote:
After a bit more digging, it seems you need a simple:
...
This seems to be so per RFC 3542 from 2003, which obsoletes RFC 2292
from 1998.
Ah... you're using 2.1.10. The git v2.1.x branch already has a
better fix which is cross-platform.
--
To UNSUBSCRIBE, email to
Josip Rodin wrote:
The first test works, but the second doesn't. The second one should actually
work, but the problem is in the definition:
C compilers now have built-in offsetof to fix precisely this problem.
See the attached patch. You'll have to re-run autoconf to
re-generate the
Configuring freeradius to also listen on a IPv6 interface (in this case
::) does not work.
Here is the error message I get when starting freeradius in debug mode:
---
listen {
type = auth
ipv6addr = :: IPv6 address [::]
port = 0
Josip Rodin wrote:
OK, so I tried it, and it actually doesn't work for me. I HUP'ed my FR
server process running since Oct 16, that logrotate had previously rotated
out and cleared out. After the HUP, the /var/log/freeradius/radius.log file
is still zero-sized, while the files used by linelog
Josip Rodin wrote:
Ah, no, here we go. I had stopped and started it again, and then it was able
to tell me:
Thu Nov 11 15:10:24 2010 : Info: Received HUP signal.
Thu Nov 11 15:10:24 2010 : Info: HUP - Re-reading configuration files
Thu Nov 11 15:10:24 2010 : Error: Unable to open file
Josip Rodin wrote:
The server needs to be HUP'd for the log rotation to work. It
previously did *not* re-open the log file on HUP. Now it does.
No, but that's not what I'm saying. Previously it just kept writing the same
file *without* a HUP.
No... it wrote to the same *filename*, but
Josip Rodin wrote:
On Mon, Nov 08, 2010 at 08:16:50AM -0500, Gedalya wrote:
Package: freeradius
Version: 2.1.9+dfsg-1+b1
After logrotate rotates /var/log/freeradius/radius.log, radius.log stays
at 0 size, further logging does not work. This seems to be due to a
change in freeradius.
Josip Rodin wrote:
Hi,
Stephen Gran mentioned to me yesterday that the OpenSSL license exemption
was in the works, that none of the contributors had complained about its
addition.
When can it be made official? :)
I think we should be able to do it for 2.1.8.
Alan DeKok.
--
To
Steve Kemp wrote:
I'd keep it unless there is a significant reason not to - grave
bugs that can't be fixed, etc - I don't regard the gcc test as
a good enough reason to remove it alone.
I've put an updated version on my new web site:
http://deployingradius.com/pscan/
The only thing
14 matches
Mail list logo
