My Howtos and Projects

Saturday, November 30, 2013

Linux – Start / Stop Services (Boot + Runlevel)

How-To: Managing services with update-rc.d

Linux services can be started, stopped and reloaded with the use of scripts stocked in /etc/init.d/.

However, during start up or when changing runlevel, those scripts are searched in /etc/rcX.d/ where X is the runlevel number.

This tutorial will explain how one can activate, deactivate or modify a service start up.

When installing a new service under debian, the default is to enable it. So for instance, if you just installed apache2package, after you installed it, apache service will be started and so will it be upon the next reboots.

If you do not use apache all the time, you might want to disable this service from starting up upon boot up and simply start it manually when you actually need it by running this command:

# /etc/init.d/apache2 start

As you can see in the output below, the scripts are in init.d but the boot process executes the scripts on rcX.d (X is the runlevel), so we have symbolic links in rcX.d that point to the scripts on init.d. For something, not to be exectuted at boot, we have to destroy the symbolic links at rcX.d, this can either be done manually or via the update-rc.d

You could either disable this service on boot up by removing manually, any symbolic links in /etc/rcX.d/SYYapache2 or by using update-rc.d.

The advantage of using update-rc.d is that it will take care of removing/adding any required links to /etc/init.d automatically.
Taking apache2 as an example, let’s examine how /etc/rcX.d is looking like:

# ls -l /etc/rc?.d/*apache2
lrwxrwxrwx 1 root root 17 2007-07-05 22:51 /etc/rc0.d/K91apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 17 2007-07-05 22:51 /etc/rc1.d/K91apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 17 2007-07-05 22:51 /etc/rc2.d/S91apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 17 2007-07-05 22:51 /etc/rc3.d/S91apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 17 2007-07-05 22:51 /etc/rc4.d/S91apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 17 2007-07-05 22:51 /etc/rc5.d/S91apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 17 2007-07-05 22:51 /etc/rc6.d/K91apache2 -> ../init.d/apache2

As you can see, for runlevels 0, 1 and 6 there is a K (aka Kill) at the beginning of the link, for runlevels 2, 3, 4 and 5, there is a S (aka Start). Those two letters stands for Kill and Start.
On Debian and Ubuntu, runlevels 2, 3, 4 and 5 are multi-users runlevels.

- Runlevel 0 is Halt.
- Runlevel 1 is single user mode
- Runlevel 6 is reboot

1. Removing a Service

If you want to totally disable apache2 service by hand, you would need to delete every single link in /etc/rcX.d/. Using update-rc.d it is as simple as:

# update-rc.d -f apache2 remove

The use of -f is to force the removal of the symlinks even if there is still /etc/init.d/apache2.

Note: This command will only disable the service until next time the service is upgraded. If you want to make sure the service won’t be re-enabled upon upgrade, you should also type the following:

# update-rc.d apache2 stop 80 0 1 2 3 4 5 6 .

2. Adding a service

2.1. Default priorities

Now, if you want to re-add (enable) this service to be started on boot up, you can simply use:

# update-rc.d apache2 defaults

Adding system startup for /etc/init.d/apache2 …
/etc/rc0.d/K20apache2 -> ../init.d/apache2
/etc/rc1.d/K20apache2 -> ../init.d/apache2
/etc/rc6.d/K20apache2 -> ../init.d/apache2
/etc/rc2.d/S20apache2 -> ../init.d/apache2
/etc/rc3.d/S20apache2 -> ../init.d/apache2
/etc/rc4.d/S20apache2 -> ../init.d/apache2
/etc/rc5.d/S20apache2 -> ../init.d/apache2

2.2. Custom priorities

But as you can see, the default value is 20 which is pretty different than 91 … a S20 link is started before a S91 and K91 is kill before K20.
To force apache2 to be started with priorities 91 for both Start and Kill, we need to use the following command:

# update-rc.d apache2 defaults 91

