Dongles everywhere!

In the last few revisions of the MacBook and MacBook Pro, Apple has replaced the legacy ports with USB-C ports which some think is forward thinking and others complain that their devices don’t connect. Last fall, when the last MacBook Pros were announced, I was eyeing one, but ultimately decided against buying one. However, when Apple had a sale on the dongles to placate people, I thought about what I would need for my next computer. I bought a USB-C to Thunderbolt 2 adapter and a USB-C to USB-A adapter.

Fast forward to last month when Apple announced the 2017 MacBook Pros and I decided that it was time to replace my almost 5 year old MacBook Pro. I again, had the option to purchase dongles, but decided the 2 I had were all that I would need. My current setup is 2 27″ Thunderbolt displays that each have 3 USB-A ports, FireWire 800 and a Thunderbolt port. With only the USB-C to Thunderbolt 2 adapter, I’m able to hook up my MacBook Pro to 1 display (second display is daisy chained) and all my devices work. When I travel, I can bring the USB-C to USB-A adapter in case I need to use a card reader.

While I may not be typical in my setup, basically 2 dongles are all I need to make my new computer hook up to all my legacy devices; this is really no big deal. Next year, however, when/if Apple releases its own displays again, they will unlikely have legacy ports. At that time, I’ll get a few USB-C to USB-B cables for my scanner and hard drive dock and a few USB-C to USB-A adapters to hook my Lightning cables; total cost for all this will be maybe $30 and the cables/dongles will always be plugged into the display. Nothing to lose and a minor cost to move forward.

I’m not sure why there was so much uproar in the Mac community about getting rid of legacy ports; to me this is a much smaller deal (if any) than moving from 30 pin to Lightning because of the shear number of devices and cables I have lying around the house.

Review: ZTE Mobley

Several years ago, I worked for a company that sold Sprint service. As part of my job, a “perk” was a company issued phone and then when the MiFi mobile hotspot was released, I got one of them for experimentation and use. (I use perk lightly because having a company issued phone or device is more of a tether keeping you connected all the time.) When I left the company in 2010, my boss said that I could use the company discount to purchase a device and plan; I purchased a MiFi and had a $45/month plan for 5 GB of data. After about a year, I realized that I wasn’t using the device much and cancelled the plan.

For the most part, I haven’t had a need or desire for a mobile hotspot and my iPhone’s mobile hotspot has worked fine when I needed it. Over the last year or so, I’ve heard advertisement after advertisement about “built in 4G/LTE” in cars which seemed like a way just to keep the kids in the back quiet and I ignored the ads. Earlier this year, I saw that AT&T was dropping the price of their “Connected Car” plans to $20/month for unlimited data (22 GB, in reality and then de-prioritization). Now things were starting to get interesting in pricing.

AT&T offered this plan on cars that had built in cellular, as well as with the ZTE Mobley which plugs into a car’s OBD-II port. The only problem with this, for me, is that I have an Automatic plugged into the port and only being able to use the device in the car had limited utility. Luckily, I read on forums that people were buying adapters to plug it into USB or AC. Since the cables looked like someone hand made them, I decided to make my own so that I could choose the parts. I picked up an OBDII Connector Cable Pigtail and a 5v to Dc 12v USB Converter (I picked this one because any heat generated from the electronics wouldn’t be right at the end of the cable). I soldered the pieces together and had a USB to OBD-II power cable.

I purchased the Mobley outright ($99) with no activation fee. When it arrived, I plugged it into my cable and into USB and it powered right up without problems. My first few uses of it were when I went to the car dealer and had to wait around; I plugged it into a USB battery (at peak power consumption, it uses something like 700 mW). It performed quite well and I got acceptable speeds without having to worry about jumping on an unknown WiFi network and dealing with my VPN.

The next test was when we drove about an hour to go camping; my wife was in the passenger seat and my son was in the back seat. My son had an iPad and was entertained for the trip. My wife started out the drive just saying that she would use her phone, but about 10 minutes down the road, she asked my son to hand up her iPad. From that point on, I think the hotspot gained a permanent place in our longer car rides! This past week we went on a driving vacation and covered about 1500 miles. The hotspot powered up when the car started (it was plugged into one of the USB ports; my car has 2 USB ports, but I bought a 2 port cigarette lighter to USB adapter, so I had a total of 4 ports) and was available wherever we had AT&T coverage which turned out to be maybe 75% of the total time in the car.

