Docker Images Not Starting

After updating my Linux host yesterday, the docker images failed to start with the following error:

Error starting userland proxy: listen tcp6 [::]:9091: socket: address family not supported by protocol

For some reason IPv6 (the hint is tcp6) is screwing things up. The problem is that I disabled IPv6 from the start on this host. Mainly because of some concerns in regards of routing and internet accessibility (I have a formal IPv6 subnet at home).

After about an hour of troubleshooting I changed the docker-compose.yaml file to include the actual IP address of the host instead of just the ports the container uses.

The old:

        ports:
          - '9091:9091'
          - '8888:8080'

New:

        ports:
          - '192.168.0.1:9091:9091'
          - '192.168.0.1:8888:8080'

Restarting the docker images went just fine after this. So I guess the update I ran yesterday included a docker update that basically thinks that you have IPv6 enabled by default. The problem is that I couldn’t find documentation on how to disable this globally.

Update Python Netaddr OUI Database

For a small project I needed to validate ~1500 MAC addresses on validity and their vendor Organizational Unique Identifier id (OUI). So a bit of Python scripting was in order.

I used a regular expression for basic MAC address validation, and the netaddr module to check the OUI of the MAC Address. A simple example of the code is shown below

#!/usr/bin/env python3

import netaddr as na
import re

_mac = '88-E9-FE-1F-65-7D'
if re.match('[0-9a-f]{2}([-:]?)[0-9a-f]{2}(\\1[0-9a-f]{2}){4}$', _mac.lower()):
    print(f'{_mac} - {na.EUI(_mac).oui.registration().org}')

Checking this MAC address online gives a normal result.

Python (or specifically netaddr) not so much, so there some work to be done. The error clearly shows that the OUI for that MAC address is not registered (in netaddr’s local database).

The problem is that the OUI ‘database’ from netaddr is (extremely) out-dated, so recently assigned OUI’s are not available, and result in Python script errors.

Unfortunatelly, the netaddr documentation doesn’t give any hint on how to update this database. Some searching on the local filesystem showed that there is a oui.txt file within the directory structure of netaddr (which in my case can be seen in the error shown above).

The latest oui.txt (~0.5MB larger than the netaddr version) can be downloaded @ IEEE (the organization were hardware vendors can request new OUI’s). The file location is: http://standards-oui.ieee.org/oui.txt.
I downloaded the file and replaced the original netaddr version. Running the code again gave no solution, since I got the same error. So back to the drawing board.

In the same directory as the oui.txt is a file called oui.idx. This file contains the decimal value of the OUI, and an offset. It turns out that the netaddr codeused this idx file to quickly skip to the actual vendor information in the oui.txt file. And since my idx file was based on the old oui.txt the vendor could still not be found.

The idx file cannot be found on the internet. It’s not something IEEE provides. It’s a file generated from the information in the oui.txt file.

Solution: In the netaddr directory where the oui.txt and oui.idx is located is a ieee.py script. Run that script, and it creates a new idx file based on the oui.txt file in that directory (as shown in the following example).

myhost:eui myname$ pwd
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/netaddr/eui
myhost:eui myname$ ls -la
total 12856
drwxr-xr-x   9 myname  admin      288 Jan 26 13:37 .
drwxr-xr-x  11 myname  admin      352 Jan 26 13:37 ..
-rw-r--r--   1 myname  admin    24990 Jan 26 13:37 __init__.py
drwxr-xr-x   4 myname  admin      128 Jan 26 13:37 __pycache__
-rw-r--r--   1 myname  admin    95467 Jan 26 13:37 iab.idx
-rw-r--r--   1 myname  admin  2453271 Jan 26 13:37 iab.txt
-rw-r--r--   1 myname  admin     9500 Jan 26 13:37 ieee.py
-rw-r--r--   1 myname  admin   419098 Jan 26 13:37 oui.idx
-rw-r--r--   1 myname  admin  3566144 Jan 26 13:37 oui.txt

myhost:eui myname$ curl http://standards-oui.ieee.org/oui.txt --output oui.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 4039k  100 4039k    0     0   370k      0  0:00:10  0:00:10 --:--:--  437k