Adding system startup for /etc/init.d/apache2 …
/etc/rc0.d/K91apache2 -> ../init.d/apache2
/etc/rc1.d/K91apache2 -> ../init.d/apache2
/etc/rc6.d/K91apache2 -> ../init.d/apache2
/etc/rc2.d/S91apache2 -> ../init.d/apache2
/etc/rc3.d/S91apache2 -> ../init.d/apache2
/etc/rc4.d/S91apache2 -> ../init.d/apache2
/etc/rc5.d/S91apache2 -> ../init.d/apache2

2.3. Different priorities for Start and Kill

Alternatively, if you want to set different priorities for Start and Kill, let say Start with 20 and Kill with 80, you will need to run:

# update-rc.d apache2 defaults 20 80

Adding system startup for /etc/init.d/apache2 …
/etc/rc0.d/K80apache2 -> ../init.d/apache2
/etc/rc1.d/K80apache2 -> ../init.d/apache2
/etc/rc6.d/K80apache2 -> ../init.d/apache2
/etc/rc2.d/S20apache2 -> ../init.d/apache2
/etc/rc3.d/S20apache2 -> ../init.d/apache2
/etc/rc4.d/S20apache2 -> ../init.d/apache2
/etc/rc5.d/S20apache2 -> ../init.d/apache2

3. Specifying custom runlevels

Finally, if you only want to Start and Kill on specific runlevels, like for instance starting apache with priority 20 on runlevels 2, 3, 4 and 5 and Kill with priority 80 on runlevels 0, 1 and 6:

# update-rc.d apache2 start 20 2 3 4 5 . stop 80 0 1 6 .

Or, to start with priority 20 for runlevel 2, 3 and 4 and priority 30 for runlevel 5 and kill with priority 80 for runlevel 0, 1 and 6:

# update-rc.d apache2 start 20 2 3 4 . start 30 5 . stop 80 0 1 6 .

Based On: http://www.debuntu.org/how-to-managing-services-with-update-rc-d/

Raspberry Pi – Specs and Features (Summary)

This is not an howto or a project per se, but it will definitly be reference in upcoming howto’s and projects.

What I present here is a summary of the Raspberry Pi specs and features:

Model A
- 256MB RAM
- one USB port
- no Ethernet
- Power: 500 mA model

Model B
- 512MB RAM
- 2 USB ports
- Ethernet port
- Power: 700-1000mA

Model A&B
- Main Specs
   - 700 Mhz (Most devices will run happily at 800MHz)
   - 8 dedicated GPIO pins
   - UART (Rs232)
   - i2c bus
   - SPI bus with two chip selects (also in arduino)
   - i2s audio
   - Power - 3v3, 5v, and ground.
   - If you dont use UART, i2c, etc (and use all for GPIO)
      - Revision 1 - 17 GPIOs
      - Revision 2 - 21 GPIOs.
   - GPIOs can theoretically be expanded indefinitely by I2C or SPI bus.

- Physical     - Measures 85.60mm x 56mm x 21mm
    - It weighs 45g.

- Network
    - 100 Mbps (model B only)
    - Ethernet is attached via the USB 2.0 bus (Gigabit not possible)
    - No netbooting or pxe

- Power
- Tension: 4,75 Volts - 5,24 Volts (You can test it on the TP2 and TP1 contacts)
    - Maximum Power - 1 Amp (1000 mA)
    - GPIO pins can draw 50mA safely (all)
    - Individual GPIO pin can only safely draw 16mA
    - Camera module requires 250mA
    - Keyboards and mice can take as little as 100mA or over 1000mA!!! (be aware, and chose low power keyboards an mice)

- Video
   - Raspberry Pi can record and play h.264 (mp4/mkv)
   - Two additional codecs can be purchased (RBPi Store):
      - MPEG-2 - DVDs Codec
      - VC-1     - BlueRay Codec (Microsoft format - Blu-ray discs, Windows Media, Slingbox, and HD-DVDs)

- No real time clock (RTC)

- Camera Board (Omnivision 5647)
    - Is the only camera module that is compatible
    - Connects via the CSI-2 camera port using short ribbon cable
    - The ribbon cable can be up to 4 meters
    - Connects to the Image System Pipeline (ISP)
    - Camera module (Omnivision 5647) specs are:
       - Photo - 5MP (2592×1944 pixels)
       - Video - 1080p 30Fps 1920x1080x30fps)
       - Power - 250mA

Based On: http://www.raspberrypi.org/faqs#introShares

Raspberry Pi Remote Desktop - via VNC (TightVNC)

So you’ve got your Raspberry Pi setup, but what if you don’t have a dedicated monitor to use with it (for example, mine’s connected to my TV). How can you use it without disrupting your setup? VNC (Virtual Network Computing) allows you to see your Pi’s desktop and control it remotely using another computer running Mac OS X, Windows or Linux (and other devices too).

The VNC server software runs on your RPi, access it by running VNC client software on your other device.

The VNC Server

There are various guides for this online, most suggest using the TightVNC server software, here’s my summarised need to know version, run all commands from the command line:

Install tight VNC: “sudo apt-get install tightvncserver”
Run the program: “tightvncserver”, and it will start a new session with 1024x728 and 24 bit colour:

pi@raspberrypi ~ $ sudo tightvncserver

New 'X' desktop is raspberrypi:1

Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/raspberrypi:1.log

the :1 (aka session number) means port 5901

If you run the program: “tightvncserver” again, and it will start a another session with 1024x728 and 24 bit colour:

pi@raspberrypi ~ $ sudo tightvncserver

New 'X' desktop is raspberrypi:2

Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/raspberrypi:2.log

the :2 (aka session number) means port 5902

If you want to start a custom VNC session: “vncserver :3 -geometry 640x480 -depth 24”

vncserver :3 -geometry 640x480 -depth 24

New 'X' desktop is raspberrypi:3

Starting applications specified in /home/pi/.vnc/xstartup
Log file is /home/pi/.vnc/raspberrypi:3.log

the :3 (aka session number) means port 5903

Notes:

Configure the session’s resolution after the -geometry argument. In the above 1024x768 is used. The RPi is capable of full HD so you could try 1920x1080.
Colour depth is specified by the -depth argument. In the above exampe, 24-bit colour depth is used. You could use 16-bit instead to reduce network traffic.
You can start more than one VNC session by running subsequent vncserver commands, just increment the first digit: e.g “vncserver :2 …” for a second, ”vncserver :3 …” for a third (I don’t know how many the RPi could handle).
You can set this to run at start up, see the eLinux wiki tutorial, or look for a later post on this blog on automatic login which can start the VNC session with less effort.

The VNC Server (Connect To Your Raspberry PI)

There are lots of VNC clients you can use, depending on your platform. I’m using Apple’s Remote Desktop software which is incredibly powerful (especially when administering Macs) but is overkill if you are just using it with your RPi. TightVNC has a free client application, there’s a native Windows version and a surprisingly good (but limited) Java version, which should run on any desktop/laptop system. A Google search should find you a suitable app for your own system.

To connect to your RPi:

Get your RPi’s IP address by running “ip addr show” or “ifconfig”. The IP address with be shown as highlighted in the image below.
Connect your client to the IP address obtained from 1.
Use port “590x”, where “x” is the session number seen in the previous section. If this doesn’t work, enter the IP address followed by “:x”, e.g. “192.168.1.50:1” (works on TigthVNC).

Based On: http://gettingstartedwithraspberrypi.tumblr.com/post/24142374137/setting-up-a-vnc-server

Monday, November 18, 2013

Make a Cisco Unified Communication Manager Bootable ISO

How to make Cisco Unified Communication Manager bootable ISO from non-bootable image on Linux

NOVEMBER 18, 2013

Here are the exact steps that help you to make bootable CUCM ISO image from non-bootable ISO image on Linux. If you want to do the same on Windows I strongly recommend to read this tutorial. I could not write my tutorial without reading it first.

Introduction
Typically, non-bootable CUCM images are those available for download on Cisco website. I used Linux Fedora 17 and mkisofs to create bootable CUCM ISO image but feel free to use any Linux distro with genisoimage installed. On Fedora you have to install a package genisoimage to get mkisofs installed.

Used software
Linux Fedora 17 x86-64 with installed genisoimage utility
CUCM 9.1.2 - UCSInstall_UCOS_9.1.2.10000-28.sgn.iso

1. Install genisomage

$ sudo yum install genisomage

Create directory where non-bootable CUCM ISO image will be mounted.

$ mkdir -p ~/temp/extract

2. Create directory where the content of mounted non-bootable ISO image will be copied

$ mkdir -p ~/temp2/

3. Mount non-bootable DVD ISO image

$ sudo mount -t iso9660 ~/Downloads/UCSInstall_UCOS_9.1.2.10000-28.sgn.iso ~/temp/extract

4. Copy the content of mounted ISO image to directory ~/temp2

$ cp -rv ~/temp/extract/ ~/temp2

5. Create bootable ISO image

cd ~/temp2/extract

mkisofs -o ../UCSInstall_UCOS_9.1.2.10000-28.sgn-bootable.iso -R -no-emul-boot -boot-load-size 32 -boot-info-table -b isolinux/isolinux.bin .

End.

Reference
http://htluo.blogspot.co.uk/2010/04/how-to-make-non-bootable-iso-image.html
http://www.ipcommute.co.uk/technical-articles/17–creating-isolinux-boot-dvds-with-free-software-cucm-uccx-cups.html

Taken From: http://brezular.wordpress.com/2013/11/18/how-to-make-cisco-unified-communication-manager-bootable-iso-from-non-bootable-image-on-linux/

Saturday, November 16, 2013

Stresslinux – Torture Tests to Your Hardware

Stresslinux Torture-Tests Your Hardware

Stresslinux is a lean, mean torture machine with 750MB of hardware-pummeling goodness for probing and load-testing your computer's hardware. Why, you ask, would anyone want to torture their nice hardware? Perhaps "torture" isn't the best word; think load-testing to expose defects, "burning in" a new machine, or to figure out some limits for overclocking.

Stresslinux runs from external bootable media: CD, USB stick, PXE boot, or you can run the VMWare image. My favorite is a USB stick because it is fast. There are good instructions for creating your chosen boot medium.

When you boot up, you have the option to allow sl-wizard to probe your system for sensors and then load the appropriate drivers (see the screen shot, below).

Probing system sensors at boot.

You can re-run this anytime after boot by deleting /tmp/sensors and then running the sl-wizard.sh script as root, like this:

stress@stresslinux:~>;sudo rm /tmp/sensors
">stress@stresslinux:~>;sudo sl-wizard.sh

Exploring Stresslinux

This is not your ordinary stripped-down Linux. It was built with SUSE Studio, and is based on OpenSUSE. If you like playing with test builds there are a ton of 'em.

Stresslinux uses Busybox in place of the usual coreutils, fileutils, and other standard Linux commands. Busybox is a single stripped-down binary containing several dozen commands, and it uses the ash shell, so you may find that some of your favorite options are missing. The Busybox command reference should help you.

Stresslinux uses the Fn keys in an interesting way. There are 6 ordinary ttys on F1-F6, and it boots to tty1 on F1. The rest are normal login ttys. On US keyboards you can switch between these with ALT+Fn. (STRG+Fn on German keyboards, which is the same as CTRL+Fn.) F10 displays eth0 throughput (see above), F11 shows hard disk temperatures, and F12 displays lm-sensors readings.

Probing system sensors at boot.

That Was Fun, Now What?

Now that Stresslinux is booted up and you have gazed upon your eth0 and sensor outputs, what's next? Let's spend some time with the stress command, because that is a good general-purpose workload generator. It operates by siccing a bunch of hogs on your system. This simple invocation puts a light load on the CPU, I/O, memory, and hard drive:

> stress --cpu 8 --io 4 --vm 2 --hdd 4 --timeout 30s --verbose
stress: info: [16275] dispatching hogs: 8 cpu, 4 io, 2 vm, 4 hdd
stress: dbug: [16275] using backoff sleep of 54000us
stress: dbug: [16275] setting timeout to 10s
stress: dbug: [16275] --> hogcpu worker 8 [16276] forked
stress: dbug: [16275] --> hogio worker 4 [16277] forked
stress: dbug: [16275] --> hogvm worker 2 [16278] forked
stress: dbug: [16275] --> hoghdd worker 4 [16279] forked
stress: dbug: [16275] using backoff sleep of 42000us
stress: dbug: [16275] setting timeout to 10s
[...]
stress: info: [16275] successful run completed in 13s

That snippet shows I wasn't kidding about the hogs. When it finishes with "successful run completed" that means there were no errors. If it did detect errors, it would either try to tell you what they were, or tell you to examine the syslog. Let's walk through this so we know what it's doing.

--cpu 8 tells it to fork 8 processes. Each process calculates the square root of a random number (by calling the sqrt() and rand functions) in a loop that stops at the end of your timeout, or when you stop it with CTRL+c. Are there any geezers out there who remember who said "Computer. Compute to the last digit the value of pi?" And why? This is similar, a way to keep the CPU constantly busy.

--io 4 forks 4 processes that call the sync() function in a loop. sync() flushes any data buffered in memory to disk. Most Linux filesystems use delayed allocation; that is, data are held in memory for a period of time before being written to disk. This speeds up performance because disk I/O is slower than RAM. Running this one by itself and trying out different values will give you an idea of your I/O performance.

--vm 2 thrashes your RAM by forking 2 processes to allocate and release memory. (Looping malloc() and free().)

--hdd 4 pummels your hard drive with writes, by calling the write function in a loop.

--timeout 30s tells stress to stop after 30 seconds. Or whatever time you want, of course, using s,m,h,d,y (seconds, minutes, hours, days, years). Always set a timeout, because this is your protection from the system locking up and becoming inaccessible. stress runs in userspace and can't cause any damage, but it would be sad to have to reboot to stop it.

--verbose makes it spit out many lines telling what it is doing.

The example above is pretty wimpy and won't stress out anything made after 1990. You can run one test at a time, for example. This puts a much larger load on your CPU:

> stress --cpu 2000 --timeout 30s --verbose

Just for fun, follow along with top, and press 1 to see all cores individually:

top - 18:58:17 up 8:56, 9 users, load average: 419.86, 226.40, 88.02
Tasks: 2207 total, 1449 running, 756 sleeping, 0 stopped, 2 zombie
Cpu0 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 98.1%us, 1.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu2 : 97.7%us, 2.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
When your stress run is finished, notice the difference in the Tasks statistics and load averages.

You can control the load on your memory with the --vm-bytes option. Suppose you have 8GB memory, which is not unusual in these here modern times. Try this:

> stress --vm 2 --vm-bytes 6G --timeout 30s --verbose

Be careful with this because thrashing your memory can make your system hang. The vm option allocates and releases memory; the vm-hang simulates low memory conditions by having each hog process go to sleep, rather than releasing memory. This example hogs 3 gigabytes of memory:

> stress --vm 2 --vm-bytes 3G --vm-hang --timeout 60s

What happens when your system is I/O bound? Try this:

> stress --io 8 --timeout 2m

Test your hard drive by writing a large file to disk:

> stress --hdd 1 --timeout 5m

The default file size is 1GB, and you can specify any size with the --hdd-bytes option, for example --hdd-bytes 5G writes a 5 gigabyte file.

stress is tidy and cleans up after itself, so you shouldn't have to worry about leftover hogs running amok. The documentation on stress isn't exactly lavish, and the most complete help is in info stress.

Other Commands

Visit the Stresslinux software page to see all of its system-testing commands. It includes reliable standbys like CPU burn, memtest, bonnie++, lshw (list system hardware, my fave), tiobench, and smartmontools. There are a lot of nice Linux bootable system rescue distros that do this and that and everything, but I think Stresslinux is tops for a good specialized distro.

Taken From: https://www.linux.com/learn/tutorials/613523:stresslinux-torture-tests-your-hardware

Thursday, November 14, 2013

Serial Port (RS232) - Null Modem / Straight Through

The Difference Between a Null Modem and Straight Through Serial Cable

Hardware: Serial

Problem:
I would like to use my computer's built-in serial port to communicate with a serial device, and I have both the null modem and straight through serial cables. What is the difference between the two cables, and which one should I use?

Solution:
The null modem cable is frequently called a crossover cable. It is used to allow two serial Data Terminal Equipment (DTE) devices to communicate with each other without using a modem or a Data Communications Equipment (DCE) device in between. For this to happen, the Transmit (TXD) pin of one device needs to be connected to the Receive (RXD) pin of the other device. To enable handshaking between the two devices, the Request to Send (RTS) pin of one device must be connected to the Clear to Send (CTS) pin of the other device. Because these pins are "crossed" on the two cable terminals, the name crossover cable is used.

Simple Null Modem Cable

Null Modem Cable with Handshaking

A straight-through cable is used to connect a DTE device to a DCE device. The TXD-RXD and RTS-CTS pins are not cross-connected in this case, hence the term straight through cable.

Simple Straight Through Cable

The built-in serial port on a PC is a DTE device. Modems and printers are examples of DCE devices. Note that an instrument with serial interface could be either a DTE or a DCE device. It is best to check the user manual of the instrument to find out the device type. For more information regarding DTE and DCE devices, please see the links below.
To tell if your cable is null modem or straight though, you can search the part number at ni.com, the product description will tell if it is null modem. Alternatively you can use a hand held DMM to test continuity on the individual pins of your serial cable. If every pin is electrically connected to the corresponding pin on the other end, i.e.: pin 1 to pin1, pin 2 to pin 2, etc. then the cable is straight through.

Attachments:

Report Date: 22/12/2004
Last Updated: 18/06/2010
Document ID: 3GLDMSIT

Taken From: http://digital.ni.com/public.nsf/allkb/1EE0DD8AF67922FA86256F720071DECF

Sunday, November 10, 2013

Make Your own PoE - Injector and Splitter

Make your own Power Over Ethernet Injector set for $2 in Parts

Ever need to install a network hub, camera, or other device in a location that did not have a locally available power outlet? Need to ‘extend’ the power cord?

In this tutorial, we’ll be building a very cheap Power Over Ethernet Injector out of $2 in parts. This will let you place your power supply for your device near the ethernet hub, where power is plentiful, and place the device itself hundreds of feet away.

Caveat: There is a Power Over Ethernet (POE) standard, which we’re ignoring, as this particular injector setup is for legacy products that do not offer POE support.

The standart states the minumum power supply should be:

44V DC / 350mA = 15.4 Watts

so for standart compatibility (802.3af - PSE Mid-Span) you would have to use a 48V DC power supply with equal or more than 350mA.

In my case, I’m making it for my wired network camera, a Hawking HNC-210, which is generally alwayssituated farther away from the power outlet. It comes with a fairly short (6′) power cable, which is an odd product design consideration. Since you’d generally put a camera at eye-level or higher, this cable is really too short for most installs.

Parts List: $1.80 US:

1. RJ-45 pass-thru connector 80¢
2. 2.1mm power jack and plug 50¢
3. spare (short) working ethernet cable 50¢

