RADIUS Attributes don't create Queue?

RouterOS General
1

Hello,

I am trying to bandwidth limit our clients by placing Mikrotik-Rate-Limit or Ascend-****-Rate into our radius server. These attributes are being received by the MT box (rb500, latest ROS), but there are no Simple Queues being created.

This is all a bit new to me, and I can’t find any posts here that seem to deal with this. I wonder if someone could point me in the direction of a good tutorial/troubleshooting guide that may help me with this? I have looked at the various Mikrotik documentation, but all I can glean is it should Just Work.

Thanx in Advance,
Neal

2

Your radius server allows you to send “Mikrotik-Rate-Limit”??? :open_mouth: That’s a invallid attribute name, it should be complaining and standing on it’s head…

The attribute you want is “Rate-Limit”. Have a look on the documentation again, I’m pretty sure nowhere does it mention Mikrotik-Rate-Limit… You also have to install the Mikrotik Radius Dictionary into your radius server, so that it will know what the attribute actually means and contains.

Failing that, post some debug output of your radius server processing the request, and mikrotik receiving the request.

3

Savage,

Thanks for your reply.

I understand what you mean regarding the attribute name. In fact, I tried using Rate-Limit to begin with, but it complained. Checking usr/local/share/freeradius/dictionary.mikrotik shows the line

ATTRIBUTE Mikrotik-Rate-Limit 8 string

