Friends don't let friends use stock firmware in their routers, part 2

Just a month since I wrote the first piece on this and there are more domestic router breaches.

1. "The Moon" worm on Linksys routers - The worm works by injecting vulnerable devices with a URL-encoded shell script that carries out the same seek-and-hijack behavior. The exploit may also change some routers' domain name system server to 8.8.8.8 or 8.8.4.4, which are IP addresses used by Google's DNS service. Compromised routers remain infected until they are rebooted. Once the devices are restarted, they appear to return to their normal state. People who are wondering if their device is infected should check for heavy outbound scanning on port 80 and 8080, and inbound connection attempts to miscellaneous ports below 1024. It seems that most E-series Linsys routers are vulnerable. 
2. ASUS routers expose shared USB drives over the public internet - The exploits against Asus routers has been known about by Asus for a year and they have yet to correct it in old and current models. 

 Ars Technica's stories are here and here. 

Do I really need to remind you NOT to use manufacturer firmware in your router when DD-WRT, Tomato and others are available?

Antrica - performance at different data rates

After my testing with the Antrica 32000AS I thought I'd better do some screen caps at different data rates; all the tests I did yesterday were at 2048kBits/sec.

32kBits/sec

256kBits/sec

512kBits/sec

1Mbits/sec

10Mbits/sec

It does seem that you don't get much benefit once you pass 2Mbits/sec - now these are only still frames and sub-500kBits you get quite a few dropped frames (I haven't figured out how to increase the buffer size at the receiver which apparently smooths this out at the expense of latency).

Finally, in an effort to get a feel for the overall degradation of HF content I grabbed a couple of frames at field-rate at each end of the encoder's range;

32kBits/sec

10MBits/sec

Antrica video-over-IP encoder/decoders

Every TV industry magazine is currently honor-bound to run a "video-over-IP will replace baseband this year" article at least once every three months. Despite the attraction of sending video over networks there are fundamental problems related not to the fact that it's a network (but, then again TCP/IP was never meant for synchronous, timely delivery of data) but rather the compression used. Actually, not the compression (after all MPEG4 v.10 variants; H.264, AVC etc are pretty good) but the latency; for long-GOP material 12-frames encode is not unusual.