The first item we need is an ethernet (RJ-45) pass-thru connector, for patching 2 ethernet cables end to end. It is available at many local retailers/computer shops. I grabbed a few at BG Micro for 80¢ a piece. The nice thing about these is you’re getting 2 pre-wired RJ-45 connectors for very cheap.

A bit of man-handling to pry the two halves apart, and we have 2 halves of our POE injector. Simply cut all 8 wires at the half way point. You can tell which wire goes to which pin by looking at the inside of the now disassembled connector. Take notes of which wire goes to which pin, using a regular ethernet cable as a reference. There are 8 wires, which we need to be grouped. 4 wires are for ethernet, 2 wires for Positive Power, and 2 wires for Negative Power (Ground).

You’ll need to strip and tin all the ends of each tiny wire on both pieces. We’re basically hand-wiring connections for power and ethernet in each connector. Use the wiring table later in this article to make the connections. While you’re here, why not put some shrink tubing over each wire to protect them from cross-connection later.

I need more Power, Scotty!

Next up in the arsenal, we need the power jacks to pass the power from the AC wall wart to the camera. I checked the camera, and it used a standard 2.1mm power jack. I picked up 2 example jacks from an electronics supplier.

The top set is an inline jack and plug, which costs $1.20 for the set. The bottom set is an panel mount jack and plug, which costs considerably less, at only 50¢ for the set. First, check to make sure they work together.

I soldered 2 wires to the power plug that were equal length to the ethernet dongle I already had on hand. I slipped some shrink tubing over it, then made the connections.

With the Power Connections, polarity doesn’t matter as much as making sure you don’t flip the circuit with your cable build. If you decide blue is tip and brown is ground, stick with it at both ends of the injectors – not following this is a sure way of destroying the device you’re powering.

In my case, I connected the tip of the power plug to BOTH the 2 blue wires, and the shield to BOTH the 2 brown wires. On the other side, I connected the same to the tiny panel-mount power jack. I then used hot-melt glue to mount the panel mount to the remaining plastic frame.

Why connect to both wires? In case one wire fails in a regular ethernet cable, it’ll still work. Plus, there is less voltage loss with the larger combined wire. The total voltage loss is negligible for most installs. If you find your device isn’t working properly, check to see if the cable is too long, and the voltage is too low to power the device.

Next up the complex ethernet wiring….

Common straight-through ethernet cables only use 4 wires out of the 8 inside the sheathing. The common wiring in illustrated below.

Take your short working ethernet cord and cut it in half. You’ll want 2 short 8″ pieces, with the working ethernet RJ-45 ends still attached. Strip off an inch at the cut end, and expose the 8 wires inside. Cut the blue and brown sets of wires off. These are unused in this application – these ‘dongles’ will be the ethernet in and out connections.

So the ethernet wires (in most cases, you should check) that we’ll be using to pass the ethernet traffic is the 2 orange wires and the 2 green wires, which fall on pins 1, 2, 3 and 6. Simply connect the pin 1 on the ethernet dongle to pin 1 on the ethernet connector jack, and so on through the other 7 wires on both sides.

Finished Power Over Ethernet Injector and Splitter

I covered open connections with shrink tubing, then tucked all wires inside the tiny connector cases. I then used hot-melt glue to seal up the open ends of the connectors, and now I have a matched pair of Power Over Ethernet Injectors!

Installed at the Camera End

Simply attach one end of your 100+ foot long ethernet cable to this end, place your camera anywhere, with only one cable feeding to it.

Installed at Hub/Switch End

At the other end, at the switch/hub (also suitably close to a power outlet), simply plug it into an available port, plug in the power supply, then the camera feed line.

Shield your eyes! Cable Porn! Shocking double-69 cable-on-cable action!

Based On: http://underdesign.wordpress.com/2010/04/07/make-your-own-power-over-ethernet-injector/

PoE Standart Details: http://www.ieee.li/pdf/viewgraphs/introduction_to_poe_ieee802.3af_802.3at.pdf