myhost:eui myname$ python3 ieee.py 
myhost:eui myname$ ls -la
total 14336
drwxr-xr-x   9 myname  admin      288 Jan 26 13:37 .
drwxr-xr-x  11 myname  admin      352 Jan 26 13:37 ..
-rw-r--r--   1 myname  admin    24990 Jan 26 13:37 __init__.py
drwxr-xr-x   4 myname  admin      128 Jan 26 13:37 __pycache__
-rw-r--r--   1 myname  admin    95467 May 10 12:14 iab.idx
-rw-r--r--   1 myname  admin  2453271 Jan 26 13:37 iab.txt
-rw-r--r--   1 myname  admin     9500 Jan 26 13:37 ieee.py
-rw-r--r--   1 myname  admin   485973 May 10 12:14 oui.idx
-rw-r--r--   1 myname  admin  4136058 May 10 12:14 oui.txt
myhost:eui myname$ 

After that the output of my script was the following:

/usr/local/bin/python3.7 /Volumes/Python_Scripts/test.py
88-E9-FE-1F-65-7D - Apple, Inc.

Process finished with exit code 0

Juniper SRX, Routing Instances, and Syslog Challenges

In the previous post I described the issue I had with routing instances and DHCP-relay, and how I fixed it. It turns out that DHCP-relay wasn't my only problem. Turns out that syslog also stopped at the time I implemented the routing instances.

View fullsize

Syslog-gap

To solve this I needed to inject the route to my syslog server (Splunk) in the global routing instance by using policy options.

set policy-options policy-statement syslog-policy term 10 from instance DEFAULT
set policy-options policy-statement syslog-policy term 10 from route-filter 192.168.20.0/24 exact
set policy-options policy-statement syslog-policy term 10 then accept
set policy-options policy-statement syslog-policy then reject

set routing-options instance-import syslog-policy

Juniper SRX, Virtual Routers and DHCP Relay

A couple of weeks ago, I started to implement virtual routers in my SRX300. The reason being a new external subnet that  needed to route to a specific security zone. Using the default VR only wouldn't work because of the (single) default route.

Implementing it was fairly easy. The trouble began this week;

• Wireless controller not accessible
• Client with weird behaviour
• etc.

In my network, I have 1 DHCP server serving multiple internal subnets. The (basic) DHCP relay configuration was:

set forwarding-options dhcp-relay maximum-hop-count 10
set forwarding-options dhcp-relay client-response-ttl 10
set forwarding-options dhcp-relay server-group DHCP_Server 192.168.x.x
set forwarding-options dhcp-relay active-server-group DHCP_Server
set forwarding-options dhcp-relay group clients active-server-group DHCP_Server
set forwarding-options dhcp-relay group clients interface ge-0/0/0.1
set forwarding-options dhcp-relay group clients interface ge-0/0/0.20
set forwarding-options dhcp-relay group clients interface ge-0/0/0.30
set forwarding-options dhcp-relay group clients interface ge-0/0/0.200

Turns out that this stops to function when implementing Virtual Routers. Something I forgot to adjust. And since the DHCP scope on my server was set to a lease-time of 14 days.... That means that problems tend to introduce themselves after a couple of days.....

Anyway, after changing the DHCP relay configuration to include the correct Virtual Router name (DEFAULT) everything worked just fine.

set routing-instances DEFAULT forwarding-options dhcp-relay maximum-hop-count 10
set routing-instances DEFAULT forwarding-options dhcp-relay client-response-ttl 10
set routing-instances DEFAULT forwarding-options dhcp-relay server-group DHCP_Server 192.168.x.x
set routing-instances DEFAULT forwarding-options dhcp-relay active-server-group DHCP_Server
set routing-instances DEFAULT forwarding-options dhcp-relay group clients active-server-group DHCP_Server
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.1
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.20
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.30
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.200

So. DHCP is a bit like DNS. Both have timers (TTL and lease-time) that might bite you in the butt.

Installing Python Matplotlib On MacOS Sierra

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.

After some frustrating hours of trying to get this 'freetype' thing installed, I ran into an article on yantonov.com which solved my issue finally.

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

Internet of Things (IoT) and Ransomware

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):

• Refrigerator
• Microwave
• Kettle
• Toaster
• Dishwasher
• Garbage bin
• Keyfobs
• etc.

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.