Tweaking LDAP parameters

[David Hartburn]

Hi,

Thanks for this response. The problem appears to be load related, so 
this will have to be done on the full production. It has never appeared 
on either our test/dev box or handling just our roaming users. It has 
been sending campus traffic that has generated the problem. It is not 
restricted to one client.

It seems to report every few minutes, so I will try doing a -X for a 5 
minute spell and see if the error is captured. I will post back what I find.

Dave


On 13/04/16 14:29, Matthew Newton wrote:
> On Wed, Apr 13, 2016 at 02:10:14PM +0100, David Hartburn wrote:
>> Sorry to waste time, but do you mean the full log from doing a 'radius -X'?
>
> That's what contains the required information.
>
>> I want to clarify because on a production server that will be a huge log. I
>> am happy to produce it though.
>
> Depending on the problem, you can sometimes be more specific about
> what you log by using radmin. First run radiusd -X and capture the
> output to the end of the startup (when it reports about Listening
> for packets). That grabs all the useful config information.
>
> Then you use radmin to capture auth information for a particular
> client. There's some information on the FR web page:
> http://freeradius.org/radiusd/man/radmin.html
>
> I did a post on how you can filter out by attribute a while back:
> http://notes.asd.me.uk/2014/09/16/debugging-freeradius-packets-with-radmin/
>
> But the best way really is to reproduce it on a test RADIUS
> server with one or two clients. That doesn't have to be hard -
> a great way is to add proxy config to your production servers over
> to a test server. When you want to capture something like this,
> just proxy particular client(s) over using unlang to select based
> on some attributes. Could be MAC address, realm, SSID, location
> etc. Makes testing things much easier and more flexible, and of
> course the debug logs on the test server will be smaller.
>
> Matthew
>
>