I was pleased to get my hands on a couple of Antrica 32000-series encoder/decoder units. These are HD/SDi and HDMI i/o and you can configure each to be either an encoder or decoder. They are clearly based on a security camera chipset (all the Pan-Tilt-Zoom controls are grey'ed out!) but they have some very nice features;

• The outputs remain live when one is being used as an encoder so you can get a feel for what the untransmitted pictures look like (it isn't just a loop-through of the input HD/SDi). 
• They have up and down converters and so a 1080i input signal can be sent at 720P and an incoming 720P stream can be displayed at 1080i (or SD, for example).
• They have three streaming modes; their own single-port over TCP mode that streams macro-blocks and hence gives incredibly short latency; 80mS at best but more likely 200mS. A buffer at the receiver end can be wound-out to smooth the spikiness of the data rate (with the worsening of the latency). If that isn't working the units fall back to RTSP over TCP or UDP and finally if all else fails MPEG Transport Stream over TCP.
• They also do a software video-wall that will receive a dozen streams.

So, proof of the pudding and all that. I made a 1080i sequence of static frames with resolution gratings and so moving stuff. At only 2MBits/sec (which is allowed to spike-up to 3MBits/sec) I was impressed. Here is BBC HD Test-Card F straight into the monitor and then via the system;

 

The aliasing you can see on the lower gratings is from my iPhone's camera - you really can resolve them to the 15Mhz grating, so no resolution is seemingly being lost.

 These two are taken from the Belle Nuit Montage test chart which shows up all sorts of problems with resolution, colour-space and levels. The finest grating is not resolvable in 4:2:2 encoded material and so what you're seeing here is in part an artifact of the sampling structure of 1.5GBit video.

This is a screen-grab from my trusty Tektronix WFM7100 - I've parked the line-selector on that final grating and zoomed in so that we're looking at 300nS/div on the horizontal. The waveform has been faithfully reproduced with only a low-frequency (I estimate 2Mhz) harmonic. I initially thought this was a fault in the optical transfer function of the monitor but it's there on the signal.

I was playing off my laptop via a Black Magic UltraStudio Express. If you want to play with the clip I've stuck it in my useful clips folder on Google Drive (there is also so DolbyE material in there). It's also worth mentioning they have a software tool for monitoring their end-points. It's called True Manager can as well as allowing you to tweak settings etc you can also monitor in realtime the bandwidth used. This is all very encouraging as tomorrow I will stick an encoder in Root6's office and see what sort of performance I get across the public Internet. As ever with these systems they are adaptive and for still frames they settle at a very low data rate, but at scene changes the system seems to spike to around 50% bandwidth than I'd configured. BUT, the fact remains, I *seem* to be seeing very nice looking 1080i pictures over a few MBits/sec!

System Design with Excel - The Engineer's Bench Podcast

Phil and Hugh go over a few tips and tricks for using MS Excel in the design of film & TV facilities. Find it on iTunes, vanilla RSS, YouTube or the show notes website.

A lie can travel half way around the world while the truth is putting on its shoes.

Not that Mark Twain knew much about fibre optic cable. If he did he'd realise that he was only talking about seventy milliseconds...!

I often have to provide proposals and quotations in response to customer's tender documents and in the last six months I have seen three such tenders specifying tight-buffered fibre for their internal networks.  When I push their staff engineers for a justification they "um and err" and are easily persuaded to do the right thing (i.e. use spliced loose-tube fibre). If you need to read up then I've written a few things in the past.

Last week I came across the following from the Argosy website;

Tight buffered cables are intended for indoor applications. They are more hardwareing than loose-tube cable, as such they are well suited for long indoor LAN connections, burial or complete even submersion in water. Tight buffered cables have a special two-layer coating. The first layer is plastic, the other a waterproof acrylate.

I wonder if this mis-information is their doing?

Friends don't let friends use stock firmware in their routers

Over the years the number of security flaws that come as standard with £50 plastic-box routers have been numerous. That 'free' router that came from your ISP probably suffers from one of these;

1. UP & P enabled by default
2. PING on the WAN side enabled
3. Port 32764 left open

That last one is very serious as it allows a remote attacker to make a query of the router and dump out lots of diagnostic and configuration information. That may be of no consequence but it does allow a hacker to gain knowledge concerning your network and work on other attacks. The problem bedevils Linksys and Cisco models and SlashDot have a good write-up.

In a very real sense your router is the gateway between your network and the wild-west that is the public internet. If you can't even trust the little hardware device that sits in the cupboard under the stairs what can you do? Well, use an open source firmware in your router - Tomato is very user friendly and DD-WRT is very powerful. There are numerous others and since the source code is open it is regularly examined by the community that develops it and so many eyes spot any nasties (malicious or just bad programming) in the code.

I grabbed a couple of Buffalo models from eBay for when my eldest two went away to University and I wouldn't dream of letting my home network be based around a closed-source router.

Chassis vs Signal earth on RS422 remotes

Grounding is essential to reliable operation of any RS422 connections. It is also the most overlooked and least understood. The easiest way to ground your RS422 equipment is to simply use "Earth" ground as your return path. Although easy this may not be the best method for grounding your application, because current leaking from equipment, electro-static discharge (ESD), and lightning all drive current through this path which results in high noise content. The reason for this increased noise level is due to the fact that "Earth" ground presents a relatively high resistance. RS422 is designed to operate normally with a ground potential difference of +/- 12 Volts. During normal operations this is typically not a problem, however during fault conditions or lightning strikes even within ½ mile the ground potential difference can reach hundreds and in some cases thousands of volts. This will most likely result in damage or failure of one or more devices on the RS422 router.

In TV facilities I most often come across three methods of earthing;

1. No earth - assume that the mains return is good (all equipment is class-1 and bolted into it's bay and that signal and chassis earths will be close)
2. Use pins 1 and/or 9 on the 9-pin D-type to couple the chassis earths together; please, don't get me started about intentionally connecting mains earths between different areas! Do you like dealing with induced hum between different areas or buildings?!
3. The best way; using pins 4 & 6 - the signal screens (it's what they're there for).

The job I'm finishing at the moment had a problem with Digital Rapids workstation which wouldn't run through the RS422 router although patching around the router worked - the PC could control a VTR. My first port of call was to test the cabling/router patch by sticking an old Sony RM450 edit controller at the back of the Rapids and pretend the RM450 was the workstation - all good; VTR control and timecode return worked fine (so Tx and Rx doing their things). 

So my first thought was to measure the impedance between the signal ground on the router and the mains earth - high Z so no return patch for the RS422 via the router if it was relying on the mains earth (scenarios 1 & 2 above) and since the router is optically isolated on it's data inputs I wasn't surprised. That is the way it should be done.

Now then; most PCs that are running video apps and have to control a piece of broadcast kit use an RS232 port with an external RS232-422 adaptor. These essentially just balance the Tx and Rx pins and there are several models. None of them (in my experience) actually use a pair of rep coils to properly balance rather they use a pair of op amps in a differential input configuration. This is fine but doesn't have the noise immunity that you get with coils (common mode rejection). What it does mean is that all of the noise immunity of the circuit comes from the electrostatic shielding of the earth and so you better get it right!

I cracked open the cheap'n'cheerful '232-422 adaptors supplied with the rapids and they had the screen connected to the shield of the 9-pin on the RS422 side (so relying on scenario 1 above). Moving that to pins 4 & 6 (scenario 3) fixed the problem. 

As an aside the Adenda "Rosetta Stone" adaptors that Avid supply do the right thing!