Chris Parker wrote:
At 12:39 PM 11/21/2003, Greg G wrote:
I'm trying to figure out what goes into the acct_users. I had thought it was user entries like those in the users file, but that doesn't seem to really be the case. It appears to be getting parsed the same way (based on 'My-Key' entries that get rejected). However, at run-time, that doesn't appear to be the case. In fact, I get a seg-fault.
Huh? You are making things more difficult for yourself than need be.
In most cases you won't need to put anything in acct-users.
OK. That wasn't really clear, but that's easy to handle.
rad_recv: Accounting-Request packet from host xxx.xxx.xxx.xxx:36538, id=167, length=27
User-Name = "test1"
modcall: entering group preacct for request 0
http://www.freeradius.org/rfc/rfc2866.html#Accounting-Request
Any attribute valid in a RADIUS Access-Request or Access-Accept packet is valid in a RADIUS Accounting-Request packet, except that the following attributes MUST NOT be present in an Accounting- Request: User-Password, CHAP-Password, Reply-Message, State. Either NAS-IP-Address or NAS-Identifier MUST be present in a RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS- Port-Type attribute or both unless the service does not involve a port or the NAS does not distinguish among its ports.
So, the packet being sent is an invaled accounting packet, as it doesn't
contain NAS-IP-Address or NAS-Identifier. Nor a session-id.
Now that's strange, because this packet is being sent from radclient. I thought I had seen it work in 092 with the default acct_users, but it's seg faulting in 093 either way.
echo "User-Name = test1" | radclient radiusserver.mydomain.net acct a_secret
That being said, the server shouldn't seg-fault in that instance. It
should reject the packet as invalid and not try to process it further.
We'll look into this and correct the behaviour.
That works for me.
-Greg G
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