In one of the hotels we were staying, I was able to get over 20 Mbps down which to me is amazing considering my first cable modem was 5 Mbps down and the first cellular data links I worked with at QUALCOMM were 9.6 Kbps.

Screen Shot 2017 07 19 at 8 49 03 PM

While $20/month seems like an unnecessary expense for times that I won’t use it, I can justify the expense.

Pros

  • Easy to use (just plug it in and connect to WiFi).
  • Coverage wherever AT&T has coverage.
  • Hard to use up 22 GB a month in normal usage (we used about 17 GB on our last trip and that was using it in the car and hotel).
  • Device is reasonably priced ($99).
  • Monthly fee is reasonable ($20/month).
  • Automatically turns on when power is applied.

Cons

  • Have to buy or make a cable to use outside of the car.
  • Limited to 5 devices at a time. This seems like a lot of devices, but we had a total of 6 and some devices always stay connected to WiFi causing me to have to block/unblock a device).
  • Doesn’t support carrier aggregation which would support higher data rates.

Summary

As much as I didn’t want to think that a mobile hotspot would fit into my usage, it has proven to be an excellent device. I’m sure that my review (except for the auto power on) would be the same with any mobile hotspot, but the price of the device and the price of this plan make the ZTE Mobley a keeper. Even though you can turn your phone into a hotspot, it doesn’t stay on all the time and uses data from your plan. By having a separate device, you don’t have to worry about going over your usage and being throttled and don’t have to worry about turning on the hotspot.

I would be interested in trying out the other mobile hotspots that AT&T has to offer as they would look neater than my soldered set of cables and be more compact, but I have to check the terms and conditions to see if there is a problem moving my SIM to a different device and keeping the same plan.

Cleaning up a mess

Over the course of the last few years, my closet of networking equipment has grown and while everything works, it wasn’t the prettiest sight. I had originally tried to color code all the cables and arrange things as neatly as possible, but it didn’t quite work out. I finally got tired of looking at it (after viewing pictures of other people’s clean networking racks), purchased a 48 port patch panel that had RJ45 connectors on the front and the back and a bunch of white cables of various sizes (color coding was a waste for me as it really didn’t matter what went where). My original plan when I setup the rack was to use patch panels, but at the time, I was looking at patch panels that I had to terminate in the back; this would have meant a bunch of wires coming from the wall that I’d terminate in the panel. I opted to put all the RJ45 jacks in the wall and have patch cords going from the wall to the equipment.

This is the before picture (yes, I know it is blurry; didn’t notice it until after I had already cleaned everything up. My son is a Michael Jackson fan and thus the song on the Squeezebox!)

Before

By rearranging the cables such that the only cables coming out the front go from the patch panel to the switches, I was able to take the clutter and move it to the back. The back doesn’t look half bad as I used shorter cables and wire tied them together.

After

These changes, of course, don’t change the functionality of my setup, but I like how clean this looks.

Fragmented World Of Payments

Last Saturday we ran a number of errands and at the end of the day something dawned on me: I had used several different payment systems and the payment process remains awkward for most of them.

Our first stop was Walmart where the payment terminal said to swipe my card, so I did and then was told to insert the card (called a dip). Since I don’t shop at Walmart all that often, I didn’t realize or remember that they now do chip. It is also hard to remember or know which merchants can take NFC payments; the terminal may look like it works, but when you try it, it fails.

Our next step was the ATM; this particular ATM was a Bank of America ATM that did NFC (NFC is the mechanism by which the iPhone talks to payment terminals). I had loaded my ATM card on my iPhone to give it a try. Unfortunately it didn’t work probably because I’m not a BofA customer and it didn’t like the card from my phone. So I reverted back to inserting the card.

After the ATM, we went to PETCO where I was able to use my Apple Watch to buy some crickets.

Then it was Costco for gas. While Costco does chip cards in the store, it is an insert (swipe) at the gas pump. I got a few hours break after that part of the journey because my credit card needed a rest!

For dinner, we went to BJ’s Restuarant. The selection is wide and my son likes it. We go there often enough that this time I decided to sign up for their rewards program. I downloaded the app and signed up. There was an option for mobile payment which was interesting. At the end of the meal, I pulled out the app, tapped on mobile payment, entered our check number, selected the tip and was presented with the option to pay with Apple Pay. That was pretty cool; I used TouchID to pay and we left (kind of felt weird not interacting with the server to pay).

After dinner, we headed to Best Buy to buy an iPad for my mother-in-law. Best Buy does NFC payments and used my Apple Watch (it took 2 transactions because the terminal froze when it came time to sign).

