Aaron Richton wrote:
On Thu, 16 Aug 2012, JET JETASIK wrote:
From truss during simple bind, I can see it read the radius.conf and sendto() my radius server, also got recvfrom() it, but nothing hit my radius server actually. Below is output of truss -p <slapd_pid>
Honestly, that looks like it *is* working from the client perspective. If
you're
asserting that nothing hit your radius server, I'd take a few minutes with wireshark/tcpdump/snoop/etc. and see if that's true (run it on both
sides). If
the server-side captures show nothing then fix the network so the packet gets seen by the server. If the captures show 2-way conversation then fix your radius server so it logs/debugs the packet that the kernel's actually getting.
Also, it might be worth getting a copy of radtest or similar program and getting that working on the box running slapd. Ideally, said test program would be linked against the same libradius as slapd.
Sorry it's my careless, actually it hit my radius server but this kind of log will only be shown when turning on full-trace logging level. Same machine with radtest, to my radius server, the request is valid but not with openldap's radius module as it lacks an attribute as seen from the below log.
[2012/08/16|14:06:22.578125][02492][MINOR][ValidationTask::getNASLocationFro mPacket] > No NAS-IP or NAS-Identifier attribute found. [2012/08/16|14:06:22.578125][02492][MAJOR][ValidationTask::routePacket] > Rejecting RADIUS request due to missing NAS Location
I don't see there is option to define the NAS-IP or NAS-Identifier in /etc/radius.conf Furthermore I dig into openldap's radius.c, only RAD_USER_NAME and RAD_USER_PASSWORD(line 82, 86) attached into the request. Please advise how to put NAS-IP/NAS-Identifier into the request, maybe using rad_put_addr() ?
-- JET JETASIK