Community discussions

MUM Europe 2020
 
User avatar
sublimespot
newbie
Topic Author
Posts: 45
Joined: Sun Sep 11, 2005 2:00 am

Radius Disconnect

Fri Feb 03, 2006 9:11 pm

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?
 
User avatar
sublimespot
newbie
Topic Author
Posts: 45
Joined: Sun Sep 11, 2005 2:00 am

Fri Feb 03, 2006 9:19 pm

It worked with Framed-Ip-Address
 
savage
Forum Guru
Forum Guru
Posts: 1214
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Fri Feb 03, 2006 10:28 pm

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:
  NAS-IP-Address = this.is.the.ip.of.my.NAS
  User-Name = piet@somewhere.nice
  Acct-Session-Id = 81200000
  Calling-Station-Id = MAC:Address:Of:PPPOE:Client
  Framed-IP-Address = this.is.the.ip.of.the.user
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.
Regards,
Chris
 
bluestar
newbie
Posts: 31
Joined: Fri May 06, 2005 1:21 am

I also have the similar problem:

Fri Feb 03, 2006 10:50 pm

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?
 
savage
Forum Guru
Forum Guru
Posts: 1214
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Fri Feb 03, 2006 11:04 pm

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.
Regards,
Chris
 
User avatar
sublimespot
newbie
Topic Author
Posts: 45
Joined: Sun Sep 11, 2005 2:00 am

Fri Feb 03, 2006 11:30 pm

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.
 
savage
Forum Guru
Forum Guru
Posts: 1214
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Fri Feb 03, 2006 11:34 pm

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.
Regards,
Chris
 
User avatar
sublimespot
newbie
Topic Author
Posts: 45
Joined: Sun Sep 11, 2005 2:00 am

Fri Feb 03, 2006 11:36 pm

I have a support contract with MT. So if they do not pick up on it then I will let them know.
 
savage
Forum Guru
Forum Guru
Posts: 1214
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Tue Feb 07, 2006 10:55 am

Just a quick proove on concept:
MT:
      requests: 0
  bad-requests: 0
          acks: 0
          naks: 0
I now send a invalid Disconnect (NAS-IP-Address is incorrect):
Sending Disconnect-Request of id 135 to 198.18.60.1:1700
        NAS-IP-Address = 198.18.60.2
        Framed-IP-Address = 00:00:00:00:00:00
rad_recv: Disconnect-NAK packet from host 198.18.60.1:1700, id=135, length=45
        Error-Cause = NAS-Identification-Mismatch
        NAS-Identifier = "wsmd-core02"
        NAS-IP-Address = 198.18.60.1
MT Stats:
      requests: 0
  bad-requests: 1
          acks: 0
          naks: 0
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
Sending Disconnect-Request of id 144 to 198.18.60.1:1700
        NAS-IP-Address = 198.18.60.1
        Framed-IP-Address = 00:00:00:00:00:00
Re-sending Disconnect-Request of id 144 to 198.18.60.1:1700
        NAS-IP-Address = 198.18.60.1
        Framed-IP-Address = 00:00:00:00:00:00
Re-sending Disconnect-Request of id 144 to 198.18.60.1:1700
        NAS-IP-Address = 198.18.60.1
        Framed-IP-Address = 00:00:00:00:00:00
Timeouts... MT Stats:
      requests: 0
  bad-requests: 1
          acks: 0
          naks: 0
Radius listener is dead. It's not accepting any other requests untill the service is disabled and re-enabled.
Regards,
Chris
 
bluestar
newbie
Posts: 31
Joined: Fri May 06, 2005 1:21 am

Tue Feb 07, 2006 11:16 am

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 ?
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24387
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Tue Feb 07, 2006 11:17 am

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
 
savage
Forum Guru
Forum Guru
Posts: 1214
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Tue Feb 07, 2006 11:22 am

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.
Flags: X - disabled 
 #   SERVICE          CALLED-ID     DOMAIN        ADDRESS         SECRET       
 0   ppp                                          198.18.60.2     core02  
     login           

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 ;)
Regards,
Chris
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24387
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Tue Feb 07, 2006 12:47 pm

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)

Who is online

Users browsing this forum: Bing [Bot] and 122 guests