Recapping, in the course of the day, I used the following ways to pay, all with my credit card:

  • Dip (insert)
  • Insert (swipe)
  • Apple Pay (on Apple Watch)
  • Apple Pay in an app

I’m a huge fan of Apple Pay because of the security (merchants don’t see my real credit card number) and while I don’t choose places to shop based on payment option, I kind of smile every time I use it because it still feels like magic. Hopefuly in the near future, all merchants will take NFC payments.

Fun with Packet Filtering

About 6 months ago, I wrote about blocking my security cameras from talking to the Internet by moving them to a separate VLAN. Things have been working well, but after getting a USG, I decided to reduce the load on the router (using a VLAN required all traffic from my cameras to my Mac Pro to go through the router). My Mac Pro has 2 Ethernet ports, so I plugged the second port into another switch port that was set to the same VLAN as the cameras and give it an IP address on that VLAN. This would allow the cameras to talk directly to the Mac Pro without going through the router.

Perfect, I thought as everything was working well. However, when watching the logs on the router, I saw that the cameras were trying to talk to the Mac Pro’s primary IP address which was on a different VLAN. The router dropped the packets which was good, but it took me awhile to figure out what the cameras were doing. Basically the cameras were sending out UPnP packets to UDP port 1900 on the multicast address of their subnet and waited for replies. I had turned all UPnP off on the cameras, but they still kept sending packets. Why was the Mac Pro replying? I have the excellent BWS Systems HA Bridge installed on the Mac Pro to add Amazon Echo control to my Vera; in order to do this, HA Bridge listens for UPnP packets and then replies with the web address for device discovery. The bridge is configured to listen on all interfaces, but in its reply, it gives the primary IP address. While I’d like the bridge to only listen on the primary interface, most services listen on all interfaces.

Having learned and realized that the cameras could talk to any service on my Mac Pro, I kind of became concerned and looked for a way to block this. While I could go back to the router method, I decided to look at Mac OS X’s Packet Filter. I read a few articles and came up with the adding the following to /etc/pf.conf,

    anchor "com.gruby"
    load anchor "com.gruby" from "/etc/pf.anchors/com.gruby"

I don’t know if pf loads by default on all OS X systems, but it does on OS X Server. Then for my /etc/pf.anchors/com.gruby, I have:

    # Don't alert source about dropped packets
    set block-policy drop

    # Allow all on local loopback
    set skip on lo0

    # Allow all on en0
    set skip on en0

    # Normalize and defragment
    scrub in all

    pass in quick on en0 all

    # Default deny policy
    block in all

    # Block in on en1
    block in quick on en1 all
    block out quick from 10.0.2.100/32 to 224.0.0.0/4
    block out quick from 10.0.2.100/32 to 10.0.2.255/32
    pass out quick on en1 inet proto tcp from any to any port 554
    pass out quick on en1 inet proto tcp from any to any port 80
    pass out quick on en1 inet proto tcp from any to any port 85
    pass out quick on en1 inet proto icmp
    block out quick on en1 all

    # Allow all outbound on en0
    pass out on en0 all keep state

I’m sure that this could be cleaned up and some rules are redundant or unnecessary, but in my testing, these rules block all inbound and outbound traffic on my secondary Ethernet port except for the security software connecting to 3 specific TCP ports. Now when the cameras do the UPnP broadcast, they won’t get back any replies and no matter what, the cameras can’t make connections to the Mac Pro.

If I had to do my camera system over again (or had cameras drop in my lap), I’d go with UniFi cameras and install their NVR software in a VM. Ubiquiti updates their products frequently and listens to feedback, it appears. The cameras I got are made by a company that doesn’t care, doesn’t release updates, and doesn’t make a quality product. While the picture quality is adequate and they’ve held up for 4 years, I wouldn’t recommend them.

My concerns over the cameras doing things they shouldn’t kind of goes back to my post about keeping devices updated. Once a device is no longer supported, should it be trusted? New vulnerabilities are being discovered all the time? Should maintenance plans be offered to keep software updated?

Review: Apple AirPods

When Apple announced the AirPods last fall, I wasn’t impressed as I already had Bluetooth earbuds that I used for running that worked quite well. It took me a few weeks to realize the advantages of them over other ear buds such as no on/off switch, take one out to pause, pairing across all devices, easy charging, convenient carrying case, etc. After that, I was convinced that they were the sleeper hit of the event.

