Re: detail sql logging problem

2008-04-16 Thread Alan DeKok
[EMAIL PROTECTED] wrote:
> a further question on this one - as the detail relay virtual
> server buffered-sql is only supposed to run when the main thread
> isnt busy...and is only supposed to read detail file, log to SQL
> then 'be quiet' why, when it encounters such an issue does the
> main authentication/accounting etc thread not process anything?

  I'm not sure  I haven't been able to test it myself, so I don't
really know what's going on in that situation.

> I'd have thought that the virtual server would be moaning and
> complaining as much as it wants, but the main core functionality
> would just keep on going...

  I would think so, too.

  Maybe the detail file reader is re-queuing "failed" requests too
quickly, and starving other threads from CPU...

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: detail sql logging problem

2008-04-16 Thread A . L . M . Buxey
hi,

a further question on this one - as the detail relay virtual
server buffered-sql is only supposed to run when the main thread
isnt busy...and is only supposed to read detail file, log to SQL
then 'be quiet' why, when it encounters such an issue does the
main authentication/accounting etc thread not process anything?
I'd have thought that the virtual server would be moaning and
complaining as much as it wants, but the main core functionality
would just keep on going...

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: detail sql logging problem

2008-04-15 Thread A . L . M . Buxey
Hi,

>   "unlang". :)

yes - i was pondering that one.  okay.
and even better, use eg sql_log for the
ones that are session-time = 0 so that i can
capture them, know them, and see when the 
issue is fixed etc...

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: detail sql logging problem

2008-04-15 Thread Alan DeKok
[EMAIL PROTECTED] wrote:
> further to last email, heres example packet:
>
...
> Acct-Session-Time = 0

  "unlang". :)

accounting {
...
if (Acct-Sesion-Time != 0) {
sql
}
else {
ok
}
...
}

  i.e. bypass the module that gets upset over 0 session time.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


detail sql logging problem

2008-04-15 Thread A . L . M . Buxey
hi,

further to last email, heres example packet:

Tue Apr 15 12:20:56 2008
User-Name = "x"
NAS-Port = 29
NAS-IP-Address = 192.168.1.28
Framed-IP-Address = 192.168.0.3
NAS-Identifier = "wism"
Airespace-Wlan-Id = 1
Acct-Session-Id = "48048f97/00:11:12:12:14:11/8514"
Acct-Authentic = RADIUS
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "222"
Acct-Status-Type = Stop
Acct-Input-Octets = 1942107
Acct-Output-Octets = 5085070
Acct-Input-Packets = 9162
Acct-Output-Packets = 8299
Acct-Terminate-Cause = Lost-Service
Acct-Session-Time = 0
Acct-Delay-Time = 0
Calling-Station-Id = "192.168.0.3"
Called-Station-Id = "192.168.1.28"
Acct-Unique-Session-Id = "f7ebd89424c03437"
Timestamp = 1208258456
Request-Authenticator = Verified

as you can see, Stop request, due to lost service.  however, sessio-time
is 0 - i suspect this is because of mobility. they've moved from one
wism controller to another or from one AP to another and then left
the network altogther. either way, kit is reporting the value. in
our SQL logging we look for the Acct-Session-Id, and the Timestamp
and then use those to create the session time due to wierdnesses
(see the example UPDATE comand in sql/postgresl/dialup.conf to get
what I mean) so hope we dont actually care about what the kit tells
us(!)

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html