Re: dynamic check item, based on nas type
On Mon, Feb 15, 2010 at 8:47 AM, YvesDM ydm...@gmail.com wrote: Hi, Situation: All users can login to different nas types. Problem: I need a different value for simult.-use check depending on the nas a user logs on to. Is there a way to do this? (using FR1.1.7 for now) tnx. Yves Edited title, needed to be check-item instead of reply of course, sorry. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Allowing user from one realm but not another
Jeff A wrote: I am using cistron compat to accommodate my userfile inputted by rodopi I'd really suggest using the FreeRADIUS features. Ask rodopi to fix their product. I have tried adding the ! and : symbol in the above line (makes no difference) Uh... I tried random things and they didn't work. That's not the way to solve the problem. See man users for *documentation* on how it works. Also have tried the realm item as a check item, quote, and no options with same results If a check item its placed on same line as username etc but still no go as below example dialuptestPassword = secret Realm = foo.net, Auth-Type = Reject That is wrong on a number of points. I think you're really not clear on how the users file works. Read the documentation for it, and then go back and read my earlier message. The line above does NOT match my message. Therefore, it's wrong. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ancient Freeradius Problem
Hi, I didn't yet running any program excepted radtest user localhost 1812 testing123 as root. And it reported rad_recv: Access-Reject packet from host 127.0.0.1:1812, id=172, length=20. Do you have any clue ? That's the client side. Your server is configured to run a program with Exec-Program, and *that one* is failing: cfg.c, line 175: no permission for configfile Exec-Program output: Exec-Program: returned: 1 Delaying request 0 for 1 seconds Finished request 0 From its own output, it appears to be a program which requires to read a config file, but doesn't have permission to read that file. There is nothing this list can do to help you since the external program has an error. You also didn't provide us hints as to how your configuration looks like; which makes it even harder to help you. All I can say here: fix your permissions of your external program... Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Counters reset period
Hey, I've defined a quarterly reset period counter (reset=3m), and when logging-in the %b and %e (beginning of counter and ending of counter periods) I am getting values for beginning which are equal to the 1st of December and ending which is equal to the beginning of March. Meaning, the quarter begins with 1st of December while I would expect it to begin at the 1st of January (being a calendar quarter). Could someone please explain this behavior? Thanks, Liran. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Allowing user from one realm but not another
Ok, I figured I goofed something up. Been looking at this so long, I am making big mistakes. -Original Message- From: freeradius-users-bounces+jeffa=globalco@lists.freeradius.org [mailto:freeradius-users-bounces+jeffa=globalco@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Monday, February 15, 2010 3:15 AM To: FreeRadius users mailing list Subject: Re: Allowing user from one realm but not another Jeff A wrote: I am using cistron compat to accommodate my userfile inputted by rodopi I'd really suggest using the FreeRADIUS features. Ask rodopi to fix their product. I have tried adding the ! and : symbol in the above line (makes no difference) Uh... I tried random things and they didn't work. That's not the way to solve the problem. See man users for *documentation* on how it works. Also have tried the realm item as a check item, quote, and no options with same results If a check item its placed on same line as username etc but still no go as below example dialuptestPassword = secret Realm = foo.net, Auth-Type = Reject That is wrong on a number of points. I think you're really not clear on how the users file works. Read the documentation for it, and then go back and read my earlier message. The line above does NOT match my message. Therefore, it's wrong. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Counters reset period
It seems that the counting period is X months until the current month. So if reset=3m is specified and it's now February it will count 3 months earlier (thus, december, january and february). I'm wondering if anybody has some insight regarding yearly recurring quarterly periods (months:1-3,4-6,7-9,10-12). Regards, Liran. On Mon, Feb 15, 2010 at 1:58 PM, liran tal liransgar...@gmail.com wrote: Hey, I've defined a quarterly reset period counter (reset=3m), and when logging-in the %b and %e (beginning of counter and ending of counter periods) I am getting values for beginning which are equal to the 1st of December and ending which is equal to the beginning of March. Meaning, the quarter begins with 1st of December while I would expect it to begin at the 1st of January (being a calendar quarter). Could someone please explain this behavior? Thanks, Liran. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Allowing user from one realm but not another
Ok good news I got it to work..New day less tired and man what an idiot I was. I have a question though. Freeradius can look at more than one user file, what is the syntax to allow this to read another, and where do I place the entry for it I am wanting to do this so I can convert to complete realm names for the users, but since so many users with different realms The process is going to take awhile, so I need for the program to see both entries so there will be a match till the process is completed I I would place them in the same file then they would be overwritten Thanks And Thanks so much for the help on the realm issue Jeff -Original Message- From: freeradius-users-bounces+jeffa=globalco@lists.freeradius.org [mailto:freeradius-users-bounces+jeffa=globalco@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Monday, February 15, 2010 3:15 AM To: FreeRadius users mailing list Subject: Re: Allowing user from one realm but not another Jeff A wrote: I am using cistron compat to accommodate my userfile inputted by rodopi I'd really suggest using the FreeRADIUS features. Ask rodopi to fix their product. I have tried adding the ! and : symbol in the above line (makes no difference) Uh... I tried random things and they didn't work. That's not the way to solve the problem. See man users for *documentation* on how it works. Also have tried the realm item as a check item, quote, and no options with same results If a check item its placed on same line as username etc but still no go as below example dialuptestPassword = secret Realm = foo.net, Auth-Type = Reject That is wrong on a number of points. I think you're really not clear on how the users file works. Read the documentation for it, and then go back and read my earlier message. The line above does NOT match my message. Therefore, it's wrong. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Counters reset period
liran tal wrote: It seems that the counting period is X months until the current month. So if reset=3m is specified and it's now February it will count 3 months earlier (thus, december, january and february). I'm wondering if anybody has some insight regarding yearly recurring quarterly periods (months:1-3,4-6,7-9,10-12). Use a cron job SQL statements. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Allowing user from one realm but not another
Jeff A wrote: Freeradius can look at more than one user file, what is the syntax to allow this to read another, and where do I place the entry for it $ man users And also see the documentation at the top of the users file. Look for include. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Counters reset period
On Mon, Feb 15, 2010 at 5:21 PM, Alan DeKok al...@deployingradius.comwrote: liran tal wrote: It seems that the counting period is X months until the current month. So if reset=3m is specified and it's now February it will count 3 months earlier (thus, december, january and february). I'm wondering if anybody has some insight regarding yearly recurring quarterly periods (months:1-3,4-6,7-9,10-12). Use a cron job SQL statements. Alan, could you explain? Since the '3m' reset period didn't work as I expected I patched the rlm_sqlcounter.c to reset counters on a quarterly cycle. Though I'd appreciate to hear from you another approach to this. Regards, Liran Tal. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Counters reset period
liran tal wrote: Use a cron job SQL statements. Alan, could you explain? The counters are stored in a DB. You can reset them any time you want by just editing the DB. Since the '3m' reset period didn't work as I expected I patched the rlm_sqlcounter.c to reset counters on a quarterly cycle. Though I'd appreciate to hear from you another approach to this. If it works, fine. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
How to convert User-Name to lower case
I currently have a working system which authenticates users using a
LDAP (eDirectory) backend. The authentication process is speedy quick!
(between 0-11 ms) However, I also have a need to return attributes
based on group membership. This part of the process is very slow
(upwards of 6500ms) The reason it is slow is that it has to query
every group and check for membership. (The reason it has to be done
this way is that I am using dynamic groups a which do not populate an
attribute in the user)
Long story short, I found an acceptable solution where I have a script
that routinely create a new users file. Everything works perfect and
very quick ( 60 ms), however I did find a problem. When FreeRadius
checks the user file it is case sensitive. So while LDAP does care
whether I type in BoBUser or bobuser, it matters to the USERS file.
And since I have no control over how stupid my end-users are much less
how they try in their username, this is a big problem!
* I first tried tried lower_case=yes/before:
This was useless and did absolutely nothing!
* I then tried Case Insensitive Regular Expressions =~ /blahblah/i
Again a freaking nightmare. Apparently the =~ is a match for
everything it compares!
* I had the best luck with attr_rewrite and using an
%{exec:/bin/homemadelowerfunction }
While this did in fact convert/replace the user name to lowercase, it
also added quotes and a trailing space!!! (i.e. BOBUSER becomes
bobuser )
I have spent the day searching the internet for a solution, but
Nothing. I refuse to believe I am the first human being ever to run
into this problem...
Please tell me someone has an idea.
Thanks
Bob
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How to convert User-Name to lower case
On Feb 15, 2010, at 12:26 PM, Bob Brandt wrote: I have spent the day searching the internet for a solution, but Nothing. I refuse to believe I am the first human being ever to run into this problem... Please tell me someone has an idea. Thanks Bob http://lists.freeradius.org/mailman/htdig/freeradius-users/2009-June/msg00335.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
Hi Alan,
The main reason my initial checking was with tcpdump was to identify what
the packets were doing.
ACCT request IN from LNS - check
ACCT request OUT to downstream RADIUS - no
So the problem is not due to the downstream RADIUS failing to respond at
all. (ie genuinely/obviously dead)
Overnight I upgraded to 2.1.8, and now the behavior has changed, slightly.
Freeradius is complaining in the logs, but now it looks like enough
back-n-forth is happening that my LNS doesn't lose its mind any more.
Freeradius is deciding that my accounting proxy destination 'looks like it
is dead'.
Tue Feb 16 07:45:32 2010 : Proxy: Marking home server {{radius-ip}} port
1813 as zombie (it looks like it is dead).
I'm not entirely sure why, though. TCPDUMP shows a stream of accounting
requests being proxied to that server, and being received from that server,
while at the same time freeradius continues to log 'looks like it is dead'
messages.
Also, status check (via request) succeeds, naturally, given that its not
the auth proxy that freeradius is complaining about.
(single downstream RADIUS configured as auth+acct)
Thanks,
Phil P
Tue Feb 16 07:46:31 2010 : Proxy: Received response to status check 68398
(563 in current sequence)
On Mon, Feb 15, 2010 at 6:23 PM, Alan DeKok al...@deployingradius.comwrote:
Phil Pierotti wrote:
TCPDUMP shows the accounting requests are still being received on the
freeradius box, but the outbound/proxied messages have just stopped.
Any suggestions as to what might be wrong/where to look?
The logs from the server?
I don't understand why you're looking at tcpdump, and not the
FreeRADIUS logs.
In 2.1.7, you can also use raddebug to get the debug logs from a
running server.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
Phil Pierotti wrote:
The main reason my initial checking was with tcpdump was to identify
what the packets were doing.
As opposed to looking at the debug logs from the server?
You can look at the high level packet in / packet out view. Or, you
can look at the detailed log messages from the server saying what's
going wrong, and why.
You chose the high-level view. I'm trying to convince you to look at
the informative view. You don't seem to see this as useful.
So the problem is not due to the downstream RADIUS failing to respond at
all. (ie genuinely/obviously dead)
There is a LOT more that can go on than just packet in / packet out.
Maybe you might want to look for more information.
Since you've ALREADY looked at the tcpdump logs and they didn't
help... maybe looking for MORE information would be a good idea.
Freeradius is deciding that my accounting proxy destination 'looks like
it is dead'.
Tue Feb 16 07:45:32 2010 : Proxy: Marking home server {{radius-ip}}
port 1813 as zombie (it looks like it is dead).
If you had bothered to run the server in debugging mode, OR to use
raddebug as I suggested, you might find out WHY this is happening.
Can you explain why you're not doing that?
I'm not entirely sure why, though. TCPDUMP shows a stream of accounting
requests being proxied to that server, and being received from that
server, while at the same time freeradius continues to log 'looks like
it is dead' messages.
You've said that. It's simply one step out of many. For some reason,
you can't get past BUT PACKETS ARE GOING BACK AND FORTH. You have
refused to follow the instructions which can help you solve the problem.
Also, status check (via request) succeeds, naturally, given that its
not the auth proxy that freeradius is complaining about.
(single downstream RADIUS configured as auth+acct)
There is no naturally here.
Run in debugging mode. Have I said that enough? Is there anything
else I need to say to convince you to run in debugging mode?
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
On Tue, Feb 16, 2010 at 4:00 AM, Phil Pierotti phil.piero...@gmail.com wrote:
Tue Feb 16 07:45:32 2010 : Proxy: Marking home server {{radius-ip}} port
1813 as zombie (it looks like it is dead).
I assume that radius is out of your control?
Also, status check (via request) succeeds, naturally, given that its not
the auth proxy that freeradius is complaining about.
(single downstream RADIUS configured as auth+acct)
Running in debugging mode, or at least looking at FR logs, might show
you what's happening. I suspect the home server is taking a long time
processing acct packets. This is somewhat common if (for example) the
home server uses database for acct, with lots of rows and index, an
slow disks, in such a way that writes/updates takes a long time. This
is just a guess though, more info should be available from the log.
--
Fajar
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
Hi Alan,
Sorry, I didn't mean to imply I wasn't interested in looking further, my
primary concern was to find out if it was something as simple and obvious as
the downstream proxy not responding.
Thanks for your feedback, I'll look at the debug logs and see what they tell
me, given the fairly frequent packets, that'll be a decent bit of reading.
Meanwhile - on what basis does Freeradius decide that a downstream proxy is
dead?
Thanks,
PhilP
On Tue, Feb 16, 2010 at 8:35 AM, Alan DeKok al...@deployingradius.comwrote:
Phil Pierotti wrote:
The main reason my initial checking was with tcpdump was to identify
what the packets were doing.
As opposed to looking at the debug logs from the server?
You can look at the high level packet in / packet out view. Or, you
can look at the detailed log messages from the server saying what's
going wrong, and why.
You chose the high-level view. I'm trying to convince you to look at
the informative view. You don't seem to see this as useful.
So the problem is not due to the downstream RADIUS failing to respond at
all. (ie genuinely/obviously dead)
There is a LOT more that can go on than just packet in / packet out.
Maybe you might want to look for more information.
Since you've ALREADY looked at the tcpdump logs and they didn't
help... maybe looking for MORE information would be a good idea.
Freeradius is deciding that my accounting proxy destination 'looks like
it is dead'.
Tue Feb 16 07:45:32 2010 : Proxy: Marking home server {{radius-ip}}
port 1813 as zombie (it looks like it is dead).
If you had bothered to run the server in debugging mode, OR to use
raddebug as I suggested, you might find out WHY this is happening.
Can you explain why you're not doing that?
I'm not entirely sure why, though. TCPDUMP shows a stream of accounting
requests being proxied to that server, and being received from that
server, while at the same time freeradius continues to log 'looks like
it is dead' messages.
You've said that. It's simply one step out of many. For some reason,
you can't get past BUT PACKETS ARE GOING BACK AND FORTH. You have
refused to follow the instructions which can help you solve the problem.
Also, status check (via request) succeeds, naturally, given that its
not the auth proxy that freeradius is complaining about.
(single downstream RADIUS configured as auth+acct)
There is no naturally here.
Run in debugging mode. Have I said that enough? Is there anything
else I need to say to convince you to run in debugging mode?
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
Hi Fajar,
Yes and no, it's a third-party product integrated into our billing system,
so it's 100% mystery magic.
Debugging is strictly ask someone to fix it because its broken.
Re: your comments about database lookups, this is exactly the situation.
Thanks,
Phil P
On Tue, Feb 16, 2010 at 8:56 AM, Fajar A. Nugraha fa...@fajar.net wrote:
On Tue, Feb 16, 2010 at 4:00 AM, Phil Pierotti phil.piero...@gmail.com
wrote:
Tue Feb 16 07:45:32 2010 : Proxy: Marking home server {{radius-ip}} port
1813 as zombie (it looks like it is dead).
I assume that radius is out of your control?
Also, status check (via request) succeeds, naturally, given that its not
the auth proxy that freeradius is complaining about.
(single downstream RADIUS configured as auth+acct)
Running in debugging mode, or at least looking at FR logs, might show
you what's happening. I suspect the home server is taking a long time
processing acct packets. This is somewhat common if (for example) the
home server uses database for acct, with lots of rows and index, an
slow disks, in such a way that writes/updates takes a long time. This
is just a guess though, more info should be available from the log.
--
Fajar
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
So I've run freeradius with -X -xx Other than logging the details of the packets sent and received, the debug logs do not have much more than marking as zombie, seems to be dead. No complaints, no explanation, no details, just jumps straight into looks like its dead. This is the point at which freeradius decides the downstream has died. Tue Feb 16 09:40:25 2010 : Info: ++[files] returns ok Sending Accounting-Request of id 180 to 192.168.147.2 port 1813 Acct-Session-Id = 00064089 Tunnel-Type:0 = L2TP Tunnel-Medium-Type:0 = IPv4 Tunnel-Server-Endpoint:0 = 192.168.92.1 Tunnel-Client-Endpoint:0 = 192.168.189.5 Tunnel-Assignment-Id:0 = - Tunnel-Client-Auth-Id:0 = - Tunnel-Server-Auth-Id:0 = - Acct-Tunnel-Connection = 2997106923 Framed-Protocol = PPP Tunnel-Medium-Type:0 = IPv4 Tunnel-Client-Endpoint:0 = 192.168.136.41 Tunnel-Server-Endpoint:0 = 192.168.136.44 Tunnel-Assignment-Id:0 = - Tunnel-Type:0 = L2TP Acct-Tunnel-Connection = 3093807349 Tunnel-Client-Auth-Id:0 = - Tunnel-Server-Auth-Id:0 = - User-Name := --...@- Cisco-AVPair = connect-progress=Call Up Acct-Session-Time = 58738 Acct-Input-Octets = 2042638912 Acct-Output-Octets = 82147247 Acct-Input-Packets = 2167463 Acct-Output-Packets = 1162476 Acct-Authentic = Local Acct-Status-Type = Interim-Update Calling-Station-Id = GigabitEthernet 8/0.31100305:3110-305#587265364###pppoe 00:1e:2a:13:24:28#QTORQE17M atm 1/1/14/32:8.35# Service-Type = Framed-User NAS-IP-Address = 192.168.144.10 Acct-Delay-Time = 2 Proxy-State = 0x3936 Tue Feb 16 09:40:25 2010 : Info: Proxying request 33 to home server 192.168.147.2 port 1813 Sending Accounting-Request of id 180 to 192.168.147.2 port 1813 Acct-Session-Id = 00064089 Tunnel-Type:0 = L2TP Tunnel-Medium-Type:0 = IPv4 Tunnel-Server-Endpoint:0 = 192.168.92.1 Tunnel-Client-Endpoint:0 = 192.168.189.5 Tunnel-Assignment-Id:0 = - Tunnel-Client-Auth-Id:0 = - Tunnel-Server-Auth-Id:0 = - Acct-Tunnel-Connection = 2997106923 Framed-Protocol = PPP Tunnel-Medium-Type:0 = IPv4 Tunnel-Client-Endpoint:0 = 192.168.136.41 Tunnel-Server-Endpoint:0 = 192.168.136.44 Tunnel-Assignment-Id:0 = - Tunnel-Type:0 = L2TP Acct-Tunnel-Connection = 3093807349 Tunnel-Client-Auth-Id:0 = - Tunnel-Server-Auth-Id:0 = - User-Name := --...@- Cisco-AVPair = connect-progress=Call Up Acct-Session-Time = 58738 Acct-Input-Octets = 2042638912 Acct-Output-Octets = 82147247 Acct-Input-Packets = 2167463 Acct-Output-Packets = 1162476 Acct-Authentic = Local Acct-Status-Type = Interim-Update Calling-Station-Id = GigabitEthernet 8/0.31100305:3110-305#587265364###pppoe 00:1e:2a:13:24:28#QTORQE17M atm 1/1/14/32:8.35# Service-Type = Framed-User NAS-IP-Address = 192.168.144.10 Acct-Delay-Time = 2 Proxy-State = 0x3936 Tue Feb 16 09:40:25 2010 : Debug: Going to the next request Tue Feb 16 09:40:25 2010 : Debug: Waking up in 0.1 seconds. Tue Feb 16 09:40:25 2010 : Proxy: Marking home server 192.168.147.2 port 1813 as zombie (it looks like it is dead). Sending Accounting-Request of id 228 to 192.168.147.2 port 1813 User-Name := --...@- Acct-Status-Type := Stop Acct-Session-Id := Event-Timestamp := Feb 16 2010 09:40:25 EST NAS-Identifier := Status Check. Are you alive? Tue Feb 16 09:40:25 2010 : Debug: Waking up in 0.7 seconds. rad_recv: Accounting-Response packet from host 192.168.147.2 port 1813, id=228, length=20 Tue Feb 16 09:40:25 2010 : Proxy: Received response to status check 34 (1 in current sequence) Tue Feb 16 09:40:25 2010 : Debug: Waking up in 0.7 seconds. Thanks, Phil P On Tue, Feb 16, 2010 at 9:11 AM, Phil Pierotti phil.piero...@gmail.comwrote: Hi Alan, Sorry, I didn't mean to imply I wasn't interested in looking further, my primary concern was to find out if it was something as simple and obvious as the downstream proxy not responding. Thanks for your feedback, I'll look at the debug logs and see what they tell me, given the fairly frequent packets, that'll be a decent bit of reading. Meanwhile - on what basis does Freeradius decide that a downstream proxy is dead? Thanks, PhilP On Tue, Feb 16, 2010 at 8:35 AM, Alan DeKok al...@deployingradius.comwrote: Phil Pierotti wrote: The main reason my initial checking was with tcpdump was to identify what the packets were doing. As opposed
Re: Problems with freeradius accounting proxy
Phil Pierotti wrote: So I've run freeradius with -X -xx Other than logging the details of the packets sent and received, the debug logs do not have much more than marking as zombie, seems to be dead. They have rather a lot more than that. No complaints, no explanation, no details, just jumps straight into looks like its dead. I doubt that very much. This is the point at which freeradius decides the downstream has died. Once again... looking at only a tiny portion of the available data is wrong. You carefully deleted pretty much all of the debug log that might be useful. Is the server showing that it receives responses to the proxied packets? Since you've deleted 99% of the debug log, I can't tell. Since you don't know what to look for in the logs, you can't tell, either. Are you interested in solving the problem, or do you want to play games by not following instructions, and withholding information that could let us help you? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius PEAP/MSCHAPv2 against Apple OpenDirectory
Moritz Dereschkewitz wrote: Wow, that sounds great. I haven't read about the use_open_directory option yet. Do I have to configure the mschap-module to connect to the OD, since Freeradius is not running on the Apple server? E.g. specify the server adress? Or does it find the server automatically? You need to run FreeRADIUS on the same machine as Open Directory. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
On Tue, Feb 16, 2010 at 6:09 AM, Phil Pierotti phil.piero...@gmail.com wrote: Tue Feb 16 09:40:25 2010 : Proxy: Marking home server 192.168.147.2 port 1813 as zombie (it looks like it is dead). There should be other things before that Sending Accounting-Request of id 228 to 192.168.147.2 port 1813 User-Name := --...@- Acct-Status-Type := Stop Acct-Session-Id := Event-Timestamp := Feb 16 2010 09:40:25 EST NAS-Identifier := Status Check. Are you alive? Tue Feb 16 09:40:25 2010 : Debug: Waking up in 0.7 seconds. rad_recv: Accounting-Response packet from host 192.168.147.2 port 1813, id=228, length=20 Tue Feb 16 09:40:25 2010 : Proxy: Received response to status check 34 (1 in current sequence) Like that one. That particular status check was completed immediately. How were other status check responses, do they arrive on time? How about actual accounting request, do they get a timely response? It is possible that the status check returns early due to non-existent record (Acct-Session-Id := ) needs no db write at all, while actual accounting requests received late response due to db write involved. As Alan said, a complete debug log would be able to show that (and possible other problems as well). You should be able to find out how long it takes for actual accounting packets to get response. If it's within reasonable limits, you may need to increase FR proxy timeouts so it doesn't declare the home server to be dead or zombie. However if it's dreadfully slow, your only choice is to fix your database, possibly tuning it or add faster disks. -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
