Phil & Tim Taylor go over some of the features of the DD-WRT router firmware and how they can be used to secure a home network.
Find it on iTunes, vanilla RSS, YouTube or the show notes website.
Saturday, December 28, 2013
Thursday, December 26, 2013
If, like me, you're tech support for family and friends you often have a need to take remote control of a relative's machine over the internet. There are lots of ways; the easiest being the paid-for services like GoToMyPC, TeamViewer etc which all offer NAT traversal with very little effort required at each end to make them work. You just give the person you're helping a ticket number and a URL and before you know it (and normally by Java or some other active web content) you're controlling their screen. They have VOIP as well and it's very slick. However, I don't do enough remote support to justify keeping an account going at ten dollars a month and I quite like VNC/RDP etc.
The problem with those protocols is that you need to know the public IP address of the recipient's router and this changes by the vagaries of their ISP and DHCP etc.
So, here's my method for always knowing the public facing IP address of your Mum's computer without having to run anything clever at her end or anything as elaborate as a VPN.
- Make sure you've made a port-forwarding rule on their router so that when you hit them on port 5900 (for VNC) or port 3389 for Windows remote desktop it gets forwarded through to the target machine; you'll probably have to have given that computer either a fixed IP address or have set the router to always assign it the same DHCP'ed IP address.
- Have that machine genarate a file at boot-time that contains the correct external IP address along with any other salient data that you might find useful.
The first part requires you to know their router - it's not hard, you'll just need to look around in its web interface. Here's how I do the second part;
I stick these four files in a convenient directory - typically c:\tools\ but anywhere will do.
wget.exe is an open-source Windows implementation of the common Linux/OS-X tool that fetches text fields from a web server.
GetIP.bat is a Windows batch file that sticks the output of wget into a text file and appends some extra stuff (IPConfig, date and time) and then initiates an FTP session with any web space you may have under your control. Finally index.html is the generated text file (makes the final URL easy to remember).
ftp.txtwget http://ipecho.net/plain -O - -q > index.html
ipconfig >> index.html
time /t >> index.html
date /t >> index.html
ftp -s:ftp.txt ftp.plus.net
cd htdocsStick a shortcut to GetIP.bat in the startup folder (and for extra finesse have it run minimised so nobody sees it) and every time the machine boots you get uploaded to the webserver a very useful status page;
So long as you have a VNC or RDP server running at the remote end you're now only a moment away from being a tech support super-hero!
Saturday, December 21, 2013
I've just finished building the technical infrastructure for a big media company who are moving premises. The job has gone rather well and I've been trying to crystallize my thoughts as to how it's differed from jobs that haven't been so enjoyable. From my point of view it all breaks down into three areas - the client, the contractors and time.
- Big broadcast and film companies always have in house people who manage projects and the disturbing trend of recent years is to have project managers who are very conversant with Prince2 or some other methodology, but often don't have a background in broadcast engineering (or indeed any technical discipline). They tend to be disinterested in the way that non-technical people are when they don't understand something; it's easier to be dismissive than show your ignorance.
- "Getting a good deal" - When I'm quoting for a job and the customer starts talking about discounts and good deals from the outset it raises a red flag for me; they're cheap and will want to reap where they do not sow. They'll be a problem and so I'm going to put fat on the bones of the job where you won't know about it as I'll need that later on. As soon as you start driving us down on cost then assume you aren't getting a good deal.
- Penalty clauses and "open book" jobs - see the previous point.
- Holding back tens of thousands of pounds because of a tiny fault in one piece of equipment that requires as firmware update from the manufacturer. They won't fix it any quicker because the SI is hurting!
- Often on large jobs the builder is the primary contractor and everyone else answers to him. If the SI is a direct-appointment then it's often a nightmare getting access to the things you need ahead of the electricians, data guys, air con guys etc as you are viewed with some suspicion.
- Having the electrican/data guys/gardener run the cat6 cable - it happens and it's never pretty! You don't realise what you do until you work with someone who doesn't do it. A job last year had us trying to unpick 700 cat6 feeds that had just been dumped into a hole in the floor of the machine room. Many weren't numbered and some even had different numbers at each end. It took three of my wiremen ten days to sort them out and identify them. Of course the customer was unhappy to pay for that.
- It's nice to be in the happy position of having enough wiremen to have them play to their strengths. The job I've just come off had between eight and sixteen wiremen and so I could have the guys who were good at fibre just doing that, the good data guy just doing cat6 panels and the good mechanical guys assembling bays and wallboxes. I was even in the nice position of being able to have one guy responsible for stores. It's a rare but pleasant state of affairs.
- The job I've just come off had a very compressed timescale - ten weeks for two machine rooms (seventy+ cabinets) and twenty+ production rooms. This sort of thing is only do'able if the customer isn't being "cost conscious"
- A timeline is always good; those last minute jobs like programming the router, labeling the patch panels and all the testing take longer than you remember!
- AT LEAST a week is needed to really understand the workflow and hence produce the bones of a design that will work.
In the end you have to guide the customer to understand the golden triangle of all technical projects;
You can only ever have two of these!
Friday, December 20, 2013
I'm looking forward to getting the beta hardware of the Oscilloscope Watch which I've funded on Kickstarter. Here is a recent project update from the developer.
Project Update #9: Beta PCB assemblies on order
Posted by Gabriel Anzzian
Sorry for the delay, I've been pretty busy these last few weeks. Here is my monthly report.
I have done some minor changes to the schematics:
- Reduced noise by connecting the 5V step-up switching regulator to the battery, instead of the VDD rail. It will also be a little more efficient, since the regulator is converting 5V from 3.7V, instead of 3V.
- Minor tweaks to reduce current consumption: increased value of some resistors, changed the diodes to low leakage versions.
- Removed the 15pF input capacitors, which aren't really needed for the bandwidth that the OW works with. I also needed the space to add mounting holes.
- Added load capacitors to the 32.768kHz crystal.
I had a hard time making space to add the mounting holes while still keeping current packages of the components. I only changed the LEDs from 0805 to 0603. Now there are two nice mounting holes on opposite corners, which will be great for fixing the PCB to the enclosure. I also moved the slide switches towards the center to solve a problem with the enclosure as discussed on update #4.
Oscilloscope Watch PCB rev 1.4
I originally thought of assembling the Beta units myself, this was when I thought I would have only 10 Beta testers. Now with 28 Beta tester units, and a few spares, it makes more sense to have these assembled at the factory. I am ordering the assemblies and they should be ready in about 6 weeks.
I am going with a 380mAh battery, it measures 40mm x 30mm x 4mm, the dimensions of the watch are not changing. I have already received enough samples of these for the Beta tester units. The battery life should not change much from the initial estimates.
BACKLIGHT & FRONTLIGHT
I bought a translucent filament to use on my 3D printer to make a backlight diffuser, it didn't work. The problem is not because of the translucent diffuser, which I already knew that it was not going to be too good. The problem is the LCD it self, it does not let much light go thru.
So I started to research what I needed. I contacted Sharp and they referred me to a company that does "front lights". I have just began talks with them, we are signing NDAs.
The Beta units will still have the backlight diffuser, but this is to make everything fit together, rather than functionality.
Not many changes to the enclosure. I tweaked the sliders to fix the collision problem, I moved the charging LED location to right above the USB connector, and made the LED see-thru holes circular. I also added the screw bosses on the TOP part.
I haven't done much to the code, only some minor tweaks to reduce current consumption during the watch mode. Once I get the Beta units, I will set up a repository, initially for Beta Testers. I am looking forward to working with the Beta Testers!
A lot of work to still to be done, but it sure is fun!
Tuesday, December 17, 2013
At ten gigabits ethernet over copper cable really struggles. Everything has to be just right and even well terminated twisted pair cable is on the hairy-edge.
On the job that I've just finished had a lot of fibre and copper data and the time to test (on a per circuit basis) is much higher for copper than fibre. With OM3 fibres so long as you have an acceptable sub-3dBs of attenuation at 850nM ten gigs is a doddle. We had to re-terminate maybe half a dozen circuits and using our INNO core-alignment splicer it takes no time. On the other hand getting the copper data cables right is a mission with Near-end cross-talk, alien cross-talk and return loss all having the be measured across four pairs. The output (above) is from our Fluke DTX-1800 analyser.
As an aside, one of the freelancers I use a lot showed me a brilliant trick with fibre panels); the BT standard for core-order involves having the coloured and striped cores 12 couplers away from each other in a 24-port panel. The better way is to put the coloured and striped cores next to each other in the same duplex pair so that if you make a mistake it's easily rectified at test-time.
Saturday, December 14, 2013
I recently installed a 288x288 Universal VideoHub from Blackmagic - bear in mind this thing has 576 coaxial video connection and 288 RS422 ports it takes more than a day for a wireman to do a nice job of plugging it up.
here's one we did earlier!
Also bear in mind this is a modular system with space for 72 interface cards - each one has four HD/SDi ins and outs (up to 3G 1080 50/60P fact fans!) as well as a proprietary connector with four RS422 standard machine remotes.
So - once unboxed I filled up the chassis with cards, control modules and power supply cards and bolted it into the cabinet. However - the power supply units were delayed and so I got Tony the wireman to finish dressing it in before I powered it up; what a mistake!
I eventually got around to firing it up expecting to start programming it the same day but imagine my horror when I discovered 20 of the 72 modules were not showing up in the GUI. Swapping cards around showed that I did indeed seems to have twenty duff interface cards; pretty poor quality control I thought. BM UK's tech support department gave me the impression they didn't believe me and after lots more swapping of cards they agreed to take them back.
I called them the following day only for them to tell me they couldn't find any faults with the cards we'd returned! I asked them to go over their testing methodology and the engineer started with "...I upgraded the firmware on the cards and inserted them into our test chassis"; exactly how I'd started - well, long story short, in the three days between me starting and them getting the cards to test BM had issued a new version of firmware. They'd gone from 5.0.4 to 5.0.5 without giving any indication to UK support as to what the changes were. It turns out that 5.0.4 disables some revisions of the card! How many of that version of the cards did I have? Twenty.
It seems like 5.0.4 was only out for less than two weeks...?!
Monday, December 02, 2013
From now on all Engineer's Bench goodness will be at it's own domain;
What is worth noting is that only a minority of our watchers do so via iTunes/RSS - most folks now get it via Youtube, and so that has been unaffected and can still be found at the same old place.
We've been a bit slow recently but it's just the pressure of work. We have several planned:
- KVM-over-IP - a technology whose time has come
- Software tricks and tips with Excel and other software for broadcast engineers
- Hardware pt.2 Raspberry Pi and NetIOM control boards
So hopefully 2014 will produce a return to form for your favorite broadcast engineering related video podcast!