Hi,
Recently (and currently) busy developing a complete authentication system to use with MT, I came along a good couple of rather strange things. I’ll post them here all in one post, but it will more than likely be to much to tackle in one go - let’s see how it goes.
For now, all of this is based against 2.9.6, I’ll see later about getting a 2.9.19 in production if I can find that hard drive that has the license…
remove command:
Using Radius, I make extensive use of rlm_perl to execute commands on my PPPoE Servers, depending on certain circumstances. Using Net::Telnet, I telnet into the MT.
I cannot execute a remove command, without executing a print command first. i.e.
/interface pppoe-server print
/interface pppoe-server remove <pppoe-username>
The print should really not be neccessary.
Radius Status Page Suggestion:
Can a average RTT be added. Perhaps even the posibility to graph it (similar to a queue or interface). Under large amounts of requests, the last RTT isn’t really TO valuable in regards to information IMHO, and a average based rate would be much better here. It would also add the posibility to perhaps compare the last RTT with the average RTT to determine whether or not there is any abnormally high turn arround times for a RTT.
Radius Page:
Whilst the Timeout value is fairly simple and straight forward, what about the frequency of retransmissions? What is the value of the retransmission rate in MT, and why not have this as a configuration option?
Again, under highly loaded Radius implementations, having a smaller/higher timeout value is not really relavent if you still have a short retransmission period…
Quick example:
Timeout: 3000ms
Retransmission: 50ms (I don’t know what MT configured this as).
In 3000ms, the same packet will arrive at the Radius Server 6 times, before MT decides the packet has timed out. The Radius Server, now has to deal with the same packet 6 times… It can potentionally add a exceptional amount of work on the Radius Servers…
Acct Interm Update in PPP AAA Settings:
The PPP AAA Configuration page, makes provision to specify a Acct Interm Update period. This IMHO is seen as a ‘default’ value. Specifing a Acct-Interm-Update value as part of a Radius Access Accept, does NOT over ride the settings in the PPP AAA Settings. i.e:
PPP AAA Acct Interm Update Time: 00:05:00
Access-Accept in Radius Authentication: Acct-Interim-Interval = 100
MT will still only send accounting updates to the Radius Server every 300 seconds, regardless of the fact that a value of 100 seconds has been specified during the Authentication Process.
On the other hand, the values of the DNS Servers specified in the PPP Profiles, can be over written via Radius via the use of the MS-Primary-DNS-Server / MS-Secondary-DNS-Server, i.e:
set default name="default" local-address=198.18.0.20 use-compression=default \
use-vj-compression=default use-encryption=default only-one=default \
change-tcp-mss=yes dns-server=1.2.3.4,5.6.7.8 comment=""
Radius Access Accept:
MS-Primary-DNS-Server = 5.5.5.5
MS-Secondary-DNS-Server = 7.7.7.7
The client connecting will receive 5.5.5.5,7.7.7.7 as their DNS Servers after authentication.
Thus, why is the one allowed to over write the defaults (DNS), but the other is not (Interm Update)?
Radius DNS Servers:
This was not the case in 2.8.x, it is so in 2.9.6, I’m not sure if this was corrected in the newer versions of 2.9.x yet…
Access-Accept packet:
MS-Primary-DNS-Server = 1.2.3.4
Client receives the address in in-addr.arpa format, being 4.3.2.1. Specify the DNS IP as in-addr.arpa format in Radius, and the client receives it correctly through MT. The attribute’s value, is therefore reversed somewhere inside MT. Debug logs of Radius indicates that the attribute is sent correctly to MT, yet, MT gives incorrect (or reversed) values to the clients.
Mikrotik Radius Dictionary:
Allot of debug logs indicates a mysterious Mikrotik-Attr-9 that is received during a Accounting Update from the Mikrotik NAS. Mikrotik-Attr-9 does not feature inside the MT Dictionary.
Buffer Overflows on SNMP:
Whilst it is general knowledge that MT’s SNMP implementation is only v1, sending a v2 request to MT, will cause the SNMP process to ‘halt’ similarly to what we recently experienced in the Radius Client of MT. This would seem again like a buffer over flow of sorts to me. Tested in 2.9.6, as I indicated in the start of my post.
Broadcast Pings:
Mikrotik responds to Broadcast Pings. If a interface is configured with a IP address of 192.168.1.2/24, and you ping 192.168.1.255 the MT will respond to the ping.
Broadcast pings are often used in denial of service attacks, and is more often disabled rather than enabled, as there is really no need for a broadcast ping. A option inside MT to disable broadcast pings would be gladly appreciated. Things like this on a Wireless Interface can even be worse, as it will consume extremely scarce resouces in regards to the availability of Wireless Bandwidth.
As stated in my post, all of this is based against testing on 2.9.6. My findings are extremely clear however, it should be fairly straight forward to test and confirm these issues against the latest version of MT in some very quick and arb tests.
–
Chris