>
> Run the queries manually, and try to sort it out.
>
> Alan DeKok.
Thank you. Just in case, I tested a build of 2.1.12 now avail through
the stock repos on a CentOS 5.8 VM. It's working correctly, so I'm
confident I can get there (an upgrade, to boot) without much too
difficulty.
- Andrew
-
Andrew Long wrote:
> In case you missed it, the debug from latest test is a couple messages
> previous (our messages crossed). I have looked through it and with my
> limited knowledge see nothing exceptional except that processing stops
> with radgroupcheck and never moves to radgroupreply. Have yo
On Thu, Apr 5, 2012 at 12:04 PM, Andrew Long wrote:
> In case you missed it, the debug from latest test is a couple messages
> previous (our messages crossed). I have looked through it and with my
> limited knowledge see nothing exceptional except that processing stops
> with radgroupcheck and nev
In case you missed it, the debug from latest test is a couple messages
previous (our messages crossed). I have looked through it and with my
limited knowledge see nothing exceptional except that processing stops
with radgroupcheck and never moves to radgroupreply. Have you any
ideas?
- Andrew
-
Li
I think we crossed each other across the water...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
OK, the test from an actual client behind the Nomadix fails even after
un-commenting read_groups = yes and restarting, still no group
attributes passed in reply.
This debug is rather lengthy as I thought you might want to see some
of the earlier loading (though I snipped some).
What should I try
Andrew Long wrote:
> It was commented out! Given the comments, though, do you have any idea
> why it would still have failed when I tested with Fall-Through
> enabled? I did it like this:
> # radreply
> account-to-test Fall-Through = yes
It should work.
> So, I removed the comment and re
I should have said...
There is also the oddity that even though the line was commented
previously, groups were being processed as I would see in the reply
packets pairs that existed only in radgroupreply. JUST NOT THE ONES I WANT.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/li
> Did you set "read_groups = yes" in sql.conf?
>
> What about the comments just above that configuration?
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
It was commented out! Given the comments, though, do you have any idea
why it would stil
Andrew Long wrote:
> I am unable to get FreeRadius to reply with attributes assigned in the
> radgroupreply table for some groups. When the same attributes are
> assigned in radreply, the server sends them as expected. Adding a
> Fall-Through entry for the user in radreply makes no difference (the
For reference, here is a debug from another account's auth request
which successfully processes radgroupreply and sends the pairs from
that table. The attributes are different here because the NAS is
different and I don't want to confuse it by assigning another vendor's
attributes. I did accidental
Platfrom: CentOS 5.8
FreeRADIUS: 2.1.8
Backend: MySQL
I am unable to get FreeRadius to reply with attributes assigned in the
radgroupreply table for some groups. When the same attributes are
assigned in radreply, the server sends them as expected. Adding a
Fall-Through entry for the user in radrep
12 matches
Mail list logo