Once the AirPods became available to order, I immediately placed my order; the price didn’t phase me. When I received them a few weeks later (I didn’t get in on the first batch), my excitement quickly turned to disappointment. They appeared to be plagued with problems such as dropping constantly on phone calls and popping while listening to music on my walks. I found forums posts where people had similar issues and I went ahead with Apple’s online support so that they could get it on record that there was a problem with my combination of devices and AirPods (iPhone 6s, first generation Apple Watch). None of their suggestions worked, but I didn’t really expect them to as I had tried what others suggested in the forums.

Several weeks later, I received a call from Apple wanting to see if I had time to follow up with a support person collecting information for engineering. Sure, I said as my AirPods were basically useless at that point. I spoke with an Apple person for well over an hour during which the AirPods dropped and switched to the iPhone’s speaker many, many times (once every few minutes). I didn’t hear back from Apple, but saw some forum reports indicating that the beta iOS versions fixed the problems (I don’t normally install beta iOS versions on my device). When iOS 10.3 came out, I immediately installed it (I backed up first because the APFS update kind of scared me). I was more than pleasantly surprised about my AirPods; they now worked exactly as Apple had described. Over 2 months after I bought them, they had become completely usable!

Now that I had working earbuds, what impressed me with the AirPods? First off, charging is easy and convenient. Next, the charging case makes it easy to carry them. There is no on/off switch and taking the AirPods out of my ears pauses the music. They are so convenient that I find myself listening to music more when I walk the dog.

Pros

  • Convenient charging/storage case.
  • Fits well in my ears.
  • Easy to pair with all my devices.
  • Acceptable sound quality (I’m not an audiophile so it works for me).
  • Taking the AirPods out of the case immediately turns them on.
  • Removing one AirPod pauses the music.

Cons

  • Initial issues delayed my full use of the AirPods.
  • There are cheaper ear buds on the market.
  • Easy to drop or lose.
  • Batteries won’t last all day.

Summary

I’ve tried a number of Bluetooth ear buds and headsets over the years and besides my Plantronics BackBeat Fit that I use for running, I haven’t managed to keep using any one for all that long. I’m cautiously optimistic that the AirPods are going to be my ear buds of choice for the foreseeable future. While they are not the cheapest ear buds out there, I think that all the pros outweigh the cost.

Review: Ubiquiti UniFi Security Gateway

Sometime after I reviewed the Ubiquiti EdgeRouter Lite, Ubiquiti contacted me and offered me a few products to test and review. One of the products they sent me was the UniFi Security Gateway. At the time, I set the box aside as it didn’t have all the features of the EdgeRouter Lite. In January when my father was having trouble with his Internet, I put the USG into service. For that application, it was ideal as it integrated with the rest of the components and was simple to manage.

After the success of that install, I was kind of jealous and decided to purchase a USG and see what it would take to replace my EdgeRouter Lite; the UniFi team has done a lot of work on the controller (the GUI to manage the device) since I was originally sent the device. Replacing a router should not be rocket science. Unfortunately for me, my network is a little bit customized. Going from the EdgeRouter Lite, I had to move over the following:

  • Dynamic DNS (for my external IP address)
  • IPv6
  • VLANs
  • Firewall rules for the VLANs
  • OpenVPN server
  • Static DHCP entries
  • Static DNS host entries

Some of this is available in the controller, some of it isn’t.

The first step was to adopt the USG into my controller. I followed the instructions on how to integrate the USG into an existing network. Unfortunately, I was unable to adopt (meaning the controller can manage the device) the USG. I tried a few times with no success. Next I looked at an article that allows me to configure the USG to find the controller (instead of the controller finding it). I followed the SSH instructions and issued the commands:

    mca-cli
    set-inform http://ip-of-controller:8080/inform

This worked and I started getting somewhere. (After reading some more posts on Ubiquiti’s extremely helpful forum, it appears that an old firmware may have had issues adopting and that upgrading the firmware before adopting may have helped.)

After the USG was adopted into the controller, I plugged in the WAN connection, rebooted the cable modem (so that it would pick up the new MAC address) and was able to connect to the Internet. If I had a simple network, I’d be done, but nothing is ever easy for me.

Next up was setting static DHCP entries. While the current controller doesn’t let you assign DHCP entries until after a device has been seen, all my devices were online and showed up in the controller (I have UniFi switches which makes the controller populate with all devices it sees) using the addresses I had assigned from the EdgeRouter Lite. It was a simple matter of selecting each device, clicking the “Use fixed IP address” checkbox and clicking Apply. (Note there is a bug in the UI where the checkbox doesn’t stay checked even after applying.)

