Become a Patron to see this content
To unlock this content, pledge $1 or more on Patreon
I have always been a firm believer in re-evaluating yourself on a regular basis. Take a look at yourself, your behaviors, and your quirks. By doing this, you can uncover weaknesses you. Read to work on, but also build on your strengths.
Case in point. I am in the process of rolling out wiki software for many clients. This software deployment will be a cookie cutter rollout, with customizations for each client after the initial implementation. I am behind on this for one big reason. Fear. Now, this is not Michael Meyers standing over your bed fear. It’s a fear of choosing the wrong platform. I have evaluated several wiki packages and talked to several people deploying each of them. Like most things, they have strengths and weaknesses. The fear breeds indecision. Is there something out there which I haven’t found that is better? Is there a better way or a way I haven’t thought of to accomplish what I am trying? The answer to all of these is probably yes.
How do you not fall into the trap of indecision? Couple of things you can do.
1. Before anything like this sit-down and write out the problem you are trying to solve. In my case with the wikis, I needed something to keep track of not only documentation but the odds and ends notes.
2. Write down what would help solve the issue. In my case an online repository of information.
3. Create a list of ways to solve this problem. This step may involve research. What are the software packages out there to address my issue? Are we utilizing anything today which could resolve this issue?
3. Once you have done some research formulate the must needed features in your solution. From there prioritize them.
4. Many people start to break down during this stage. Whether it is getting overwhelmed from the sheer amount of choices or thinking every feature is needed. The decision process begins to grind to a halt rather quickly. How do you overcome this? First, be realistic, how many of the features do you really need to accomplish your goal? Out of the features left, what does it take to implement them? How many times have you deployed a software tool and are only utilizing a fraction of the tools available? This happens quite a bit.
5.Set a hard time to make a decision. Tell yourself you have ten business days to research and come up with the solution. Once you have made the decision, have a rollout plan in place. This plan should include a timeline of start and finish. This way you don’t start to second guess yourself and drag your feet even more.
This method is not a foolproof way, but it will get you to implement more things than you are now.
Do you have a Quanta Lb4M and are looking for software? Check out this site:
I will grab these files and if this site ever disappears will mirror them if anyone asks. Until then use the above link.
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:
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