The Radius NAS Port number in a Accounting Request is a huge number and is going negative on my Radius server resulting in a crash of the server when login from MT router.
I have been using Colubris MSM311 for years now want to use MT. All is working via external radius apart from the huge number
Is there any way I can either change the NAS PORT format or even specify it on the router
Which attribute? NAS-Port is only used in Access-Requests, not Accounting-Requests:
http://tools.ietf.org/html/rfc2865#page-30
5.5. NAS-Port
DescriptionThis Attribute indicates the physical port number of the NAS which
is authenticating the user. It is only used in Access-Request
packets.
Yes I saw that and set it to 1 ( a configurable parm )
Here is the accounting request with big NAS-Port number
16:33:54 radius,debug,packet Signature = 0x2ca67a737acfefad79ecb67964b557b3
16:33:54 radius,debug,packet Acct-Status-Type = 1
16:33:54 radius,debug,packet NAS-Port-Type = 15
16:33:54 radius,debug,packet Calling-Station-Id = “00:03:47:7D:09:E5”
16:33:54 radius,debug,packet Called-Station-Id = “hotspot1”
16:33:54 radius,debug,packet NAS-Port-Id = “ether2”
16:33:54 radius,debug,packet User-Name = “m01”
16:33:54 radius,debug,packet NAS-Port = 2159018249
16:33:54 radius,debug,packet Acct-Session-Id = “80b00109”
16:33:54 radius,debug,packet Framed-IP-Address = 172.16.5.252
16:33:54 radius,debug,packet MT-Host-IP = 172.16.5.252
16:33:54 radius,debug,packet Class = 0x5376633d3431
16:33:54 radius,debug,packet Event-Timestamp = 1282318429
16:33:54 radius,debug,packet NAS-Identifier = “S205”
16:33:54 radius,debug,packet NAS-IP-Address = 172.16.2.35
16:33:54 radius,debug,packet Acct-Delay-Time = 5
This is what its doing to the radius server - NAS Port has rapped round to negative - radius server crashes
08/20/2010 16:33:46 Receive: Request from host 188.223.88.141 code=1, id=26, length=171
08/20/2010 16:33:46 NAS-Port-Type = Ethernet
08/20/2010 16:33:46 Calling-Station-Id = “00:03:47:7D:09:E5”
08/20/2010 16:33:46 Called-Station-Id = “hotspot1”
08/20/2010 16:33:46 NAS-Port-Id = “ether2”
08/20/2010 16:33:46 User-Name = “m01”
08/20/2010 16:33:46 NAS-Port = -2135949047
08/20/2010 16:33:46 Acct-Session-Id = “80b00109”
08/20/2010 16:33:46 Framed-IP-Address = 172.16.5.252
08/20/2010 16:33:46 Vendor-Specific = “\00\00:\8c\0a\06\ac\10\05\fc”
08/20/2010 16:33:46 User-Password = “\07bES\8ah-\94H\d4\10\c4\b3\f5%\c5”
08/20/2010 16:33:46 User-Service-Type = Login-User
08/20/2010 16:33:46 Vendor-Specific = “\00\007*\03\1bhttp://172.16.2.35/logout”
08/20/2010 16:33:46 NAS-Identifier = “S205”
08/20/2010 16:33:46 NAS-IP-Address = 172.16.2.35
08/20/2010 16:33:46 Sending Code=2, Id=26 to 188.223.88.141
08/20/2010 16:33:46 Class = “Svc=41”
08/20/2010 16:33:46 Idle-Timeout = 900
08/20/2010 16:33:46 Session-Timeout = 3600
08/20/2010 16:33:46 User-Service-Type = Login-User
08/20/2010 16:33:46 Mikrotik-Recv-Limit = 150000
08/20/2010 16:33:46 Mikrotik-Rate-Limit = “200k”
08/20/2010 16:33:46 NAS-Port = 1
08/20/2010 16:33:46 Port-Message = Access Accept
Further to this, on the Colubris controller we get NAS-Port 1 for first login, NAS Port 2 for second login etc. This large Port number from the Mikrotik is not actually a meaningful number which its meant to be, ie: the port number taken by the user. In Colubris and Proxim this is incremented for simultaneous logins so you have a unique incrementing number for each smultaneous login and reaches the highest number of sumultaneous logins then goes back to 1 as users logout.
ON the radius server we have this option:
hmmm… what version of ROS do you use? and what uptime do you have?
on our 3.28, with 13d uptime we have current NAS-Port=183936
so we need about 400 years of uptime to get NAS-Port = 2159018249 %)
and yes - NAS-Port for me starts from ~66000 and increments sequentially. actually, NAS-Port is .id of the ppp interface:
:put [/interface pptp-server find];
Its 4.5 on RB433
Uptime can be 1 minute and we still get the huge number
When I started testing I did not have any extended radius working. It worked fine then and did not get the huge number if thats any help
I will try to revert to initial setup and see if it goes back to smaller number
I am using hotspot and radius features
This is also a problem when using Microsoft IAS for authenticating. I’ve already sent an e-mail to support, requesting that this value could be changed.
I have a serious compatibility problem between RouterOS and Microsoft IAS radius server.
I've setup a hotspot on a mikrotik device, and want to authenticate users with a remote microsoft IAS radius server.
We managed to find the roots of the problem.
Mikrotik uses a very high NAS-port number in the authentication packet, 10 digits starting with 21xxxxxxxx. This value is somewhere around 2^31. E.g.: 2152726529.
This is also confirmed by Normis here http://forum.mikrotik.com/t/radius-nas-port/7290/1
The problem we have is that IAS is unable to log this large number. So if we have enabled logging on IAS, login fails with "RADIUS server is not responding".
But if we disable logging on IAS, login is successful.
Same thing described here http://forum.mikrotik.com/t/radius-nas-port/7290/1
There is no way to change logging settings on the IAS server, since it is a ~10000 user campus server.
I've tried to change NAS port type in the mikrotik hotspot server profile, but the values are always in this high range.
I'd like Mikrotik to add a feature to change the range of the NAS port. Right now I have to report this as a bug, since every other hardware we have is compatible with IAS.
This is really important, because we'd like to use several Mikrotik routers and APs instead of expensive ones like Cisco, but this problem prevents us from doing so.
The problem exists on 4.11 and 5.0b5 also (but I guess it is version independent).
There is a ticket #2010080266000278
Support replied that they see what they can do, so basically nothing promising.
Let’s hope we will see some improvement in the next v5 beta (:
Yep, this is a big problem
I am looking to abandon use of Mikrotik as a hotspot radius device, shame because we had lots of hotel hotspot sites to deploy using them.
Back to HP I suppose unless anyone knows of an alternative ?
Looks like this is a bug to me, 2^31 is the upper limit of an integer range, someone has done some bad coding.
Maybe if this came out as an urgent patch there may be a sudden increase in Mikrotik sales
Just tried V3.3 and still same problem
I wonder how many sales Mikrotik has lost due to this problem. Its not going to the small implementors as they are less likely to need external radius, Its going to be the big players who have not been able to use Mikrotik.
Come on Mikrotik, sort this one out as a matter of urgency !!
well, according to http://tools.ietf.org/html/rfc2865#section-5.5 , there’s no limitations on NAS-Port value - it’s just four octets. so, it’s a bug in your RADIUS implementations.
and yes - [2147483648..2164260863] for hotspot users is not very good choice due to those buggy RADIUSes =) so just a feature request - either make Hotspot users have .ids in the same space as usual interfaces (1 and up), or at least change value range to the upper block of signed integers… the former is better, IMHO
greenman, have you opened up a support ticket? The forums MAY be read by support staff, but the official channel is support@mikrotik.com.
Yes, someone else opened a ticket. Multiple ones would still be a good idea so they can internally measure that it affects multiple clients.
And for what it’s worth, I use Hotspots extensively with RADIUS with FreeRADIUS as well as an appliance by A10 and they both work fine for all authentication and accounting purposes. As Chupaka posted, the RFC specifically allows for this.
Ok thanks for pointing this out Chupaka and fewi
The system we use is a bit old and we have found some discrepancies with the RFC’s but there are now 2 sizable radius network operators with this problem and to use MT we have to turn off logging which puts us in the dark when it comes to troubleshooting.
Both the other operator using Microsoft Radius and ourselves found Radius Authentication and Accounting with big NAS Ports numbers was not THE problem but logging the radius transactions to a flat logging file caused the crash. So in both instances the implementor of the logging facility assumed an unsigned integer was sufficient. I will post a “Feature” request with the hope that it will be considered a relatively quick change to implement for immediate benefit to larger organisations using MT
We have migrated our Radius server to Linux and the problem has gone away
Looks like its a microsoft issue