I enabled Radius with /radius incoming set accept=yes

I tried to perform (Disconnect-Message) via command line:

echo 'User-Name = 00:00:00:00:00:00" | radclient 192.168.10.10:1700 "disconnect" radpasswd

Mikrotik Log says "Radius disconnect with no ip provided'

How can I disconnect a user by mac address?

It worked with Framed-Ip-Address

You need to send a NAS Identification, one of:
NAS-IP-Address,
NAS-Identifier, or
NAS-IPv6-Address (which won't be supported by MT).

Then, you need to also send, a SESSION Identification, one (or more), of:
User-Name,
NAS-Port,
Framed-IP-Address,
Called-Station-Id,
Calling-Station-Id,
Acct-Session-Id,
Acct-Multi-Session-Id (Not supported by MT),
NAS-Port-Type,
NAS-Port-Id,
Originating-Line-Info (Not supported by MT),
Framed-Interface-Id (Not supported by MT),
Framed-IPv6-Prefix (Not supported by MT).

Take those, build up your request, and send it to the MT. A typical disconnect request to drop a PPPoE connection, may therefore look like this:
That would be a properly formated disconnect message, including VARIOUS checks to ensure that the MT only disconnects the one single correct connection.

All these values, are received from each adn every single accounting update that the radius server receives, all the information is avaiable to the radius server, you just need to send the correct ones back.

Let's rather make sure we get the correct information on this forum.

I found the similar problem and possible bug in funcionality.
When mikrotik is configured to work as PPTP server and radius client, also
radius incoming is enabled.
Users can sucessfuly connect to mikrotik using PPTP and everything is working fine.

When "Disconnect-Message" come from radius server then something strange happend:

In PPP - Active connection conection is no longer prezent, but in
PPP - Interfaces we can still see connection present.
Also client ( win XP ) see connection established on his computer.

Ather that when client disconnect PPTP connection, then PPP - Interfaces
is now empty, but when we look in IP - Pool submeny we can see that IP
address

Previously used IP is still used in ip pool by pptp. It stay used until
reboot of mikrotik even all pptp clients are disconnected. Becouse of that
we will have no more free ip numbers in ip pool afther couple connectings
and disconectings clients on that way.

Have You any solution for this?

Based on his other post where he's able to crash the radius listener, I would bet the Radius Listener has issues...

Having a quick read through his post, I'm also going to take a gamble and say that MT has not implemented the RFC properly, or completely. Will be easy to verify however. Will see about playing with this over the course of the weekend, and perhaps send off a nice detailed bug report to MT for them to fix for the next release. Considering that the Radius Listener crashes on invalid requests, I am immediately seeing buffer overflow alarms coming up already.

It would seem to me, that there are mainly three issues involved here:
1 - MT accepts invalid requests. According to the RFC, a error code, 404 must be returned for invalid requests. MT, the RFC has a whole bunch of error return codes, I don't know what's going on in the code, but look at it please
2 - I'm going to say I'm almost certain, that when a DM is received, and not executed propperly, it's due to two issues:
2.1 - A invalid DM is sent to MT (for example, a DM packet not containing all the required information), or
2.2 - MT does not handle the disconnections / terminations of the Interface properly (my money is on both currently).

You have to remember, the MT needs to find the interface to disconnect, based on the information you give it! If you give it incorrect information, it's not going to disconnect the correct interface (if any). If you don't give it enough information, it's not going to find the interface to disconnect, or worse, disconnect the wrong interface. How more info you give it, the better chances that MT will find the interface and disconnect it properly.

Now, I'm not attacking MT here at the very least (I trust they won't see it as this), but provided that can be done, fixed, and deemed stable (which I don't see it as currently), it is going to be a brilliant feature. At this time however, I'm extremely reluctant to use it, due to problems like this.

The RFC is brief at best, the 'feature' is relatively new (Dated July, 2003), and there's not allot of support, nor information about it available because it is so new... Over time, I'm sure it will come right however.

If anyone is running this, and want to give it a try... See my post above, and try a DM using a properly formated request, giving as much information as possible. I'd say try and include all the attributes in the session-identification that MT supports.

savage, thanks for all this information. I was able to crash the listener with invalid information. Disabling the listener and re-enabling brought it back.

Ok, MT would need to sort that out then.

There's definately a error in the service inside of MT. It should not crash, it should return a NACK (Not Acknowledged), with a error 404 (Invalid request). My guess would be MT simply coded the parts of the RFC they require, and disregarded the rest.

This can now be seen as a bug IMHO. Spares me the sweat in this TERRIBLE summer we're having to go sit and sweat in a server room, playing with Mikrotiks and Radius.

Just incase MT doesn't pick up on it on the Forum, perhaps mail support@mt about this, though I'm sure we'll have a responce from MT about this here soon.

I have a support contract with MT. So if they do not pick up on it then I will let them know.

Just a quick proove on concept:
MT: I now send a invalid Disconnect (NAS-IP-Address is incorrect): MT Stats: So far so good, though, NACK should have gone up, as the request was not BAD, it was just incorrect... IMHO BAD = invalid syntax and the like, but that's a matter of opinion I guess.

I now send the same request, but with the correct NAS-IP-Address Timeouts... MT Stats:
Radius listener is dead. It's not accepting any other requests untill the service is disabled and re-enabled.

I have the same problem.
I send support file to support@mikrotik.com , but still no sollution in replay.
Have anyone any sucessful solution for Radius Disconnect to working fine ?

1. BAD means that shared secret (or packet signature) was not correct
2. Disconnect-Request will not work with PPPoE & PPTP because there is a problem in current versions that will be fixed in next release

1. BAD means that shared secret (or packet signature) was not correct

In that case, where are you supposed to configure the secrets for the incoming clients? The request was sent from the Radius Server that is configured as a Radius Client, same secret / IP / etc.
Either way, it is possible that the disconnect can come from a different server than what is configured in the Radius Server sections, therefore, there really is no place to configure a secret for the Incoming Radius Clients... Radius Client simply has enabled=yes/no and the incoming port. Nothing to specify client source addresses, or secrets

Unless, ofcourse I missed it

1. turn on debug,radius logs, there you will see what is happening;
2. if you want to send from another address, then you have to add this address as another radius server (doesn't matter that you will not use it)