This isn’t your typical “rag on Mikrotik” post. I see some frustrations with the Mikrotik process, mainly in regards to getting ongoing bugs and issues fixed. Having a persistent bug continue for large amounts of times tends to make for a frustrating experience. Mikrotik has made leaps and bounds in their Changelogs over the past couple of years, which has been a huge help in the decisions of what software versions to upgrade (or even downgrade) to. But I think things get lost in the process. This results in ongoing bugs, which tend to get unburied if someone makes enough noise.
One of the biggest things I would like to see is a public bug tracking system like Redhat’s Bugzilla tracking system. This would benefit the community as a whole and help users see some of the outstanding issues when they go to implement things. Forums are a great tool, but due to the nature of them, you get a fair amount of mis-information and unrelated chatter. Just because Joe says he is seeing a bug, doesn’t mean he has a confirmed bug. Having a confirmed bug system that has information and able to have moderated comments would be beneficial in many ways:
1.Users with long term bugs they are experiencing or waiting on would be able to keep informed on open status of bugs.
2.Would cut down on the “non-scientific” nature of forums. Information could be specifically submitted in support of a confirmed bug. Bug reports normally include the conditions that need to be met or existing for the bug to manifest itself. Users can then confirm, under those specific conditions, if they are experiencing a certain bug.
3.Bugs that are important to users will get reported more often. This should lead to the more important bugs being upvoted by the community thus getting them fixed earlier. If your particular bug has low numbers you have a reference as to why it’s not being addressed in a timely manner. Companies have to give resources to places they get the most bang for the buck.
Not only would this keep Mikrotik accountable, but it would keep the community accountable. Properly reporting bugs and reproducing them is a process. It takes effort on both the user and the developer. In the end, it makes for a better product.
I have the utmost respect for Mikrotik and their staff. Several folks there I consider friends. I think, before growing pains get too out of hand some sort of additional feedback options would be helpful for the community at large. Mikrotik is getting there. Things like making bug fix versions and release-candidate versions available, along with changelogs has been a huge help for planning and just keeping up on what’s being addressed.
What prompted this was I had a client over the past weekend who started having OSPF issues. Many hours of troubleshooting later, and only talking to some other folks who were seeing the same issues, I was able to determine a specific RouterOS version was to blame. Being able to attach data to a specific bug report, or having Mirkotik open up a new bug based on information I submitted would have been a great help to others. A forum of blog post would have been too general. Forums posts also tend to bring out the “I am seeing that too” and they are not meeting the same conditions you are.
Mikrotik implement a bug tracking system! Bugzilla is even on GitHub.
New Features added:
Release 2.4 adds the following features:
- New ePTP mode operation: The release introduces a new mode of operation for point-to-point configuration providing significantly lower latency than other modes. Not available for DFS bands.
- Improvements to VoIP performance
- Ability to configure the Max MCS independently in each direction
- eAlign: The release introduces eAlign (found under the Tools menu), a tool to aid with link alignment
- Session Time per SM on the AP (under Monitor->Wireless)
- Improvements to the throughput chart on the GUI dashboard (under “Home”)
PDF Release notes can be found at http://community.cambiumnetworks.com/t5/ePMP-1000/New-ePMP-Release-2-3-1-now-available/m-p/37067#U37067
o RFC1213 supports standard interface MIBs. Items such as Ethernet interface Tx/Rx and
corresponding stats are now supported per the standard RFC. This allows users to utilize 3rd party monitoring tools that support RFC1213
• Separate Management IP when SM is in NAT mode
o Separate Wireless Management IP will provide the ability to separate management traffic from user traffic when the SM is configured in NAT mode providing separate management access to the SM. This includes the ability to have a separate management interface when PPPoE is enabled on the SM.
• ARP table display
o Displays all the ARP entries for interfaces present in the routing table
• VoIP helper functionality under NAT
o When the SM is in NAT mode, ePMP inspects SDP packets and automatically creates appropriate