Category: Uncategorised

We are in the process of shredding our paper records from twenty years ago, stuff like tax returns, invoices, insurance papers that are no longer relevant or needed.

During this paper demolition process, I came across this invoice from 24 years ago!

A Windows 95 PC costing over $4,500 in 1998 money. Wow. I did not realize I had such an appetite to spend that much money back then.

Notice that we were still using dial in modems back then. No high-speed internet yet. Most motherboards did not come with sound and video either. I also have to laugh at the hard drive specification. At 8.4 GB, that would be smaller than most USB flash drive you can now get at Staples.

Fascinating walking down memory lane!

This year on January the 31st, I purchased a gold bar from TD Canada Trust. It is one ounce for $2,414.67. The idea is from my wife. She wanted to establish a new trend as her annual birthday gift.

As the kids are grown up and our RESP savings are being maxed out. the redirection of funds to accumulating gold may not be a bad idea. The world has become a more unpredictable place, the pandemic, and growing geopolitical issues.

This morning I was curious and check the price for the same one ounce of gold and it is sitting at $2,540.03. Already up in about three weeks.

We will continue to monitor to see if this is indeed a good long term investment.

At this point in time, all of our family members have our first dose of the Pfizer vaccine, and we are awaiting our second dose. As the Delta variant of the Covid-19 vaccine makes its way around the world, numerous reports are indicating that those who only have their first dose are only 33% protected from this variant.

Of course knowing this fact creates an a certain anxiety and urgency to get our second dose. Although we all have our second dose already scheduled when we got our first dose, those original schedules are weeks away. York Region today from 8am started taking appointments for rebooking second doses. This is of course very welcoming.

Unfortunately, as expected the scheduling web site experience leave very little to be desired.

I visited the site at around 7:50am, and it told me that I was in line and I had a 10 minutes wait. At this point, it is very reasonable, since it officially starts at 8am. I took the screen shot above, and as you can see the waiting time hasn’t really gone down and we have already passed our initial 10 minutes. To make matters worse, at around the 5 minutes mark, it immediately presented the booking form.

My sons who visited the site at 8am sharp got a waiting period of 1 hour. You can see how discouraging for some can be. Never mind vaccine hesitancy, it is these types of frictional booking experience that probably also discourages people from getting their doses. I really don’t understand why it is taking the organization so long to get there act together. Perhaps I’m being too harsh.

On the plus side, I did finally manage to book all members of my family for our second dose, because the site did allow me to make multiple bookings without having to virtually re-queue.

I have the following Unifi networking setup:

• Unifi Secure Gateway (USG-3P) running 4.4.55.5377096 firmware
• 3 Unifi Access Points AP-AC-PRO running 4.3.28.11361 firmware
• 3 Unifi AP-AC-M running 4.3.28.11361 firmware
• Unifi Controller (6.2.25) running on Ubuntu
• The AP’s are connected to Unifi Switches running 5.43.36.12724 firmware

The AP’s are separated into two AP Groups. One of the AP Groups contains the 3 AP-AC-PRO and one of the AP-AC-M. This latter group was the problematic group. The other AP Group which contains the remain 2 AP-AC-M continue to work flawlessly throughout incident. From here on when I reference an AP Group, it is the problematic group that contains the 3 AP-AC-PRO and 1 AP-AC-M.

It all started yesterday when I noticed that my WiFi was a bit slow in the backyard and I wanted to change my radio configurations on one of the AP-AC-PRO and one AP-AC-M in the same AP Group. After the provision, the AP went disconnected as shown by the controller.

I ssh into the problematic AP-AC-PRO and discovered in /var/log/messages that there were many instances of the following log entry:

syswrapper: [state is locked] waiting for lock

I attempted to reboot the device but the device remained in the same “locked” state.

Since it is inconvenient for me to physically reset the AP, I attempted to reset the device via ssh using the command:

syswrapper.sh restore-default

Unfortunately, this did not always work because it immediately just shows the same locking message:

