Mikrotik Router OS "Gotchas"

Mikrotik Router Operating System "GOTCHAs"
by Joe Mehaffey    (updated 12/23/2003)

I have received comments from users (and experienced myself) a number of things in setting up a Mikrotik OS HotSpot router that cause a lot of wasted time. I have documented the worst here so as to (hopefully) help keep others from falling into the same traps.

1) The Mikrotik OS is only modestly well documented and Mikrotik has less technical support than many users expect for a production software product. The 400+ page manual is detailed, but more of a reference guide for the knowledgable router programmer than a tutorial.   They are getting a little better with more and more applications guides and examples in the manual, but getting detailed answers to most any technical question directly from Mikrotik is can be difficult at times. Yet, the Mikrotik software is generally well designed, robust (more or less), serviceable, generally reliable (but not well tested at the factory), and inexpensive. For these reasons I have written my HOTSPOT SETUP PROCEDURE to assist users in getting an initial system up and running.. I am hopeful that Mikrotik will soon realize that a quality product like the Mikrotik OS will sell A LOT better if it is accompanied by quality support. The other side of the coin is that their support costs will go down when they get good documentation.    Several users say they would not mind paying double the price Mikrotik charges IF they would improve software stability and quality and improve their technical support.
2) Mikrotik's "ChangeLog" is cryptic and apparently includes only a fraction of the changes actually made from version to version. Mikrotik tells me that it would be too much effort to make the changelog accurate. (Sounds like some software engineers I have known!) Sometimes command syntax changes are made which are not chronicled until users ask why a command will not work. If a command syntax fails to work, Check the ChangeLog on the Mikrotik website. If the answer is not there, you may have to contact Mikrotik Tech Support to get the correct syntax.
3) Related to #2 is the problem of incomplete command syntax information in either the manual or in the OS command listing. Commands often have "unpublished" features and options that turn out to be very useful but that are (seemingly) documented nowhere but in the Mikrotik programmer's memory. The moral of this story is: If you cannot figure out how to do something, ASK. You likely have a 75% chance that there is a feature to do what you want even if it is not addressed in the manual.
3) If you use FIXED IP ADDRESSES for IP/Gateway/DNS server on the Mikrotik Router port going to the internet, you MUST point to some actual DNS server or to a router that offers DNS Caching. The Mikrotik OS fails to resolve DNS requests sent to some routers which offer "DNS Relay" services (such as the Hawking FR24). This can result in confusion in new users who cannot figure out why they can PING the internet but cannot get a URL to come up in their browser unless they put in an explicit IP address for a URL.
4) If you use the Mikrotik UNIVERSAL CLIENT so as to be able to allow visitors with "ANY" IP address/gateway/dns setup to log into your Hotspot without making networking IP changes (a very nice feature!), then simple 802.11 REPEATERS such as in the Dlink DWL-900AP+ will not work. You get to pick which operational feature you like best.
5) Mikrotik software versions below 2.7.11 and 2.8beta1 through 2.8beta4 do not support the Mikrotik HotSpot unless you are a PAID license holder. Versions 2.7.11 and up and 2.8beta5 and up DO support the Mikrotik Hotspot with a DEMONSTRATION license.
6) If you setup your IP DHCP address pool to less than the full domain range (such as 10.5.50.2-10.4.50.199) then later versions (maybe all??) of Mikrotik OS will not allow clients with fixed IP addresses outside this range (say 10.5.50.223) to login UNLESS the Hotspot system is setup with the Universal Client feature. I hope they fix this! It does not seem that failing to recognize clients who happen to have a fixed IP address outside the DHCP range is a desirable "feature".
7) If you setup Hotspot Clients with FIXED IP addresses and use the universal client, then these addresses are NOT pinged by the HotSpot "keep-alive" timer. As a result, and regardless of the Hotspot inactivity timeout setting, these FIXED IP address clients will be removed from the Hotspot's ACTIVE list after about 5 minutes of inactivity (or whatever you set) . (Inactivity means no data packets have been sent to/from this client.) This means that these clients will have to be relogged in frequently. The solution? Use DHCP in the client machines. This has been reported and hopefully it will be fixed in some version beyond 2.7beta6.
8) A related problem to #7 is that if you decide turn Universal Client OFF and to have FIXED IP addresses which are INSIDE the hotspot DHCP range, then you will find that "occasionally" the hotspot's DHCP Server passes out these FIXED AND OPERATING ON THE LAN IP addresses to some client requesting that DHCP furnish an IP address.   Apparently this is because the hotspot's DHCP server only considers an address "leased" if a user has logged in. (Or maybe things are more complicated.) But in any case, it is currently not possible to insure that IP address conflicts will not occur if you use fixed IP addresses on a hotspot's wireless LAN INSIDE the DHCP server's IP pool range. Unfortunately, some wireless clients and bridges REQUIRE a fixed IP address so you can easily find them for maintenance services. Hopefully, Mikrotik will come up with a fix for this soon.

