Labels

Tuesday, November 13, 2018

Cataloging Patch Panel Connections

So I was busy over the last two days trying to get the patch panel connections documented.  If you have never tried to do this at your house, it is quite an eye opener.  What you originally thought that you had connected, turns out to be incorrect.  I have prided myself on documenting how the home network is wired together.  However, in the heat of battle, sometimes you fail to record the subtle differences, especially if you make a sudden change to the wiring because of a problem you find.  I finally settled on giving each patch panel a number (i.e., PP#1).  I also designate a connection that the port is connected to (i.e., PP#1-5 for patch panel 1 port number 5).  I had designations on the patch panels to record what device I was connected to.  However, this became a problem since I started rearranging the patches to suit different things that I was doing at the moment.

I now have labels on each patch panel port that tell me what patch panel (and associated port) contains the port connection.  I also have labels on the patch panels that tell me what number the patch panel is. What this means is that the label on the patch panel end points back to the opposite patch panel port.  Even though the numbering on the patch panel doesn’t tell me the signal it does tell me the infrastructure (that which doesn’t change) pieces so that I can trace a signal as necessary.  I also record patch cord connections to equipment in my iPhone; generally something like this:

PP#1: (toolroom)

15, 16 empty

1- To Kitchen/Dining Rm Ethernet plug (patch to .115-3)

2- To TIVo Mini downstairs (patch to PP#1-4)

3- To Computer Rm-Hutch wall (n/c)

4- to PP#2-1 (patch to PP#1-2)

5- to cable20 / cable21 .114-1 (patch to PP#1-11)

6- to PP#2-4 (patch to PP#1-9)

7- to black cable2 PP#6-2 (patch to Unmgd sw)

8- to light blue cable6 PP#6-1 (patch to .115-7)

9- to dark blue, PP#5-Y (patch to PP#1-6)

10 - to PP#2-8 (n/c)

11- to PP#3-19 (patch to PP#1-5)

12- to PP#4-X (patch to .115-5)

13- to PP#2-2 (patch to .115-2)

14- to PP#3-20 (patch to .115-4)

Notice that this setup allows me to see at a glance what signal is flowing through that patch panel port.  It also tells me if I have some empty ports (for expansion later).  Notice that I have in parends a patch cord designation that tells me the device or patch panel port connection.  The .xxx-x indicates a device IP number and the device port.

I tried hard to rearrange the port wiring so that patch panel ports for the most part connect to other patch panel ports.  After all, that is what patch panels are for.  Now I can rearrange the patch cords as necessary for different devices that are added or vlan connections that need to be made.

Friday, September 7, 2018

HA #1 - Making Changes to the Network for Home Automation

On a lark, I started changing out my Experimental vlan to add some Home Automation components.  I took my Plex server and changed it out to run Ubuntu 18.04 LTS, now called the HA-IOT server, added Docker, and spun up around 12 containers to support what I wanted to do.  I also added an Aeotec Z-Wave USB stick to interface to a number of Z-Wave components.  So far I have added three multi-sensors (temp, movement, humidity, etc.), three Z-Wave dimmable wall switches, two Z-Wave toggle wall switches, one plug in Z-Wave dimmer, one plug in Z-Wave switch, one Z-Wave door lock, and one Z-Wave door open switch.  In addition I have added one wifi multicolor LED bulb and have started adding dimmable LED bulbs in various lamps.

I have also started a project using a Raspberry Pi Zero W which interfaces to a LinkMaster 850LM so that I can press the buttons on my Subaru to activate some automations via a MQTT message.  The containers include home-assistant which interfaces to the Z-Wave USB stick, node-red which sets up automations, and pertainer which is used to manage containers in Docker.  I originally set-up the containers using a docker-compose script that I found on the home-assistant blog.  I will be changing those docker-compose scripts as I go.

Right now I am attempting to understand how to control lights via triggers so that I will be able to set-up automations that will work pretty much the first time.  I am also exploring a couple of different dashboard layouts.  All of this is actually controllable via web interfaces, so I am able to push the ports through a router (Netgear FVS318N) to my media vlan so that I am able to get to the web interfaces easily.

Monday, August 20, 2018

HomeLink HA Interface #4 - Slowdown to use a breadboard

So life happened again.  I wish I could just get down with development and not have to stop for something, but that is never the case in my life.  Maybe when I am retired it will get better; hopefully more time available for my hobbies.  Right now I am in the middle of a kitchen update and work activities that are ramping up again.

I decided to go ahead and get a couple of Raspberry Pi Zero breadboards to see if I can solder the required resistors and the level shifter, along with a couple of breadboard electrical connectors.  I have it in mind to run power to the RPi breadboard and then connect the 850LM to the breadboard as well. That way, the power goes to one location and is distributed from there.  It would be nice if I could find a simple board that provides 5v power without being huge.

That being said, I fritzed a layout using the Adafruit quarter proto-board.  I used pretty much the same connections, except that I purposefully put most of the power traffic cop on the proto-board.  So there are now five entities that will need to go into a 3D print, counting the LiftMaster 850LM.  The fritzing layout (not showing the 850LM) follows:



This was pretty much as simple as I could get it.  I am using a slightly different Buck-Converter than the Adafruit one shown in the Fritzing diagram, but the principle is the same (9v -> 5v power for the RPi Zero W).  I am assuming at this point that when the relay switches and drops the voltage to zero that the 9v power will not drop below the point where the RPi will "brown out."  The resistors are 220 ohm which will give a draw of 40 ma from the 9v power supply during the relay switch. Note that the 850LM channel 1 is tied to GPIO4, channel 2 is tied to GPIO5, and channel 3 is tied to GPIO6 on the RPi Zero W.  The fritzing RPi is a Zero but that is okay for illustration purposes since the GPIO pinouts are the same.  The use of a RPiZW is for wifi access in my IOT vlan.

Wednesday, August 15, 2018

HomeLink HA Interface #3 - Started the breadboarding process using an RPiZW, Buck converter, and 850LM

So I was able to start breadboarding the whole HomeLink HA Interface last night with mixed success.  I first of all did the tests in HA #2, followed by connecting everything up to my breadboard test setup.  The overall setup that I am going for looks like this:



The converter board will actually be a breadboard connected to the RPiZW gpio pins.  I am planning to initially mount the Down Converter (Buck) to the same breadboard.  However, I need to get everything set up first before moving the parts to the RPiZW breadboard.  So, the initial physical setup looks like this:


The RPiZW is rather small compared to the LiftMaster 850LM, so piggy backing everything on one breadboard for the prototype is probably ok.  I also need to figure out a model to print from my 3D printer to contain everything.

Tuesday, August 14, 2018

HomeLink HA Interface #2 - Experiments with the LiftMaster 850LM

So I decided to go ahead and test out the LiftMaster 850LM to see what I was up against. This device will become central to how I am going to interface my home automation system to my car.  I have always been a little upset that there were no interface devices to link my car to other than a simple switch or a garage door.  That is shallow thinking on the part of the automotive industry and the people who make garage door devices.  Anyway I digress.

The 850LM is going to be used to detect button clicks from my car and convert those clicks to MQTT messages that will be sent to my home-assistant controller via an MQTT broker. I expect to interface this on a Raspberry Pi Zero W (RPi0W) using its gpio pins.  However, there are a couple of issues that need to be resolved. The gpio pins on the RPi take 3.3v and the lowest voltage DC that the 850LM can handle is 9v.  Fortunately, I noticed previously that the Adafruit bi-directional level shifter can take a high side voltage up to 10vDC.  That means that I can use the level shifter between the 850LM and the RPi0W. The main reason that I want to use the RPi0W for this interface is that I can run the software under a Docker container, and allow for another container to House a Bluetooth proximity sensor / MQTT setup. Note that the RPi0W needs a 5v DC power source, but generates its own 3.3v power for the gpio.

The 850LM has a power port as well as a screw connection marked plus and minus. It has a total of three relay connections; the first two having NO / GND screw terminals and the third having NO / GND / NC screw terminals.  So my first question was how do the power port and power screw terminals relate.  The second question was when the relays switch is it momentary (governed by how long you press the button on the car), is it momentary (fixed close then open time), or is it more of an on / off switch (changes as you click the car button). Fortunately, I should be able to use a remote control to do the testing.

Test 1: I powered up the 850LM using a 5v to 9v usb cable that I had lying around by plugging it into the power port.  I had to use an adapter because the center pin on the power port was thick (white size). Once powered up, I had no problem setting up the remote control by following the 850LM instructions (click yellow button on 850LM, led next to button flashes, click button on remote, led goes out).  Once I did this, a click on the remote caused the relay to close and then open on its own.  So I answered the second question.  It makes sense because most garage door controllers have wall switches that momentarily close a connection which starts the garage door motor running.

Test 2: I then checked the power terminal pins and discovered that there was on voltage in the millivolt range.  This means that I cannot power the 850LM and draw power from these terminals when the 9v supply is plugged into the power connection.

Test 3: while clicking on the remote, I checked the voltage levels appearing between the NO / GND terminals.  This did not measure any change from zero volts.  This means that I will need to use a pull-up resistor for transitioning on the level shifter.  It also means that I will need to deal with negative logic; high showing up on the gpio means False / 0 / not clicked, and low means True / 1 / clicked.  I might end up using interrupts instead of running everything through a loop in order to not interfere with other container programs.

Test 4: I connected my 9v power source to the power screw terminals. I checked the on / off with my remote and everything worked out just fine.  So I will be connecting the 9v source (via a barrel to screw terminal adapter) to these terminals, along with the input side of a Buck converter (to give 5v from the 9v source) and some connection wires to power up the high side of the level shifter.  What I may do instead is put everything on a breadboard connected to the RPi0W gpio and minimize the connections needed (use the breadboard as the connection points for all of it).

I wonder if I can mount the Buck converter on the breadboard as well, that would save some space for me.  I am also concerned that the Buck converter might interfere with the functioning of the RPi, but I will have to test that out as everything is built.

Thursday, July 12, 2018

HomeLink HA Interface #1 - Development of a RPi Based Integration with a Liftmaster 850LM and Home Assistant

Not long ago I became interested in Home Automation.  This occurred as a result of making plans to add some more living space to my house.  I figured if I was going to spend some money on my house I should add some new capabilities as well.  I found out about Home-Assistant and was intrigued by the idea of being able to integrate disparate manufacturer's devices into the same mix along with being able to control them from the same source.  The problem with going to any one vendor is that they want you in their ecosystem; hence when you have many devices you end up with say many apps on your phone.  I wanted to do everything with one, or do it by voice, but be able to pick and choose what device I want where.  The war between Insteon and Z-Wave be damned.

So here is the brain-fart.  I have a Subaru Forester that has a set of HomeLink buttons on the auto-dimming rear-view mirror.  I don't have a garage, but I do have a porch with lights.  So, my first interaction was to add a Chamberlain light switch to the porch lights which I can command to go on and off from one of the HomeLink buttons.  Now I can turn on the porch lights when I get home late, and turn them off when I get in the house.  That was very little effort and I did that before I decided to go into Home Automation.  I removed a dimmer switch to put in the Chamberlain light switch.  I miss the ability to dim the lights on the front porch.  Why can't I have both a dimming capability and a HomeLink turn on and off ability.  In fact, why can't I use the HomeLink buttons to key off a "scene" like turn on the porch lights (if it's dark outside), turn off the living room lights, lock the door, set the alarm, wait for x minutes so you can get out of the driveway before turning off the porch lights?  Then, when I come home I just use a different HomeLink button to do the reverse?  Hence my desire to integrate something into the Home Automation sequence using HomeLink.

I was able to locate / buy a Liftmaster 850LM switch which has the ability to integrate with the HomeLink switches and garage door opener remote controls.  Normally it is used to control a garage door, but interestingly enough, I can sense the latches with an ESP8266 / Arduino / Raspberry Pi (take your pick) and push out the state of those latches using MQTT to the Home Assistant automation platform.  If I want, I discovered that the 850LM can run on as little as 9 volt DC input.  The Adafruit 757 bi-directional logic level converter has a max input on the high side of 10 volts which means that I could go through the 757 from the 850LM to whatever device I want to sense the state change.  I can then use the chosen device to use MQTT to send state information changes to the Home-Assistant center.  If I am real smart I can use a length of time timer that a HomeLink button is held down to increase the number of different states that I can report and if I use an RPi with Docker I can do other things at the same time.  Oh, and two clicks within 1 second would give me a third level, but let’s not get ahead of ourselves.  Anyway, it's worth investigating.

So now to get from Brain-Fart to working system.

Monday, July 9, 2018

OVS Changes #4 - Spinning up a Remote Z-Wave USB stick and Connecting to Home-Assistant

So over the weekend I was able to set up a Aeotec Z-Wave USB stick server on a Raspberry Pi using the instructions at https://community.home-assistant.io/t/rpi-as-z-wave-zigbee-over-ip-server-for-hass/23006.  It was a piece of cake getting it installed and running under systemd.  Now I have to set up a client and attach it to my running home-assistant.

TBD.

Sunday, July 1, 2018

Project #14 - Add Home Automation to the Network

I have been getting interested in Home Automation and setting up things so that I can automate some lights.  In addition, I would like to have the ability to lock doors, look at camera feeds, etc. from a single source.

Saturday, June 30, 2018

OVS Changes #3 - spinning up Home Assistant in a Docker Container

Now that I know how to connect a Docker Container to a specific bridge through the OVS, it's time to spin up an example.  I am trying to get into Home Automation and I have settled on the use of Home Assistant (http://www.home-assistant.io).  I am going to be reporting more on the use of this controller since it will pretty much control what I do within my house.

I have settled on the use of Z-Wave Plus components throughout the house because of the added distance and mesh connection improvements.  Home Assistant gives me the flexibility to connect to all sorts of things that normally don't go together because you know business.  Every company out there wants to do there own thing and control the whole market.  I'm not buying it if I can't use it with other companies products that have a capability I want.

I am going to first spin it up on the Experimental vlan until I am able to configure everything the way that I want.  I am intending on using OVS to connect ways of having devices on separate vlans and integrating them within the home system.  Anyway, that is the plan.

According to https://www.home-assistant.io/docs/installation/docker/, I have to do the following on Ubuntu:

$ docker run -d --name="home-assistant" -v /path/to/your/config:/config -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/home-assistant

Except in my case I need to have the container attached to a specific OVS bridge, so:

$ docker run -d --name="home-assistant" -v /path/to/your/config:/config -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/home-assistant

Update: well that didn't work out as planned.  I sent the following commands:

$ docker run -d --name="home-assistant" -v <my_HA_directory>:/config -v /etc/localtime:/etc/localtime:ro --net=none homeassistant/home-assistant

$ ovs-docker add-port <my_ovs_bridge> eth1 home-assistant --ipaddress=<home-assistant-ip>/24

What I ended up with was the home assistant available on every vlan that was in the ubuntu server.  I only want it on the <my_ovs_bridge>.  So what do I do to get it there?

Thursday, June 14, 2018

I've gone overboard with the SD Cards

I was sitting at my kitchen table last night getting all of my RPi SD cards organized.  I just realized that I have gone overboard - I now have a total of 70 plus cards that do various things and are in various levels of completion.  Do you think I have a case of hoarder fever?  Must needs to reuse cards that I haven't touched in a while.  I know it is that many cards since I have all of them numbered.  Good grief!!

Sunday, May 13, 2018

OVS Changes #2 - getting Docker containers to attach to the OVS bridges

Now that I have been successful with KVM VMs and their connections to the OVS bridges, I need to figure out how to do much of the same thing with Docker containers.  One of the reasons that I run ubuntuServer is because it is very easy (so they say) to get Docker containers running.  So now, what I am going to attempt is to startup a Docker container attached to one of the OVS bridges, used on a pfSense KVM VM.

So according to the site, http://containertutorials.com/network/ovs_docker.html, I have to do the following steps:

Install OVS (already done on my system) -

Install OVS-docker utility (already done on my system) -

Create an OVS bridge (already done on my system, except the bridge doesn't have an IP address) -

Create the docker container

Connect the container to the OVS bridge, such as
$ ovs-docker add-port ovs-br1 eth1 <container_name> --ipaddress=<ip_address_for_container>

OVS Changes #1 - Updating the ubuntuServer to use OVS bridges

One of the things that I wanted to do with my network was to be able to access multiple vlans while I was away on trips or from the office.  I hit upon the use of OpenVSwitch (OVS) as a means of connecting an Ubuntu VM running under VMWare on my Windows 10 laptop.  In addition, I wanted to be able to run a set of Docker containers from my Mac Mini server and have them connected to the ubuntuServer.  So, in effect I have a SDN within my house that can be connected to through my VPN server.

I had setup bridges to multiple Ethernet ports using the following template:


iface <ethernet-port-name> inet manual

auto <bridge-name>
iface <bridge-name> inet manual
        bridge_ports <ethernet-port-name>

The setup is in a number of bridge definition files located in /etc/network/interfaces.d/; one file per interface.  The only template that is in /etc/network/interfaces is the one that I have for my day-to-day network activities.  Again, I separate out vlans for different purposes making sure that the vlans do not talk to each other except in controlled instances.

What I did to use an OVS generated bridge was to remove the bridge definition file from /etc/network/interfaces.d/ and then delete the previous bridge using:


sudo ip link set <bridge-name> down
sudo brctl delbr <bridge-name>

sudo brctl show

and then perform the following command (note the ovs addition to differentiate it):

sudo ovs-vsctl add-br <bridge-name-ovs>
sudo ovs-vsctl add-port <bridge-name-ovs> <ethernet-port-name>
sudo ovs-vsctl show

Which is done for each port that I have defined, except for the day-to-day port.  It turns out that you can use the Virtual Machine Manager to pull up the VM, reset the bridge designations from the pull-down list, hit apply, then launch the VM.  Works very well with pfSense.  The interesting thing is that the <bridge-name-ovs> will now show up in an ifconfig command, where as before (when first created with OVS) would not.  Also, there are now tap devices that show up in ifconfig, like macvtap0 and macvtap1.  Those correspond to the tap device attached to the KVM VM; created from the use of Virtual Machine Manager.  I still need to figure out how to do this with Docker.

Anyway it works!  I am able to pull up the VMs on the correct vlan now.

Wednesday, May 9, 2018

Surprised at the changes in 18.04 LTS

So I went ahead and updated my Ubuntu Server from 16.04 LTS to 18.04 LTS.  I did this in order to stay current with the loads from ubuntu and look at the new stuff at the same time.  So I performed the upgrade over the weekend; I did have some issues with the vlan setups but didn't think anything of it.  I sort of kinda followed the instructions here.  Now I have discovered that the way that Ubuntu handles networks has completely changed in 18.04 LTS (see article here on NetPlan).

So now I need to look into NetPlan and figure out how it impacts with OpenVSwitch (OVS) since I am about to use that to do some remote vlan stuff.

Update: after requesting some help in the Reddit Ubuntu forum, I found out that NetPlan is not a typical Linux community project.  This means that it is somewhat of an Ubuntu.com project.  That being said, the responder showed me how to take NetPlan out of the equation.  Instructions are at UbuntuGeek, and are duplicated here:


Note:- This is not recommended and this is for advanced users only

Edit the /etc/default/grub file

sudo nano /etc/default/grub

Add the following line
GRUB_CMDLINE_LINUX="netcfg/do_not_use_netplan=true"

Save and exit the file

Now update the grub using the following command

sudo update-grub

You need to install ifupdown package

sudo apt install ifupdown

Now you can add all the interface details in /etc/network/interfaces file and reboot the ubuntu PC/server.

Wednesday, April 25, 2018

The Network That Could #1 - Introduction

I have had people ask me what I do with my network at home.  To that, I can only say that I use it as a playground for whatever strikes my fancy.  My job is in engineering and lately it has been more focused on security engineering.  I don't get a lot of hands on at work at my level.  My home network is a way of letting off steam and learning some things in the process.  So here is a simple intro to what I do with my network in case you were interested.

I mostly use my home network for experimentation but I also have parts of the network which are specific to media streaming (TiVo, Plex) and outbound connection.  My "homelab" is rather distributed throughout the house depending on its purpose.  In my home network I have 7 managed switches (Netgear GS108Tv2 / GS116Ev2 / GS108Ev3) spread throughout my house, all connected with each other through a series of "trunk" lines. Each "trunk" line carries multple vlans in a 802.1q sense. Some of the vlans are "patch" vlans which give me the ability to patch an Ethernet connection from one location to another.  I have the switches set to prevent crossover between vlans and isolate the management to a specific vlan that is normally not connected to anything. Ports that are not used are set to a "fake" vlan that goes nowhere out of the switch for security.

I play around a lot with media, Raspberry Pis, hacking, Weather station things, and just learning weird networking things. I have a couple of servers in the network running VMs (not located in the same part of the house) and at any moment I might want to access something across the network and might need a cable or two for some reason. I just change the ports to use one of several predefined "patch" vlans and connect up to the switches. It saves a lot of time trying to pull a new Ethernet cable, especially if it is going from the basement to the attic and on to the roof.

I have one vlan, full of Raspberry Pis and Arduinos, with several ongoing projects: e.g., one is a settup to use for Christmas light switching and another is a midi project in containers that use Raspberry Pis loaded with Docker. The other vlan is being used for some experiments with routing protocols, including Quagga and IPSec within IPSec tunnels for security.

I have a hacking vlan in my home network. There are a lot of VMs and things there that are VERY vulnerable to attack - on purpose, so I can personally learn how to break into them.  This vlan is very isolated from the outside.

I'm also cheap!  I'm using Ubuntu (free) to host VMs under KVM (free) on a <$250 AMD 8core FX with 16GB memory and 1TB drive with a stolen (from another project) cabinet and power supply. I have also been playing with Docker in the same setup. I've got a number of Linux VMs and also Windows 7 and Windows 10 VMs that started out as VMWare VMs.  The Ubuntu box provides a number of pfSense VMs for routing between some vlans.  This is in addition to a Mac Mini server and several Raspberry Pis setup in multiple clusters for experimentation.

Basically, all of this grew out of getting familiar with "networking stuff" and adds to my knowledge on the job as a Systems/Software/Security Engineer.

Wednesday, April 18, 2018

Added some patch panels to the network over the weekend

Well, I broke down and finally added a couple of patch panels (PP) to the homelab over the weekend.  I was getting tired of having to reconstruct connections whenever I wanted to move equipment from one room to the next.  My homelab is distributed across the house and I like to think that I can move and update things at will.  The problem was that I could not conveniently switch things around because of having to move existing Ethernet cables from one location to the next.  What I needed was a set of Ethernet cables that didn't move but still allowed me to connect at will, hence the use of patch panels.

Right now I am concentrating on getting the minimal number of patch panels up along with keeping equipment and connections the same.  This is little more than routing an Ethernet cable to a patch panel and then using a patch cable to go from the PP to the device.  In the throes of putting the initial two PP together, I made the mistake of routing a piece of equipment to the patch panel as though it were part of the infrastructure.  I now know to keep lines primarily from PP to PP within the network.

I started out with a 16 port and one 24 port PP that I placed in two locations.  The first location was in the tool room where my main switch is located, that got a 16 port PP.  The main switch is like the hub for most of the other managed switches.  The second location was part of the computer room shelf where I am not concentrating most of my efforts.  I originally drew up a diagram of what I wanted to do first followed by a diagram of where I wanted to go.  I followed the first diagram pretty closely but ended up with a lot of differences due to the position of the ports and other equipment that was around it.

Monday, March 26, 2018

Docker Test #1 - setting up test platform

So I decided to go out and get  a couple of parts to start running some Docker tests.  I was able to get a Raspberry Pi Zero WH from my local MicroCenter.  To that I added a USB-A connector (https://www.amazon.com/gp/product/B077W69CD1) and an OLED display (https://www.amazon.com/gp/product/B078D6NXFM) so that it is all one compact unit as shown here:








I wanted to be able to use the WiFi and Bluetooth capabilities as well as have a small OLED display with some control switches that I could use to control different Docker Containers as I develop them.  There are a few hoops that I need to get through to accomplish this.
  • Install Redmine, get it configured for general projects
  • Install Docker repository, integrate with Redmine (MySQL? Git repository?)
  • Start Redmine project for test
  • Get test install working on RPi for OLED screen, including buttons
  • Install Docker on RPi
  • Pull test into container, record steps,
  • Run test to ensure it works correctly
  • Push test container to local repository
  • Split test code into two pieces, one for OLED explicitly and one for test code
  • Pull two piece test code into two containers
  • Run combined test to ensure it works correctly
  • Push combined test containers to local repository
I am not going to do each of these in a specific order, however I will document what I do in this post and in 
posts to follow.  The first thing that I wanted to get accomplished was the setup of the Raspberry Pi.

- first, I mechanically put the docker test platform together

- next, I setup a 16GB micro SD using my Mac Mini with the following commands:
df -k
sudo diskutil unmount /dev/disk3s1
sudo dd bs=1m if=2015-02-16-raspbian-wheezy.img of=/dev/rdisk3

note that I actually used a newer version of raspbian (Stretch) since I was planning on keeping 
this as up to date as I possibly could.

- next, I changed two files on the /boot directory of the micro SD.

cd /Volumes/boot
nano wpa_supplicant.conf

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
network={
   ssid="YOUR_NETWORK_NAME"
   psk="YOUR_PASSWORD"
   key_mgmt=WPA-PSK
}

touch ssh

- next, I unmounted the micro SD and checked to see that it was unmounted
sudo diskutil unmount /dev/disk3s1
df -k

- next, I installed the micro SD, booted the RPi, checked my router for the IP address of the RPi,
and set ssh on, SPI on, time zone, and expand microSD using raspi-config

- I rebooted the RPi and performed and update
sudo apt-get update
sudo apt-get upgrade

- next, I went to the website for the WaveShare OLED display at 
https://www.waveshare.com/wiki/1.3inch_OLED_HAT, gathered some reading material, and started
loading libraries from the instructions at https://www.waveshare.com/wiki/Libraries_Installation_for_RPi.

- I did manage to bork the install of the docker suite using:
curl -sSL https://get.docker.com | sh

I'm not sure of what happened but it appears that the setup I am using has some issues with
power. I apparently need more than some usb cables that I own of being able to provide enough
power; the most success that I have had was using a powered usb hub from Smays which also
doubles as an ethernet connector.  Now it appears that I will have to go back and remove docker
and re-install it on my system.

Thursday, March 1, 2018

Project #13 - Add Patch Panels to the Network in Order to Ease Cabling

Since I seem to be moving cables from point to point, I thought that I would make sense for me to add a bunch of Patch Panels to the network so that I can minimize the runs needed between different parts of the network.  I think it would be a good idea to have keystone type Patch Panels instead of wired patch panels.

Wednesday, February 21, 2018

New Network Layout #1 - Layout of my experimental network vlan

I have been very fortunate to be able to put together pretty much any network layout that I want.  I have made some changes over the years culminating in what I have currently.  Through many trials, I have been able to get to the point that I am comfortable with the layout and how it works.  The experimental network is below:



As you can see in this diagram, I have a Gateway vlan which I connect most of my toys to.  The Gateway vlan in turn is connected, through various routers to the Internet hosted by my ISP.  For purposes of this discussion, how I connect is immaterial.  I have a pfSense router which isolates the Experimental vlan (Exp) from the Gateway vlan.  I also have a Personal vlan (Pers) which is used to monitor the Exp and is isolated from the Exp by another pfSense router.  I can update/command experiments in the Exp from anywhere in the house that is connected to the Pers.  The Exp is also connected to the outside world during Christmas (and other specific times) through a Ubiquiti WAP.  When Christmas rolls around the wifi connection is turned on to command some wifi-enabled switches and some wifi-enabled LED displays via experiments in the Exp vlan.  Since I am using a lot of managed switches, I am able to connect an Ubuntu server to the Exp, along with an RPi Cluster, and additional RPi experiments.  I also have a permanent RPi development terminal that I can use to ssh into various experiments as necessary.  The Ubuntu server supplies a number of VMs that are useful for development work including a subversion repository and some bug/issue tracking software like RedMine.

Friday, January 26, 2018

The VLAN 101 Story

The VLAN 101 Story

TL;DR - Op writes a story to explain how VLANs work using an example problem because inquiring minds want to know.

Ok, here is VLAN 101, written as a story and providing a quick summary of the use of 802.1Q to solve a problem:

For sake of argument lets do this with an example because that lends itself to being able to grasp the concept easier.  So lets say that you are living with your mother in a house with three levels: attic, main floor, and basement.  You live in the basement and you just signed a contract to provide some IT services to get a server ready.  The only problem is, your house doesn't have internet and your mother doesn't want a lot of wires going through her walls and she wants things neat and tidy.  You convince her that if she gets internet through an ISP she gets to watch movies on Netflix through her network aware TV and her cell phone can now use wifi, and a little later on she can get a camera pointed at the front door so she can see who is there.  An additional gotcha is that there is a lot of metal/concrete in the main floor so wifi doesn't get to the basement easily.  I am purposefully taking cable TV out of the picture here and just concentrating on the connection to the internet and Ethernet which you need to do your contract work.

So you think this through and you decide that if the ISP puts incoming lines into the attic, you can do everything with a two Ethernet port patch panel in the attic, two ethernet cables going from the attic to the main floor, attach those cables to a three Ethernet port patch panel in the main floor, one Ethernet cable going from the main floor patch panel to a single Ethernet port patch panel in the basement.  Your wiring would be ISP (attic) -> port#1 (attic patch panel) -> port#1 (main floor patch panel) -> ISP router (with wifi) WAN port.  Thats incoming service.  For LAN side service - router LAN port (main floor) -> port#3 (main floor patch panel) -> port (basement patch panel) for your server; and a different router LAN port (main floor) -> port#2 (main floor patch panel) -> port#2 (attic patch panel) for the camera to connect to.  You can plug the TV into an empty ISP router LAN port.  You also think to yourself that if you have an unmanaged switch you can plug that into the port in the basement and plug your server equipment and your laptop into it.  So you write up the instructions for the ISP installer.  Your hardware diagram looks like this:

     +--------+                             +--------+
     | ISP    +-----------+   +-------------+ Camera |
     | Conn.  |           |   |             |        |
     +--------+        +--v---v--+          +--------+
                       |  1   2  |
                       +--+---+--+
                          |   |
                          |   |
                          |   |                 Attic
            --------------------------------------------
                          |   |
                          |   |
                          |   |   +--------+
     +--------+           |   |   |        |
     | ISP    |WAN     +--+---+---+--+     |
     | Router +---------->1   2   3  |     |
     |        |        +------^---^--+     |
     +-+-+--+-+ LAN           |   |        |
       | |  +-----------------+   |        |
    LAN| |LAN                     |        |
       | +------------------------+        |
       |                                   |
     +-+---+                      +--------+
     | TV  |                      |
     +-----+                      |             Main Floor
            --------------------------------------------
                                  |
                               +--+--+
                               |  1  |
                               +--^--+
                                  |
           +-----------+          |         +----------+
           |           |     +----+----+    |          |
           | Server    +-----> Unmgd   <----+ Laptop   |
           |           |     | Switch  |    |          |
           +-----------+     +---------+    +----------+
    
                                               Basement

On the day of the installation you leave to get your server equipment and your mother is now in charge of giving the instructions to the ISP installer.  While you are gone, the ISP installer gets the instructions from your mother and notes that in your neighborhood, all cables and electric are in conduit in the ground coming to the houses.  So, guess what, the ISP installer puts the connection in conduit in the ground up to your house and installs the ISP connection in the basement.  However, the Ethernet cable connections in the walls are done per your instructions.  Then the ISP installer runs an Ethernet cable from the ISP connection in the basement to the single port connection in the basement.  He then puts the router (with wifi) on a table on the main floor behind the TV, connects the WAN port on the router to the 3 pin port panel going to the basement, connects up the TV to a LAN port on the router, and leaves.  Meanwhile your mother is not really happy about seeing those antenna on the router in her living room and waits for you to come home to complain.

You arrive at home with the router, an unmanaged switch, and a gleam in your eye, knowing that it will be simple to get everything connected.  Then you discover what happened with the install while you were away.  In addition, your mother tells you to get rid of the antenna "thingy" in the living room because it looks bad. So what do you do now?  Enter 802.1Q.

You understand instinctively through your IT experience that you have several broadcast domains to deal with here. When we use the term broadcast domain we are talking about a logical division of a network where the nodes can reach each other by broadcast at the data link layer (in our case Ethernet). You can have several LAN segments in the broadcast domain "bridged" together with the use of hubs or switches; but broadcast wise they can still get to each other.  A router forms a boundary between broadcast domains.  In our case we have at least two broadcast domains to deal with: the ISP network and your home network.  The ISP router forms the barrier between the ISP and the home network and allows traffic to flow from one to the other according to a set of rules, e.g. network address translation, known as NAT.

You know that you cannot put the router in the basement because one of the selling points is the wifi connection.  That leaves putting the ISP router in the attic.  You only have one Ethernet cable between the basement and the main floor so that leaves out getting the LAN side of the router to your server.  Somehow you have to flow the ISP Ethernet to the WAN port on the router in the attic then the LAN port on the router back to your server equipment using one cable.  So lets talk "router on a stick"; it's going to look like we have the router on a long pole.

If you obtain two vlan aware (managed) switches, you can solve the problem. Virtual LANs (vlans) are like any other LAN that is a single broadcast domain.  VLANs are normally separated from each other the same as a normal LAN is to any other LAN.  But, in this case we can flow the traffic from multiple vlans down the same physical cable by using 802.1Q.  In the 802.1Q based Ethernet packet that goes out over our cable (level 2), we introduce a 32-bit vlan tag field between the source MAC address field and the EtherType/Length field of the original Ethernet frame.  This 32-bit number is composed of: a Tag Protocol Identifier (TPID) of 16 bits set to 0x8100 [ends up in the same position as the Ethertype/length field]; a Priority Code Point (PCP) of 3 bits referring to its 802.1p priority [used to prioritize classes of traffic such as voice, video, data, etc.]; a Canonical Format Indicator (CFI) of 1 bit indicating if the MAC address is in canonical format [always 0 for Ethernet switches to distinguish from Token Rings]; and a VLAN Identifier (VID) of 12 bits specifying the VLAN number which the frame belongs to [0x000 and 0xFFF being reserved giving 4094 possible VLANs].

As long as the connecting devices understand the vlan tag field they can introduce the field when sending packets down a physical connection/cable.  Note that packets from different vlans can be mixed together on the same physical cable, but are identified and therefore isolated from each other by reason of this 32-bit field.  The IEEE 802.1Q standard defines this number and how it is used.  A static vlan connection would be when we have a port on a managed switch that connects to one single vlan (an "untagged" port).  A dynamic vlan connection would use these 32-bit fields on packets to distinguish between different vlans and multiplex them together on the same cable.  We sometimes call this a "trunk" line.  The ports on at least two managed switches are set up to use "tagged" packets.  Note that some routers also have a vlan tag capability.

Back to our story.  So you leave the house again and go out and buy two cheap managed switches, along with a few Ethernet patch cables, and bring them home.  When you get home you place one of the managed switches in the attic and connect it (port SW1-8) to port#1 of the attic patch panel and one in the basement connected (port SW2-8) to the basement patch panel.  The designation SW1-8 means port 8 on Switch#1.  In the attic, you connect the WAN port of the ISP router to the managed switch and note the port number (SW1-1) on the switch.  Likewise you connect one of the LAN ports on the ISP router to the managed switch on a second port (SW1-2).  You also connect  one of the ports (SW1-3) on the switch to port#2 on the attic patch panel.  Down on the main floor you connect port#1 to port#3 on the main floor patch panel and port#2 to the TV.  In the basement you connect one of the ports (SW2-8) on the managed switch to the port on the basement patch panel.  You connect another of the ports (SW2-2) on the managed switch to your server.  Your laptop goes into still another port (SW2-3) on the managed switch.  Normally we would go ahead and connect the ISP connection to the managed switch (SW2-1) in the basement but we have to configure it first.  The hardware connection now looks like this:

                                                               +-----------+
                              +--------------------------------+ Camera    |
                              |                                |           |
                   +----------v---+                            +-----------+
                   |  Managed     +------------+
                   |  Switch#1    |            |
                   |              +--------+   |
                   +--^----^------+x       |   |
                      |    |            +--v---v--+
    +-------------+   |    |            |  1   2  |
    |  ISP        +---+    |            +--+---+--+
    |  Router     | WAN    |               |   |
    |             +--------+               |   |
    +-------------+ LAN                    |   |                 Attic
                            --------------------------------------------
                                           |   |
                                           |   |
                                           |   |   +--------+
                                           |   |   |        |
                                        +--+---+---+--+     |
                                        |  1   2   3  |     |
                                        +--^---^---^--+     |
                      +---------+          |   |   |        |
                      |         |          +-------+        |
                      | TV      |              |            |
                      |         +--------------+            |
                      +---------+                  +--------+
                                                   |             Main Floor
                             --------------------------------------------
                                                   |
                                                +--+--+
                                                |  1  |
                                                +--^--+
                                                   |
                                                   |x
                      +-----------+         +--------------+        +-----------+
                      |           |         |  Managed     |        |           |
                      |  Server   +--------->  Switch#2    <--------+  Laptop   |
                      |           |         |              |        |           |
    +------+          +-----------+         +--^-----------+        +-----------+
    | ISP  |                                   |
    | Conn.+-----------------------------------+
    +------+                                                     Basement

The important thing to remember in this diagram is that port x (SW1-8) on Managed Switch#1 is connected to port x (SW2-8) on Managed Switch#2.  The Ethernet cable connecting these two ports is where we are going to have our "trunk" line ("dynamic" vlan), i.e. 802.1Q tags (fields).  The other ports on the Managed Switches will not be "tagged" and will be dedicated to one vlan only ("static" vlan).  Once we have all this connected with none of the equipment on, except maybe for the TV we can now configure the system.  We will use VLAN 100 for the WAN side, VLAN 200 for the LAN side, and VLAN 300 for the Management VLAN.  The choice of an IP subnet for the LAN VLAN could be based on the default LAN IP for the ISP router, or just choose your own after changing the subnet on the ISP Router LAN.

So what is the flow of a packet in this network to our server?  ISP Conn. -> Managed Switch#2 (SW2-1, VLAN 100, "untagged") -> Managed Switch#2 (SW2-8, "trunk") where a VLAN 100 tag is applied -> Managed Switch#1 (SW1-8, "trunk") where the VLAN 100 tag is removed and sent to any port with the "untagged" VLAN 100 -> Managed Switch#1 (SW1-1, VLAN 100, "untagged") -> ISP Router WAN port -> rules are applied -> ISP Router LAN port(s) -> Managed Switch#1 (SW1-2, VLAN 200, "untagged") -> Managed Switch#1 (SW1-8, "trunk") where a VLAN 200 tag is applied -> Managed Switch#2 (SW2-8, "trunk") where the VLAN 200 tag is removed and sent to any port with the "untagged VLAN 200 -> Managed Switch#2 (SW2-2, VLAN 200, "untagged") -> our server.  Note that a similar flow can be shown to any other LAN connected device.  Also, note that we did not have to modify the wiring that the ISP installer left.

What are the steps needed to configure this network?  Thats another story for another day and it depends on your equipment.

Saturday, January 6, 2018

LED - Light Controller #3 - I always seem to never have enough time to complete projects

As usual, I am here after a long period of time without completion of my project.  During my time away from my little projects, it occurred to me that I might have a problem with the way that I was doing this project. I had a workable solution, bread-boarded part of it and connected the raspberry pi to it, putting a simple python program onto it and exercising the 8-channel relay.  After checking things out, I started putting the elements together and soldering them to a perma-proto board from Adafruit.  Sure enough, when I started soldering the 24 pin chips onto a breadboard I ended up smoking them.  I found myself completely unable to switch the 8-channel relay at this point.

At this point I started rethinking my approach to development.  Even though I had plenty of Raspberry Pis to go around, I started thinking about other solutions.  In my network, I have a vlan specific to Experimenting.  I also have a bunch of switches that allow me to setup links all over the house.  It occurred to me that maybe I could use an ESP8266 NodeMCU chip to receive commands and cause the switching to occur.  That way, I could use a Raspberry Pi to do the commands.  I could also simply print each of the boxes and tailor them to my circuitry.  So that is where I am at.