syswrapper: [state is locked] waiting for lock

I had to reboot the device via the command line reboot. As soon as I can ssh into the device after reboot, I immediately execute the restore command as above. This took a lot of trial and error because my timing is often off. When I miss the window, I will get the lock message again. I find that my chances are higher if I first forget the device on the controller first.

A quick suggestion to the Unifi team. It would be nice that the restore-default command if not able to restore immediately due to the lock, would at least set a flag in persistent flash memory of the device so that on the next reboot it will perform the restore then. This feature will safe me A LOT OF TIME!

Once the device is reset to factory default I proceeded to reconfigure it to the WiFi networks that I had. Unfortunately, when I try to provision the changes (adding the re-adopted device back into its original AP Group that is associated with the WiFi networks), it went into the disconnected state again. To make matters worse, the other AP’s in the same AP Group started to misbehave. Some would go into a provisioning state and followed by a disconnected state, while others go into an adopting state. This is of course very unnerving and frustrating. However, this observation lead me to remember a previous episode that I experienced a few weeks ago.

When I updated the controller to 6.2 and upgraded the AP’s firmware, the AP exhibited a similar locking issue. The solution that I employed was to restore to factory default and re-adopt the device. However after readopting, I assigned the AP to a brand new AP Group which I associated with the original WiFi networks. Simply adding the device to the original AP Group did not solve the issue.

When I tried this solution yesterday, it did not work. The device continues to go into a disconnected state immediately after provisioning when I added to the new AP Group. After many hours and much experimentation, I decided to erase all the WiFi networks and the problematic AP Group. I recreated the WiFi networks, and created a new AP Group and proceeded to add each AP one by one (after a reset to factory default). In summary here are the final steps that got me out of this pickle:

1. Forget all AP’s in the affected AP Group.
2. Remove all WiFi networks from the AP Group.
3. Delete the AP Group.
4. Delete all the WiFi networks that was associated with the above AP Group.
5. Re-create all the WiFi networks and associate with a brand new AP Group.
6. For each AP, use ssh to reset to factory default, adopt, and add them one at a time to the AP Group using the controller web UI.
7. Since there were four AP’s (3 AC-Pro and 1 AC-M), I waited until the AP is fully connected and can service WiFi clients before I continue with the next one.

I am documenting this so that I can share with Unifi support. This has happened twice now, and each time I spent multiple hours to try to get my WiFi network working. In these pandemic times, WiFi is as important as electricity and plumbing. Since Tier-1 support was unable to resolve this issue, waiting for Tier-2 support (around 24 hours) is a bit “hard to swallow”.

Any ways I am glad that I was able to resolve this and brought my WiFi networks back up and running with the 4 affected AP’s, FOR NOW. However I must admit, these two episodes have made me apprehensive of making configurations to these AP’s, thinking that the next provisions will result in many more lost hours.

I hope the Unifi team can use this information and see if there is an issue relating to AP Group provisioning, since this seem to have triggered the issue in both cases.

Today my wife and I got our first dose of Pfizer BioNTech Covid 19 Vaccine after probably more than 14 months since the first lock down notice from 2020. Of course it is still too soon to declare victory, as our second dose is still scheduled 3 months from now.

On a related note, the Ontario government has also declared the AstraZeneca vaccine will no longer be available as a first dose: “the decision was made out of an abundance of caution.”

I can’t help but think that this sounds a bit contradictory to what the government was peddling a few weeks ago. It kind of makes you think whether their 3 months guidance between the two doses of mRNA based vaccines is warranted and backed up by facts or not.

Regardless, this is another case of inconsistent information provided by our institutions. It certainly will continue to chip away at the credibility of the same institutions.

I hope we learn something from episodes such as this. In the meantime, both of our sons, who are age 17 and 16 should also be eligible for Pfizer or Moderna soon. We are now just monitoring our local clinic schedules to see when they can be booked. Fingers crossed, and three months cannot come soon enough.

The story continues in the media: