UBNT Unifi upgrade issues

Recently my best friend installed some unifi access points in his home.  We had ordered a 60W unifi switch, a couple of AP-LR, and a couple of AC-Lites.  These were ordered and sat for several months until we could get around to installing them.  Upon installation, the AC Lites were adopted and had to go through the normal upgrades to bring them up to the latest version.

However, the AP-LRs were used and had very old firmware on them and would not upgrade properly. They would adopt but not upgrade.  We fixed this in the following ways.
1. We Factory reset the APs. At this point, they grabbed DHCP from the local network. Quick ssh into the AP verified it had internet connectivity.

2. I was able to find some old firmware on the UBNT web-site.  We issued the following command to each LR AP

upgrade http://dl.ubnt.com/unifi/firmware/BZ2/3.7.58.6385/BZ.ar7240.v3.7.58.6385.170508.0942.bin

the “HTTP” is important to note.  If you copy the link directly from the UBNT website it has https in it.  The older firmware blows an error due to invalid certs (fixed in newer versions).

Once it came back we were able to upgrade from the controller.

PHPIPAM upgrade 1.3.2 to 1.4 error and fix

Tonight I was upgrading PHPIPAM from version 1.3.2 to version 1.4 and ran into an issue.  After doing a git pull I logged into the web GUI and went to upgrade the database.  I receive the following error.

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'dbversion' in 'field list'

Since I run Webmin, I logged into Webmin and ran the following command on my database

alter table settings add column dbversion tinyint(1);

Once that was executed I was able to go back into the web GUI and upgrade the database.  I ended up with two theme errors which were easily fixed.

You can still upgrade to windows 10 for Free

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin Wilson's Patreon at $0.01 or more
Already a qualifying Patreon member? Refresh to access this content.

RouterOS 7.0Beta4 released on Dec 6 2019

!) included all features and fixes from 6.46 version;
!) implemented completely new User Manager package;
*) dhcpv4-server – added “option-set” parameter for each “vendor-class-id”;
*) dhcpv4-server – added “radius-password’ parameter under “config” menu;
*) dhcpv6-client – allow reading passed options in script;
*) dhcpv6-relay – include client’s Link-Layer address in option 79;
*) interface – improved support for Intel, Mellanox and other generic network cards;
*) ipsec – fixed action=none policies;
*) ipv6 – added “disable-ipv6” parameter;
*) lte – added support for Quectel EC25-E;
*) lte – added support for Sierra Wireless MC7304;
*) lte – improved system stability when resetting modem;
*) package – fixed USB and CD-ROM installs;
*) ssh – improved key exchange algorithm support;
*) system – fixed port duplication on each system reboot;

Network wide Mikrotik RouterOS updates with Unimus

https://unimus.net/blog/network-wide-mikrotik-routeros-upgrade.html

This article will focus on MikroTik – we will show you how you can do a network wide mass upgrade of RouterOS using Unimus, and the RouterOS Package Source feature. What’s even better, doing the entire upgrade process (including setup of Unimus and RouterOS Package Source) can be done in under an hour.

Interesting topic on discontinued gear

So an interesting topic came up on Facebook tonight that got me to thinking. As WISPs grow and evolve, what are your thoughts on hoarding gear you have been using for years when it becomes discontinued? We will examine some ideas as to why this isn’t necessarily all a technical problem. It’s also a philosophical thing with the WISP owner/management.

First off let us examine the whys you would hoard equipment. One big reason is that you have a significant investment in the gear you are using.  This gear has been proven to work, and you have deployed large amounts of it. As a company grows, the ability to introduce new gear into things facing the customer becomes a slower process. To use the analogy, the larger the company grows, the slower the ship turns.

Another reason is the amount of capital needed to migrate to new gear.  Many times when a product line gets discontinued, there is no clear replacement for it. The Facebook post which brought up this post involved the Mikrotik NetMetal 9s.  These are now discontinued by Mikrotik and have no replacement.  If a WISP were to migrate to something else there would be a significant cost in new access points, but more costly, would-be customer CPE. “But just put up the new gear alongside the old and migrate customers over,” you say. This brings us to the next point.

Frequency plays a big role in any migration path. In a perfect world, everyone has open channels and there is no interference. However, that is hardly the case in many scenarios.  This scenario is especially true of 900mhz.  You only have 902-928 MHz to deal with in the US FCC realm.  At 20 MHz wide this is only one non-overlapping channel.   If you put up another access point on 900mhz on top of your existing you will be interfering with yourself. Besides, the frequency may be the reason you are able to reach customers.

Finally, the pros of hoarding equipment are the soft costs of upgrading. Training, engineering, customer service, and possible re-work of some installs can add to the overall cost.  Anyone who has had to change the pins on a reverse polarity Subscriber Module knows the pain I am talking about.

The Cons

The biggest trap I see operators fall into is they horde equipment and then forget about i.  They have spares on the shelves, and enough to service customers. They fool themselves into a false sense of security and kind of wait for something to fall into their laps.  Then, it seems all of a sudden, something happens, and they are scrambling for a solution.  Sometimes this is a software update current equipment gets, but the older stuff does not. This could be some critical security vulnerability or new code to interface with a new system.  Either way, this equipment is stranded on a software island.

Next up is hardware failure.  As equipment gets old it, is more prone to failure.  A WISP may find their reserves depleted after a weekend of storms or bad luck. What may have been plentiful supplies a month ago is now an issue.

Lastly, the performance of the equipment is a big issue.  In today’s bandwidth-hungry consumer ISP radios are needing to perform better and deliver more bandwidth to the customer. Sometimes a manufacturer discontinues a product because they see the limitations of the band or the equipment. Sometimes the manufacturer sees operators are moving on to other ways of doing things. This could be newer frequencies or data algorithms. Usually, it boils down to the equipment was too expensive to make or wasn’t selling well enough.

So whats a WISP to do?

The number one thing a WISP needs to do is not fall into a rut of doing the same old same old for too long when it comes to equipment.  What worked five years ago, may work okay today, but will it work two years from now? Always have a strategy to dump your equipment if need be for something better.  Whether that strategy makes business sense is a different question. Sometimes the approach is to have money in the bank for when the right equipment comes along. Until then, it’s business as usual. Don’t let yourself keep saying you will figure it out tomorrow.

I believe that WISPs should have three lines of thinking.

  1. What am I doing in the immediate future to run my business?
  2. What am I doing in the next 18 months to keep my business competitive?
  3. What am I doing in the next 24-36 months to grow and keep up with customer demand?

If you have strategies for each of these then hoarding equipment is no big deal.  You have plans in place. Just don’t let yourself fall into a false sense of security. Always be learning about new rules, technologies, equipment, and methods.  As your business grows you can delegate this to others, so you don’t have to be in the thick of it and can concentrate on your business.  If you are that “techie” who is doing all of this, keep an open mind.  Don’t be the typical I.T. guy stuck in your ways. None of this is saying hoarding discontinued gear is wrong, just have a strategy.

#packetsdownrange

 

My 3rd WordPress speedup tip

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin Wilson's Patreon at $0.01 or more
Already a qualifying Patreon member? Refresh to access this content.

Another WordPress speedup tip

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin Wilson's Patreon at $0.01 or more
Already a qualifying Patreon member? Refresh to access this content.

Mikrotik 6.45.2 is out

What’s new in 6.45.2 (2019-Jul-17 10:04):

Important note!!!
Due to removal of compatibility with old version passwords in this version, downgrading to any version prior to v6.43 (v6.42.12 and older) will clear all user passwords and allow password-less authentication. Please secure your router after downgrading.
Old API authentication method will also no longer work, see documentation for new login procedure:
https://wiki.mikrotik.com/wiki/Manual:API#Initial_login

*) bonding – fixed bonding running status after reboot when using other bonds as slave interfaces (introduced in v6.45);
*) cloud – properly stop “time-zone-autodetect” after disable;
*) interface – fixed missing PWR-LINE section on PL7411-2nD and PL6411-2nD (introduced v6.44);
*) ipsec – added “connection-mark” parameter for mode-config initiator;
*) ipsec – allow peer argument only for “encrypt” policies (introduced in v6.45);
*) ipsec – fixed peer configuration migration from versions older than v6.43 (introduced in v6.45);
*) ipsec – improved stability for peer initialization (introduced in v6.45);
*) ipsec – show warning for policies with “unknown” peer;
*) ospf – fixed possible busy loop condition when accessing OSPF LSAs;
*) profile – added “internet-detect” process classificator;
*) radius – fixed “User-Password” encoding (introduced in v6.45);
*) ssh – do not enable “none-crypto” if “strong-crypto” is enabled on upgrade (introduced in v6.45);
*) ssh – fixed executed command output printing (introduced in v6.45);
*) supout – fixed supout file generation outside of internal storage with insufficient space;
*) upgrade – fixed “auto-upgrade” to use new style authentication (introduced in v6.45);
*) vlan – fixed “slave” flag for non-running interfaces (introduced in v6.45);
*) wireless – improved 802.11ac stability for all ARM devices with wireless;
*) wireless – improved range selection when distance set to “dynamic”;