On 11 Jul 2006, at 17:00, Alan DeKok wrote:
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
Is there a chance that on a fast loaded box that threads are
accessing the dictionary index which is being dynamically modified
(it would appear) and using non-valid memory for their lookup ?
resulting in
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> Is there a chance that on a fast loaded box that threads are
> accessing the dictionary index which is being dynamically modified
> (it would appear) and using non-valid memory for their lookup ?
> resulting in the value being kept as octet and
On 7 Jul 2006, at 17:46, Alan DeKok wrote:
Are dictionaries loaded each time a child is started? or just once
and then kept in memory?
The server doesn't start any children. The dictionaries are loaded
once, and cached as long as it's running.
Hi,
Have been digging through the source for
On 7 Jul 2006, at 17:46, Alan DeKok wrote:
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
these are hex values, not octal, and it seems to be an intermittent
thing.
Dang. Those bugs are hard to track down.
Yup, looking high and low for correlation
Are dictionaries loaded each time a c
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> these are hex values, not octal, and it seems to be an intermittent
> thing.
Dang. Those bugs are hard to track down.
> Are dictionaries loaded each time a child is started? or just once
> and then kept in memory?
The server doesn't start a
On 6 Jul 2006, at 22:20, Alan DeKok wrote:
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
What would cause FreeRADIUS to output in this manner, we have
summized that if it sees a none ASCII byte in the field it would
convert the whole field into a hex representation to stop trying to
write binar
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> What would cause FreeRADIUS to output in this manner, we have
> summized that if it sees a none ASCII byte in the field it would
> convert the whole field into a hex representation to stop trying to
> write binary to the db.
No, it should prin
On 6 Jul 2006, at 09:58, Graeme Hinchliffe wrote:
On 4 Jul 2006, at 17:01, Alan DeKok wrote:
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
Further to this, I have just noticed that this doesn't seem to just
be restricted to the IP address, but also the Session ID field.
Instead of displaying
On 4 Jul 2006, at 17:01, Alan DeKok wrote:
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
Further to this, I have just noticed that this doesn't seem to just
be restricted to the IP address, but also the Session ID field.
Instead of displaying the session ID as say
020268001A6C-44A618FF
I
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
> Further to this, I have just noticed that this doesn't seem to just
> be restricted to the IP address, but also the Session ID field.
> Instead of displaying the session ID as say
>
> 020268001A6C-44A618FF
>
> I am seeing:
>
> 0x30323032464
On 4 Jul 2006, at 12:05, Graeme Hinchliffe wrote:Hi, I have just (as of yesterday) upgraded FreeRADIUS from 1.0.3 to 1.1.2 keeping all the same config files. I am running it on a Debian Woody system and using Postgres 7.4.7 as the database. This particular box is solely for RADACCT and only uses
Hi, I have just (as of yesterday) upgraded FreeRADIUS from 1.0.3 to 1.1.2 keeping all the same config files. I am running it on a Debian Woody system and using Postgres 7.4.7 as the database. This particular box is solely for RADACCT and only uses RADIUS as a test to test the state of the service
12 matches
Mail list logo
