There is a device (D1) on my network that sends ASCII data over UDP port 5000 to a DVR which overlays text onto a composite video stream output. I want to overlay that data on a network IP camera stream. But the first step is to confirm that there is in fact text data over port 5000, and because I don’t do anything the easy way, I built a box.

Let’s start at the beginning.

The Beginning

The concept for this text overlay operation is that it runs between the network camera and the router. That way the DVR will see it as a legitimate camera feed even though text has been added (the text from port 5000). The text overlay function works really well currently using composite video to a network-enabled DVR connected to D1, and I’d like to know how. So the Text Box (watch out folks, highly technical term here) will need to have the following features:

1. It will intercept the IP camera feed before it reaches the router. Because I said so.
2. It will have its own IP address, for D1 to connect and send the text data.
3. It will capture that data, time stamp it, and store it on some removable storage media.
4. It will overlay that data onto a live network camera feed, and send that feed so that it looks unaltered back to the DVR like it ain’t no thing.

I have a feeling I might need consult the masters of video cable taps and data injection, Eric and Zach. But in the meantime, I’ll need a simple network tap to confirm and capture sample data from D1 on port 5000.

To that end, I build this simple passive network tap box out of stuff just lying around. I used a punch-down tool, some junction boxes, and Cat5e. It is important to note that this kind of tap has some pretty serious Gigabit Base-T issues, and is not compatible with IPv6! Not even a little (well, maybe a little). Apparently those kinds of taps require an independent power source, or have tons of other issues related to electrolon-enabled super-flux capacitive midichlorians, and just aren’t feasible for a project of this scale. Also, if you plan on using this tap for totally legitimate network snooping on your own totally legitimate network, you should know that there will be a small amount of downtime while you plug everything in (unless you do it live, and then still).

The Tappy 1

To build the Tappy 1 (or Tappy-Bird, or Love-Tap, or Aw-man-she-gave-me-the-Tap), I needed a few things. First the network cable. Like I said I used Cat5e, a punchdown tool, and 2 network junction boxes.

The first step is to cut and strip the cable. Against the better judgement of FCC, I removed all the casing from the ethernet cable because it is so short that EMI (electromagnetic interference) shouldn’t be a problem, and because I like to live dangerously. Keeping all the pairs twisted until right before you terminate the cable helps ensure that very little EMI wiggles its way into the re-purposed series of tubes (not that I care, because Danger is my middle name).

Using the great info from Janitha’s site and this stuff from Ossmann, I pulled up this diagram and started punching down the cables.

The idea is pretty simple; Host A and Host B exchange data over pins 1, 2, 3, and 6 (Tx+, Tx-, Rx+, and Rx- respectively). The pins are punched down and not terminated on Tap A and Tap B, to allow another device to see the data stream in that direction. One tap works perfectly well for this project, as I only need to see the text stream going from D1 to the DVR, but if you need to monitor both directions simultaneously, you’ll need two cables and ostensibly 2 NICs, and also a linux version of Wireshark, because the Windows version of Wireshark’s support for 2 NICs is complicated.

So I happily began punching down my cables (inner-tubes?).

You’ll notice I renamed hosts to A and B, solely to confuse you.

I also switched which side would be Tap A and Tap B because again, I am a rebel. Also D1 uses a crossover cable, which makes this make sense (somehow). In actuality, it doesn’t matter so long as you know which side is which.

Pro-tips:

1. Make sure you punch everything down snugly.
2. Check your punchdown tool tip, some have a little blade that cuts the wire on one side for termination. Don’t cut the wire for the taps – you’ll spill all the electrons.
3. Some punchdown tools require a lot of force, but you’re not trying to win a wrestling match (lolwateven is wrestling?). Don’t break the thing or Private Hudson’s gonna get you.

Once all the cabling is hooked in properly, use a network testing tool to make sure that all the cables are connected properly. Then take the board around and show it to all your friends so that they know just how cool you really are (after all, you told them they’d be sorry one day). Then plug this bad boy in and sniff your tap. Or something.

Wireshark

I’m running Wireshark through Kali Linux on Oracle Virtualbox. I had to use a USB-to-Ethernet adapter, because my VM had issues talking to my NIC (don’t we all). D1 goes to A. B goes to the DVR. Kali sniffs on either tap.

I didn’t document which tap gave me the data I needed, but it was probably the tap on Side A because that’s where Host A’s Tx+/Rx- wires were tapped and that’s how Tx and Rx stuff works.

After configuring Wireshark to use the USB-to-Ethernet adapter for capture (I used the GUI version of WS for this because fuck you), I ran a short capture filter command to make sure I was only getting the things I needed.

udp.port == 5000

Plugged everything in. Made sure that both D1 and the DVR were on. Tested the working text overlay functions on the DVR. Ran WS.

And wouldn’t you know it, nothing exploded! And it worked!  The ASCII data came in clear as a bell (no crosstalk, or interference of any kind), and I was able to see exactly what the DVR sees to do text overlay from D1.

Theory (Or Do The Twist)

There are a few reasons why EMI isn’t a huge issue here, even though it looks a little sketchy having all these exposed wires waggling all over the place. Let me throw a little knetwork knowledge knugget your way, in case you are a nerd.

Ethernet cables are made up of these 4 pairs of twisted wires. Each twisted pair of wires are known as a “balanced pair”, which means that equal and opposite signals are sent and received by both wires (kind of). Blah blah blah when two pairs of untwisted wires run in close proximity to each other over a moderately long distance, the EMF from one pair will spill over into the other pair, inducing something called “crosstalk,” the effect of which is additive and correlates directly to the length of wire in parallel, among other things.

Thus, twisting the wires reduces the length of any wire running parallel to another for too long, giving the electromagnetic signal from pair A less of a chance to interfere with pair B. However, twisting them all the same way can actually bring back some of the crosstalk, so it’s seen as a best practice to twist the wires at a slightly different rate (wire twists are actually measured in twists per meter by people with nothing better to do who get paid to count wire twists). The twists even vary by network cable; Cat5e and Cat6 are compared below.

There is an excellent list of some general rules for LAN cable length over here. Allow me to read you an except.

There is NOTHING more annoying than spending 30 minutes debugging a network problem to find it was the cable. Badly made or non-standard cabling is a foolish thing to spend time on – do it once and do it right. This guide may help you to forget cabling problems and spend time doing really useful things™ – like pondering the meaning of life or watching TV.

Truth.

Next Time, on Curious Kitty Playtime Adventures –

The Tappy 1 was a big success – it did everything expected of it. EMF wasn’t an issue (as we have learned), and I captured all the data I needed for my script.

However no design is perfect, and there are plenty of ways to improve. For the Tappy 2 (or Taps-all-folks, or Just-the-Tap, or Tap-Trap 5000 ), here is a short list of things I would do a little differently.

• Get a real enclosure

This one is a given. Tappy 1 is basically just 2 circuit boards connected by loose wires. While this is hilarious perfectly functional, a heavier-weight enclosure would give it some desktop stability and up the cool factor by at least 300% (then they’ll be sorry!). Maybe there’s a way to re-purpose a totally normal network switch enclosure.

• Use proper cable twisting technique

Even though it worked with all these exposed wires, taking steps to curb potential interference from the very beginning is best.

• Expand functionality to IPv6

Probably not because that is hard, and I don’t care that much. Yet.

So Tappy 1 was great. Tappy 2 will be even greater if I ever end up needing / wanting it. All is right with the world. On to phase two of operation text insertion yarnball adventure-cat wonder story the movie.