• 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
  • 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.