Alan, Thanks. I ran radius in debug mode and examined the request. Its data matches what I'm using so I'm back to square one. When you say "RFC 5176 should allow that" what specifically are you referring to? Bil On 11/19/2015 11:16 AM, Alan DeKok wrote:
On Nov 19, 2015, at 12:11 PM, Bill Schoolfield <bill@billmax.com> wrote:
This isn't freeradius specific per se but I can't find anything on the web about this. Maybe someone here has experience with this. Oh, yes.
I'm trying to drop a session using radclient:
Sending Disconnect-Request of id 169 to 204.101.13.1 port 1700 User-Name = "someid@example.com" Acct-Session-Id = "erx ip:67.69.123.10:67.69.201.164:1698:d542:29da:ae8e:33d542:002" You would think that would work, right?
I spent a *long* time in the IETF RADEXT working group arguing that RFC 5176 should allow that. The vendors refused... because all of their equipment would immediately become non-compliant.
rad_recv: Disconnect-NAK packet from host 204.101.13.1 port 1700, id=169, length=26 Error-Cause = Session-Context-Not-Found Yup.
But regardless of what I try I can't seem to send the right attrs to get (ie. find) an active session dropped. Yup. And if you send *too many* attributes, it will complain with "Unsupported attribute".
The NAS is a Juniper Edge Routing Switch ERX-310. Best I can tell I have the right attrs. Including others results in Unsupported attr error. Omitting either of these two results in attr missing error.
Does anybody know the what should be passed? Here is the radacct record for the session: Typically send the same attributes you see in an Accounting-Request packet. And hope for the best.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html