Screen Shot 2017 03 06 at 11 08 48 AM

Perfect, so now that was out of the way (tedious, but reasonable), I could move on or so I thought. The controller lets me assign static IP addresses for clients; switches and access points are not considered clients. I needed static IP addresses for the switches and access points so that I could use SNMP monitoring on them; the package I’m using, Observium uses host names to address the devices; in order to use host names, I had to first give devices static IP addresses. This is where the messiness begins. Ubiquiti has an article on how to customize the USG and have the changes persist across reboots. (The EdgeRouter Lite just lets you configure it using the command line and the changes persist.)

You start the process by doing something like this:

    configure
    set service dhcp-server shared-network-name LAN_10.0.1.0-24 subnet 10.0.1.0/24 static-mapping UniFi-LR ip-address 10.0.1.131
    commit
    save
    exit

and then

    mca-ctrl -t dump-cfg

At this point, you have to pick through what was dumped and only choose what you entered manually as the json file you create gets merged in with what is produced from the controller. This isn’t necessary if you have a standard config and the controller has all the options you need.

I then repeated this process for IPv6, static DNS entries and my OpenVPN server configuration.

There is a GUI for configuring the firewall and I setup rules that prevent IoT devices from talking to my LAN, my cameras from talking to anything except 1 device, and a few other rules. This was straightforward, but a little different than on the EdgeRouter Lite.

Screen Shot 2017 03 09 at 2 13 16 PM

Now that I had the USG setup like my EdgeRouter Lite, what did I get? The hardware is virtually identical, so I didn’t gain performance. The main thing I gained was being able to look at my entire network in 1 place. In addition, I get the ability to remotely manage/monitor my network through the UniFi cloud. Did I mention the pretty picture with the circles?

Screen Shot 2017 03 06 at 10 59 55 AM

People are going to ask, why go with a USG over an EdgeRouter Lite. Here’s my rundown:

USG

  • Easily integrates with other UniFi equipment.
  • Simplified configuration.
  • Remote access via UniFi mobile app.
  • Firewall configuration is slightly easier than on ERL, I think.

EdgeRouter Lite

  • UI has some more advanced configurations like being able to change any option using the configuration tree.
  • Firewall configuration in UI allows you to apply rules directly to VLANs.
  • Configuration via command line is a one step process; make change and save it vs USG which has multiple steps.
  • Core operating system is newer than USG.
  • Static DHCP reservations can be made prior to a device being on the network.

Conclusion

Pros

  • Easy setup for simple networks.
  • Full view of entire network in one spot.
  • Remote access to router from UniFi mobile app (using the UniFi cloud).
  • Easy configuration of firewall entries.

Cons

  • No IPv6 DPI (deep packet inspection).
  • DPI works across all interfaces and may not give you an accurate representation of WAN traffic (which is what interests me).
  • Not all configuration options are available via the GUI.
  • Initial setup into a non-trivial existing network is painful.
  • WAN speed test is only useful for up to 150 – 200 Mbps (according to a forum post; I have 300 Mbps down and can only get about 130 Mbps shown).
  • JSON configuration for command line options is a bit awkward as you have to use the command line first, export the options and then pair down the result to put in the JSON config so that settings persist.

Summary

As I’ve written about in the past, the UniFi line of networking products is easy to use and everything works well together. The USG fits in well and despite my rough start with it, I’m pleased with it. While there wasn’t a huge leap from the EdgeRouter Lite to the USG, being able to see my entire network configuration in one place makes it easier for me to manage. In the future, I plan on adding more firewall rules and possibly more VLANs to separate out more IoT traffic (a day doesn’t go by where you don’t here about some IoT device doing something shady).

If you already own an EdgeRouter Lite, moving to a USG is a tough decision. You gain no new functionality or performance, but an interface that works with other UniFi hardware. If you don’t already own an EdgeRouter Lite and either plan on getting UniFi access points or switches, I think it is a no brainer to get a USG. If you aren’t using other UniFi gear, a USG itself won’t buy you a whole lot. With the USG, I’m able to define VLANs once and have it apply to the WiFi access points and the switch ports; with the EdgeRouter Lite, I had to define VLANs in both places for proper routing.

UniFi employees are quite active on their forums and have posted their roadmap. I really like some of the features and their openness is refreshing. The features won’t really change how I use the device, but will help reduce the number of command line changes I have to make.