So I used that. The Mikrotik dictionary (http://www.mikrotik.com/Documentation/manual_2.9/dictionary) indeed shows

ATTRIBUTE Rate-Limit 8 string Mikrotik

For testing, I edited usr/local/share/freeradius/dictionary.mikrotik to match this line (the server is live, so I didn’t fancy swapping the dictionaries out). In both cases, the MT box shows the attribute as MT-Rate-Limit - I assume this is because both attributes have a value of 8.

As requested, some debug output;

RADIUS says:
Sending Access-Accept of id 218 to 10.0.0.19 port 1034
Framed-MTU = 1500
Framed-Compression = Van-Jacobson-TCP-IP
Service-Type = Framed-User
Mikrotik-Rate-Limit = “128k/256k”

MT Box says:
Jun 2 09:56:06 10.0.0.19 wireless,debug ShopTower: wlan2: 00:0B:6A:C1:xx:xx attempts to connect
Jun 2 09:56:06 10.0.0.19 wireless,debug ShopTower: wlan2: 00:0B:6A:C1:xx:xx not in local ACL, query RADIUS
Jun 2 09:56:06 10.0.0.19 wireless,debug ShopTower: send RADIUS request for 00:0B:6A:C1:xx:xx on wlan2
Jun 2 09:56:06 10.0.0.19 radius,debug ShopTower: new request 58:e6 code=Access-Request service=wireless
Jun 2 09:56:06 10.0.0.19 radius,debug ShopTower: sending 58:e6 to 10.0.0.10:1812
Jun 2 09:56:06 10.0.0.19 radius,debug,packet ShopTower: sending Access-Request with id 218 to 10.0.0.10:1812
Jun 2 09:56:06 10.0.0.19 radius,debug,packet ShopTower: Signature = 0x2ef0056525d0e52fcfb1e13037927a0c
Jun 2 09:56:06 10.0.0.19 radius,debug,packet ShopTower: Service-Type = 2
Jun 2 09:56:06 10.0.0.19 radius,debug,packet ShopTower: NAS-Port-Id = “wlan2”
Jun 2 09:56:06 10.0.0.19 radius,debug,packet ShopTower: User-Name = “00:0B:6A:C1:xx:xx”
Jun 2 09:56:06 10.0.0.19 radius,debug,packet ShopTower: User-Password = 0x
Jun 2 09:56:07 10.0.0.19 radius,debug,packet ShopTower: NAS-Identifier = “MikroTik”
Jun 2 09:56:07 10.0.0.19 radius,debug,packet ShopTower: NAS-IP-Address = 10.0.0.19
Jun 2 09:56:07 10.0.0.19 radius,debug,packet ShopTower: received Access-Accept with id 218 from 10.0.0.10:1812
Jun 2 09:56:07 10.0.0.19 radius,debug,packet ShopTower: Signature = 0x93d1b54285fb0db50ae6a990168a6225
Jun 2 09:56:07 10.0.0.19 radius,debug,packet ShopTower: Framed-MTU = 1500
Jun 2 09:56:07 10.0.0.19 radius,debug,packet ShopTower: Framed-Compression = 1
Jun 2 09:56:07 10.0.0.19 radius,debug,packet ShopTower: Service-Type = 2
Jun 2 09:56:07 10.0.0.19 radius,debug,packet ShopTower: MT-Rate-Limit = “128k/256k”
Jun 2 09:56:07 10.0.0.19 radius,debug ShopTower: received reply for 58:e6
Jun 2 09:56:07 10.0.0.19 wireless,debug ShopTower: RADIUS got accept for 00:0B:6A:C1:xx:xx on wlan2
Jun 2 09:56:07 10.0.0.19 wireless,info ShopTower: 00:0B:6A:C1:xx:xx@wlan2: connected


Thanks again,
Neal

4

I believe Rate-Limit only works for PPP connections… You seem to be doing Wireless Client Authentication - it won’t create a queue for that.

Wireless Authentication via Radius only manupilates the Wireless Registration Table…

5

Thanks - can I bother you with a couple more questions?

  • I have also tried using Ascend-*-Rate (the debug output is almost identical, but with Ascend--Rate attributes, obviously). This also dosn’t work (no queue) - is this the same problem?
  • The manual say that Rate-Limit works for PPP connections. My test server sends a Framed-Protocol = PPP attribute, so I would assume that the wireless connections are using PPP. Is this not the case (or ‘what am I missing here’ :wink:)?
  • Having read a few threads, you appear to know quite a lot about these here MT boxes - can you suggest another way I may accomplish this? Your input would be greatly appreciated!

Regards and further thanks,
Neal

6
  • I have also tried using Ascend-*-Rate (the debug output is almost identical, but with Ascend--Rate attributes, obviously). This also dosn’t work (no queue) - is this the same problem?

From the 2.8 Documentation,

Rate-Limit - Datarate limitation for clients (PPPs only).

So I’m definately right about that. Remember though, Wireless Authentication authenticates and manages whether a AP can connect to another AP. A AP has fixed speeds, 1mb, 5mb, 11mb, etc… I highly doubt that telling the AP to only use 64k is going to work. Therefore, I also do not believe that Ascend-* will do what you require.

A queue is only generated for IP traffic. What you are authenticating, is not IP based, it’s MAC based, and therefore IP addresses really does not come into play as far as Wireless Authentication goes.


  • The manual say that Rate-Limit works for PPP connections. My test server sends a Framed-Protocol = PPP attribute, so I would assume that the wireless connections are using PPP. Is this not the case (or ‘what am I missing here’ > :wink:> )?

Will have to check what the RFCs say, but I believe that Mikrotik is wrong to send a Framed-Protocol = PPP on Wireless Authentication. It’s not a PP Authentication request that you are doing to either authenticate Wireless or DHCP. A Wireless connection most definately is not PPP.

It may be that they simply elected to include Framed-Protocol = PPP as a means to hack configurations. It would be extremely difficult to have it authenticate without the precence of a Framed-Protocol, or even worse, if Framed-Protocol = Login (for example).

I’m not sure if MT will take this to heart, but personally, I would expand on the Dictionary…

  • Having read a few threads, you appear to know quite a lot about these here MT boxes - can you suggest another way I may accomplish this?

Well what is it that you wish to accomplish? If you want to authenticate Wireless Cards to connect to your network and manage their speeds without using PPP, then yes, allot of things come to mind…

  • Static IP addressing, with static simple queues (most work)
  • Dynamic IP addressing via DHCP or Radius, with static simple queues
  • Dynamic IP addressing using dynamic queues through PCQ (might be a bit complex)

Ideally… I would simply use Wireless Radius to determine whether a MAC is allowed to be on the network or not, but I would still use something like PPPoE to authenticate users and manage the “IP” part of the connection.

–
C

7

From RFC2865:

5.7. Framed-Protocol

   Description

      This Attribute indicates the framing to be used for framed access.
      It MAY be used in both Access-Request and Access-Accept packets.

   A summary of the Framed-Protocol Attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      7 for Framed-Protocol.

   Length

      6

   Value

      The Value field is four octets.

      1      PPP
      2      SLIP
      3      AppleTalk Remote Access Protocol (ARAP)
      4      Gandalf proprietary SingleLink/MultiLink protocol
      5      Xylogics proprietary IPX/SLIP
      6      X.75 Synchronous

Framed-Protocol should not be send for Wireless, DHCP, or Login via Radius. MT needs to fix this

Instead, I would however send Service-Type

5.6. Service-Type

   Description

      This Attribute indicates the type of service the user has
      requested, or the type of service to be provided.  It MAY be used
      in both Access-Request and Access-Accept packets.  A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Reject
      had been received instead.

   A summary of the Service-Type Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      6 for Service-Type.

   Length

      6

   Value

      The Value field is four octets.

       1      Login
       2      Framed
       3      Callback Login
       4      Callback Framed
       5      Outbound
       6      Administrative
       7      NAS Prompt
       8      Authenticate Only
       9      Callback NAS Prompt
      10      Call Check
      11      Callback Administrative


      The service types are defined as follows when used in an Access-
      Accept.  When used in an Access-Request, they MAY be considered to
      be a hint to the RADIUS server that the NAS has reason to believe
      the user would prefer the kind of service indicated, but the
      server is not required to honor the hint.

      Login               The user should be connected to a host.

      Framed              A Framed Protocol should be started for the
                          User, such as PPP or SLIP.

      Callback Login      The user should be disconnected and called
                          back, then connected to a host.

      Callback Framed     The user should be disconnected and called
                          back, then a Framed Protocol should be started
                          for the User, such as PPP or SLIP.

      Outbound            The user should be granted access to outgoing
                          devices.

      Administrative      The user should be granted access to the
                          administrative interface to the NAS from which
                          privileged commands can be executed.

      NAS Prompt          The user should be provided a command prompt
                          on the NAS from which non-privileged commands
                          can be executed.

      Authenticate Only   Only Authentication is requested, and no
                          authorization information needs to be returned
                          in the Access-Accept (typically used by proxy
                          servers rather than the NAS itself).

      Callback NAS Prompt The user should be disconnected and called
                          back, then provided a command prompt on the
                          NAS from which non-privileged commands can be
                          executed.

      Call Check          Used by the NAS in an Access-Request packet to
                          indicate that a call is being received and
                          that the RADIUS server should send back an
                          Access-Accept to answer the call, or an
                          Access-Reject to not accept the call,
                          typically based on the Called-Station-Id or
                          Calling-Station-Id attributes.  It is

Strictly speaking RFC Style, It needs to be a Login request thus, as we would request the Wireless Client to connect to our host (Access Point). Outbound might be valid as well in this instance, or perhaps Authenticate Only.

Either way, it has nothing to do with PPP, and therefore I believe sending the request as a Framed-Service, is completely wrong.

–
C

8

Good stuff savage.

OK, I think DHCP via radius is probably the way to go for me (I’d like dynamic IP’s, and yes, PCQ seems a bit complex for me right now!!) - I need to read up on the queueing (sp?) stuff first though!!

In case there has been a misunderstanding, my test Radius server sends the Framed-Protocol attribute - its not coming from the MT box (although the MT dosn’t complain about receiving it).

Thanks again for your input on this. experience tells me it is rare to find people willing to help others so freely, but it is these people that make forums like these worthwhile. I am, at the very moment, bowing in recognition of your help (no, really!! :wink:)

At the risk of repeating myself, Thanks Again.

Neal