For a work related project, I wanted to run the Juniper vSRX firewall (v15.1X49-D110) on my work laptop by using VMWare Workstation Pro 14. Unfortunately, the installation (importing the Juniper vSRX OVA file resulted in a VMWare Workstation crash.
I recently 'upgraded' to MacOS Sierra (Apple's latest Operating System) by doing a clean install. This resulted in a couple of challenges, including some software that could not be installed, and for which I had to find some alternatives.
Another issue I ran into is that some Python3 scripts with matplotlib wouldn't run, because matplotlib wouldn't install correctly.
I could 'pip' all I wanted, but the result was always:
$ pip3 install matplotlib [...] The following required packages can not be built: freetype
Some googling pointed me to some articles that freetype is/was a part of the XQuartz (X11) software that's no longer (pre)installed on MacOS Sierra. And in the past I have always upgraded my OS. The times that I did a clean install on this machine.... Must have been ages ago.
First I installed 'homebrew'.
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
After that I installed pkg-config and freetype:
$ brew install pkg-config [...] $ brew install freetype [...]
And finally, I was able to successfully install matplotlib:
$ pip3 install matplotlib
Unfortunately, and no matter how funny the cartoon may be, this may be what the future is going to bring us if we're not careful.
Below are some of the online appliances (just random picks from Google):
The only item I couldn't find was the Internet-connected broom. But I guess that won't take long. The other items can all be bought with some sort of Internet connectivity, and are therefore potential vulnerable for abuse.
We have a lab which we can access by using a VPN (Cisco ASA and Cisco AnyConnect). This setup has a so-called split DNS configuration, which means that only resources in the lab are accessed through the VPN tunnel. Regular Internet traffic uses my local DSL connection.
At my house I (like most folks) rely on DHCP for providing me with IP address, gateway and DNS servers. My local subnet uses 192.168.10.1 for DNS and 192.168.10.254 is my default gateway. So my clients are in the same subnet as my DNS server (directly-connected).
All these things considered I should be able to browse the Internet while I have a VPN running. Well, that's where you're wrong.
This post is about something that bothers me a lot. Especially, because it originates from a place where you think they should know better. It's about Dots-Per-Inch (DPI) and JPEG (the popular digital image/photo format).
It all starts, when I read the requirements of certain online photo contests. The criteria for entering the contest contain the following: The photo entering the contest must be in JPEG with maximum quality (least compression), AND 300 DPI.
This weekend went my Internet (VDLS) down. The DSL part was still up, but the IPv4 connectivity (over PPPoE) was down. When I checked the Fritzbox (7340) I saw that the DLS had 'trained' on ~100Mbps down and ~30Mbps up. Connection speeds I could only dream of......
Trying to re-establish the IPv4 connection I restarted the DSL modem. Upon reboot, it trained on about 70Mbps download and 30Mbps upload, and the PPPoE tunnel for IPv4 established nicely..... for about 5 minutes.
It turned out that the DSL connection tried to get a better connection, and got it. So starting off at 70Mbps, it could establish a 74Mbps a couple of seconds later, and 75Mbps a bit later after that, and so on, and so on. During this time the PPPoE connection worked like a charm. Until the DSL reached the magical 100Mbps rate. That's when the PPPoE (and the actual IPv4 connection to the Internet) failed.
Ever since the good-old Popcorn Hour died last year, we've been consuming our media through a Minix media player with XBMC, or Kodi as it's called since version 15. And even though this was a complete package (everything configured and pre-installed), it had a learning curve and required more maintenance than the Popcorn Hour.
A couple of weeks back, we started to experience cut-offs in the media we were consuming. TV shows, and movies stopped for no reason. The image froze, audio cut-out, and the subtitles would go on like nothing was wrong. After a few seconds display goes black, and after 5 to 10 seconds the Kodi-menu would present itself.
At this point we would select play, and the TV show, or movie would continue were it had stopped.
The stopping (or crashing) of the media could occur 1-10 times in a movie and a couple of times in a TV show. One or two times is already annoying, so you can imaging what 10 or 15 'crashes' might invoke....
This week, I ran into an annoying feature regarding the Apple iOS Personal Hotspot function of my iPhone 5s. I had to do some software testing with various WiFi clients. This worked fine, up to the moment that new devices ran into connectivity problems.
The new devices could connect, but got a message that there was no/limited Internet connectivity. Checking the IP address of the devices showed that they had an 169 address assigned.
So the iPhone wouldn't give new IP addresses to the new devices. Earlier devices that connected correctly could reconnect without a problem though.
It turned out to be a 'normal' DHCP problem. The IP address scope on the iPhone was depleted.
The iPhone has a small DHCP address pool that can give out 16 addresses (172.20.10.0-172.20.10.15). Of these 16 addresses are 3 taken by the network, broadcast (172.20.10.0 and 172.20.10.15) and iPhone itself (172.20.10.1). Leaving 13 addresses for other devices.
In normal situations, this shouldn't be a problem, but when your testing stuff, you can run into a shortage of IP addresses. Besides the shortage of addresses there is another challenge; no way of altering the DHCP lease time, or even clearing the issued IP addresses.
The lease time for the DHCP address is approximately 1 day (85536 seconds), as shown by a little network traffic capturing below.
20:53:29.544291 56:e4:3a:38:4d:64 > 00:23:6c:8d:7f:8e, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 255, id 45806, offset 0, flags [none], proto UDP (17), length 328) 172.20.10.1.67 > 172.20.10.2.68: BOOTP/DHCP, Reply, length 300, xid 0xfd7e0982, Flags [none] Your-IP 172.20.10.2 Server-IP 172.20.10.1 Client-Ethernet-Address 00:23:6c:8d:7f:8e sname "Free-Public-WiFi" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 172.20.10.1 Lease-Time Option 51, length 4: 85536 Subnet-Mask Option 1, length 4: 255.255.255.240 Default-Gateway Option 3, length 4: 172.20.10.1 Domain-Name-Server Option 6, length 4: 172.20.10.1
There is a function to reset the network settings on the iPhone, but that just clears everything regarding (wireless) network settings, but it doesn't touch the DHCP service in the iPhone. A reboot of the iPhone doesn't do the trick either. So you just have to wait till it clears automagically.
So there is room for improvement......
The new iTunes iOS app that goes with the Apple Radio launch annoys the heck out of me. For some reason the GUI designers (and marketing peoples) think that the Apple online services are the only thing you'll ever need. This results in an iTunes menu bar where 80% is useless to me.
This week I re-installed my Mac Mini server at home. It still ran Snow Leopard, and it was time to start with a clean slate. So after a couple of hours of pondering if I had forgotten to backup something, I started with a clean install of OS X Yosemite (10.10).
Everything went smooth, until I started using the DHCP service that comes with the Server App add-on.
My server uses 802.1q (VLAN-tagging) to connect several different VLAN's which I feed into several Virtual Machines. So I also use several DHCP Scopes for those segments.
The IP addresses for these scopes are all in the 192.168-range (class C subnets), so when I created the scopes I had to go through a simple wizard in the Server App. I just had to fill-in the blanks (very user friendly), and OS X did the rest.
Upon testing I ran into the weirdest behaviour on my network. Getting connectivity with a device took a very long time, and when the device got an IP address, it was from a different network (???)> So it couldn't communicate across the network.
At first I began to wonder if I had mixed up the VLAN names and tags, but those were correct. After an hour of troubleshooting (more and more DHCP clients were failing in the network), I found the problem;
When you create a scope Apple will assign a default subnet mask (255.255.0.0). I guess I should have seen it, but I didn't.
After I changed the subnet mask in the DHCP scopes everything went back to normal.
Lesson learned: Don't rely on wizards and other user-friendly stuff.