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
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
Nov
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 th
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:
> % 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) =
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 [::]
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:
> 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 linel
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
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 fre
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.
--
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
