Watching TV Is Dangerous

I am not talking about humans.

But TV-sets might threaten other devices in the smart home; this was a recent puzzle submitted by a blog reader.

Two unrelated devices / services met on the user’s local computer network:

  • IP-TV provided by a large German telco.
  • a data logger for monitoring the heating system.

This user had one of the solutions in place that I mentioned in my previous post on data logging: The logger BL-NET connects to the controller UVR1611 via CAN bus, and to the computer network via ethernet, and it acts as a ‘CAN-ethernet gateway’ to allow for logging data to database server on the network, hosting the application UVR Data Logger Pro.

Data Logger BL-NET, with ethernet, CAN, and USB interfaces (My attempt at 'organic tech product photography.)

Data Logger BL-NET, with ethernet, field bus, and USB interfaces (My attempt at ‘organic tech product photography’.)

The issue: Every time the user turned on the TV, BL-NET suddenly refused to work – communicating its predicament via a red LED. The IP-TV did not use up all the band width; so my suspicion was that the TV (or TV service) sends a network packet that the logger does not like; perhaps a special unicast or broadcast message too sci-fi-like for it. Or any of the parties involved does not strictly comply with standards. Or standards might be ambiguous.

It would have been interesting to do network analysis and trace the network traffic and spot that packet of death. But the logger BL-NET had been superseded by its successor – called C.M.I. – Control and Monitoring Interface – which has better out-of-the box logging, cloud support etc.. Since the open source UVR Data Logger Pro does not yet speak CMI’s protocol so I understand that users do not want to change their solution immediately. But it is unlikely that BL-NET will get firmware updates, and it is very unlikely that a large internet services provider will change its IP-TV communications protocol.

My suggestion was to shield the logger from packets sent by the TV – by tucking BL-NET away in its private subnet – using a spare internet router or the sniffer-router PC I had described in Network Sniffing for Everyone:

The ‘spare’ internet router was placed behind the main internet router, connecting its ‘WAN’ port to the main LAN, and BL-NET was connected to a LAN port of this second router.  If the router is a PC with sniffer software this configuration would also allow for researching the evil packet.

In order to avoid running yet another box consuming electrical power, one might also…

  • add another network interface to the the UVR Data Logger Pro database server and use this one as that router.
  • replace the internet router by one that can be configured for more than one virtual LAN (in case the current one does not have this option).
Bundesarchiv Bild 183-H0812-0031-001, Werbung, RFT Color 20, Fernseher

At that time, TV-sets did not yet jeopardize the integrity of other devices in the dumb home. Ad for color TV set, 1969. (Bundesarchiv – German national archive, Wikimedia)


7 thoughts on “Watching TV Is Dangerous

  1. Excellent solution. It will provide a permanent solution that never needs tinkering. I believe this type of problem is one that will become increasingly prevalent. Its also a good reason why consumers should always buy an access point with a multiband radio ☺

    • True – I have also fixed some weird WLAN connections issues with a two-band radio router.
      I can’t be tested in this case as the devices in question needed wired connections – but it would be interesting to investigate if it would helps. I think it depends on where in the protocol stack the clash happens: Different bands separate connections from the devices to the router at the lower layers, but the devices’ communications will still ‘meet’ at the upper protocol layers in the local subnet. I hope normal routers will provide virtual LANs in he future!

      • Indeed–the best solution of all. Keep ’em separate ’til the end 🙂 On that track, though, here’s a question: is the data logger using a UDP protocol, maybe (and if, so, why since there’s no no conceivable reason why you’d need that much speed to just send information about a heating system? I have yet to see that type of “interference” from TCP packets. Of, course, on that note and it is TCP then why, on earth, would any maker use anything other than plain text for the transmission data. It’s just sending sensor readings, right?

        • It is TCP and it does not need much speed and bandwidth as it is actually not intended to be used as a real-time logging protocol (in my opinon): It was designed as the protocol to be used on a PC running Windows and a software (provided for free by the vendor) that will fetch log files stored on the logger. You would fetch the log files once every few days. The software can also configure the logger and tell it to keep or delete the logged data – so the application protocol is more than just reading data. It is rather sort of a file transfer protocol, so a binary transmission of the file contents makes sense to me. The successor of this logger by the same vendor uses HTTP to fetch the log files.
          The open source logging solution (in place in this case) uses the device more like a real-time logger, by using the same protocol but reading off data (fetching mini-logfiles) more often – so that you don’t have to rely on the limited storage space of the data logger device but but log to your own database in real-time instead.

    • At least many protocol converters / gateways and the llike will be required in case on user does not buy anything from one vendor and/or has it all installed at the same time by a single contractor.

Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s