Often, for administrative reasons, it is desirable to have APs, bridges, repeaters, and such have fixed IP addresses. You can do this as long as you use DHCP for all client machines which require DNS and gateway services. Be SURE that your root APs connected to the Mikrotik use DHCP -or- have a fixed IP address INSIDE the Mikrotik Hotspot's DHCP server's IP range. Otherwise, clients cannot always get DNS services.
9) Another DHCP related problem in hotspot is that (in version 2.8beta6) if you set up the DHCP address range of 10.5.50.50-10.5.50.254 and have fixed IP addresses in the range below 10.5.50.50, -and- you have Universal Client turned ON, then you will find that some people attempting to login cannot get service. This may be somehow related to #8.
10) Automatic MAC address login normally requires that you input the MAC address of the particular computer you wish to have automatically login as both the USER and the PASSWORD in the Winbox>IP>Hotspot>User> (+) Add User setup entry. However, if you use any sort of external wireless client device(bridge) with a particular computer and plug the wireless client into the computer's LAN card, you have to do more. In this case, you must enter BOTH the MAC address of the computer itself AND the MAC address of the Wireless Client Bridge into the above user table or you will not get automatic login. This applies to such devices as the LinkSys WET11, Dlink 900AP+ (operating as a client bridge), and similar. A bug I have noticed is that "Automatic MAC logins" are not shown in the Hotspot ACTIVE list. (2.8beta6)
11) During October/November/December 2003, Mikrotik has gone through a period of extremely frequent software revisions caused by a steady stream of fairly serious software problems. I installed 2.8beta6 in my working hotspot about October 2003 and it has been a pretty stable performer. I have tried copies of 2.8beta7 through 2.8beta12 and have not found a single stable performer in the group.   Mikrotik is now recommending I drop back to 2.7.18 (which 2.7.x has had its share of problems and does not offer all the features I need) . I plan to try this one out and I will report if it appears to offer a stable platform.
12) Mikrotik has a two piece software security ID/KEY to protect their product from theft. This system has turned out to be extremely cumbersome and difficult to use causing a tremendous amount of time waste. I would MUCH prefer a hardware "dongle" type key. For example: a) Sometimes software gets flaky and you want to reload the software (not just the configuration). You are not allowed to do this without loading from scratch and getting a replacement key from Mikrotik. b) The system will not allow you to DOWNGRADE to an earlier version when something is found wrong with an upgrade version unless you go install from scratch and go to Mikrotik for a replacement key. c) If you have a paid for ID and KEY (goes with a disk drive) and you install a floppy based system to try and evaluate the new software, you have LOST YOUR KEY and you have to go back to Mikrotik for a replacement.    d) Even if you use NETINSTALL (which requires a key to use), and you want to load software on a unit for test and/or use, the software is not smart enough to go and get the key off the running system. You have to obtain a replacement key from Mikrotik.    There are some pretty obvious and workable solutions to these time wasters, but Mikrotik apparently has not recognized these customer time wasters or the difficulty these issues present in recovery from a system failure.
13) As you move from one software edition to another or between versions, you MAY find that the particular NIC cards identified as ether1, ether2, ether3 and etc. have "changed places". This can lead to a fair amount of confusion if you find that the NIC card that WAS ether1 (say the connection to the Internet) is ether2 (the hotspot interface to your external AP) after you upgrade your software.   To be sure, don't fail to perform the port tests suggested in the Mikrotik Setup document EVEN IF the software is just being upgraded.
14) Mikrotik makes "running user interfaces changes" between versions without any notice to users. The changelog generally will not mention that "so and so" command(s) have been changed/moved and the old command(s) will no longer function. This also applies to configuration backup file from an older configuration which can cause the backup file not to be workable when an update version is loaded. Such changes are generally not mentioned in either the version changelog and corresponding changes in the manual may not be mentioned until the next major software edition. This process can make a configuration file that worked fine in one software edition fail to operate at all in when you try and use the same configuration in the next software update in the same software edition. A routing system may be extremely complex and you may not have anything to work with except the backup file which cannot be used in ANY other machine except the one it was generated on! Couple this with the fact that when you encounter this problem, you may have just had a hardware failure. It may be quite awhile before Mikrotik gets back to you with a fresh software key so you can back up to your prior software and you can have quite an emergency situation on your hands.
15) So you decide that to avoid urgent problems, you are going to make up a "clone" system IDENTICAL to your existing Mikrotik system so as to be able to maintain an identical backup system at all times. This is a good idea, but you had better be SURE the hardware is absolutely identical all the way down to theMAC addresses of plug in NIC cards, wireless cards and etc. If the computer is not identical or (for instance) the NIC cards are not identical or from different manufacturers, then likely the systems cannot be made to work with each other's configuration files. I believe Mikrotik must key the configuration files off the hardware MAC addresses and such instead of using the logical name (such as ether1). And so, I am not sure but do not believe that two systems can be made to be 100% compatible as to the backup configuration file as MAC addresses will differ between units. I have not been able to get any scheme to allow me to overcome this problem. Obviously the way to handle backup files to allow a user to keep a "hot standby" would be to have two configuration backup elements. The first would backup details of hardware configuration. This part would be "hardware specific" to the particular computer platform used. The second would backup "non hardware specific" routing tables, hotspot data, and etc.   By these means, a user could first set up his hardware configuration, save this and then be able to load his "router specific" and "hotspot specific" and "user specific" features via a backup file which would function on any identically equipped hardware platform but with the hardware specific backup file from this second hardware system. Mikrotik has no such capability so you must manually build and maintain any second system. There are EXPORT/IMPORT features to assist but you must use care as sometimes it is not obvious which of these include some hardware specific items.   Perhaps Mikrotik could simply provide a script file to export/import and thereby generate a method of "cloning" a configuration to another computer system.
16) If a user tries to login on (even) a (simple) 2 port hotspot system, there is about zero troubleshooting aid. If the MT loses the internet link, it will not even put up the login screen but will simply give you a windows error message: "could not connect to http://www.yahoo.com" or similar. . (This is supposed to be changing soon in v 2.8 so that the login screen will be capable of display even if the internet connectivity beyond the router is lost.) Needed is a simple connectivity and troubleshooting display screen in winbox to show the existing logical connections and at least give a hint of link defects without having to resort to detailed external testing which can be tedius and time consuming.   Many times even detecting that problem exists where multiple incoming/outgoing links are involved can be a problem according to reports from users.