Devices That Need Timestamping

Short version:

Wireless webcam feeding images to BSS sends them with wrong timestamp because device enables normal functioning before getting a reliable NNTP update.  If you’re using “smart” network-based devices, make sure that they’re capable of always providing data with reliable timestamps.


Long version (ranting included for no extra charge)

I’m doing a project that involves importing images from a motion-activated camera into the BSS (Blog Storage Service).  Because I had one lying around, I used a wireless, self-contained webcam.

Let me say, for the record, that this is a very poorly implemented camera, something that is not helped by Linksys’ refusal to provide timely firmware updates.  E.g.: If you use a dynamic DNS service like, presumably you’re doing so because you want to, y’know, actually use it, maybe?


Why how come?  Because Linksys knows more than you about…INTARWEBS! They have a MASTERS DEGREE, in teh INTARWEBS.  As such, they know that your preferences are merely the pathetic dribblings of a puny mind, and in order to make you life better, you will be using TZO.COM for your DNS redirection service.  “Who?” I hear you thinking.  “Who?” say lots of users on the LinkSys message boards.  Yeah, “who?” exactly.  Never mind that DynDNS (and others) are around, and that you might have existing accounts and reasons for using them.  No.  You will use the Precious, the shiny-shiny Precioussss…..yessss….

Sorry….just went to Middle Earth there, just for a second.  The point, and there is one, I assure you, is that this device, when the power is removed, forgets a critical bit of data: the time and date.  Yep.  $.25 for a battery was too much for the product design geniuses, apparently.

“Big deal,” you say.  Doesn’t the device access an NNTP service during boot, as all other devices in Known Space do?  You’d think that, wouldn’t you, with your pointy little brain, but guess what?  You’d be, that’s right,


There is a “Sync with PC” in the administrative interface, but no settings to allow you to specify a specific xNTP server/stratum/protocol.  And, since the device is never, at any time, connected to a PC, the actual functioning of this button, when it’s not mysteriously grayed out, is a Mystery of Science.  Presumably it’s actually using one, because at some point it seems to know the correct(ish) time, but you’d have to do protocol analysis to find out.  No settings for this, either.

All of this would simply be annoying, were it not for the piece de resistance: the device begins sending data BEFORE THE SYSTEM CLOCK HAS BEEN SET FROM A RELIABLE SOURCE.  “Ha-ha!” I hear you say.  Yup, pretty much.  In practice, this means that files uploaded by FTP (no, not SFTP, why would we want a secure connection?) have bad filenames, because the date+time is used for the filename.

“But Lynne, it’s just an inexpensive webcam, surely the designers…” NO! NO!  BE QUIET! BAD USER, NO PR0N FOR YOU!  I might be inclined to agree with you, except that I’ve used other networked webcams, in the same price range ($75+), and they’re just not this bad.

In reality, the device is too complex for a complete novice to use, and they’re presumably the target, given the price.  They’re not sophisticated enough for a user with a modicum of expertise, because they remove certain important choices. You know, I think we’ve all learned an important lesson, except the Windows Mobile UI design team:

Either make a thing an appliance, with a volume knob, or expose every single solitary setting so that experienced users can make it work correctly in any environment.


This specific device is only suitable for casual research projects.  I wouldn’t even use it at home.  My choice for inexpensive network cameras would have to be a D-Link unit, which even 6 years ago worked better.  We used them in retail establishments and spent about $350 each.  I’d link to their site, but is borked ATM.

At the high end of the scale are units like the one, designed for deployment in public and industrial environments, including hostile ones.  They also document and expose an API  Expect to pay 5-10 times as much as the D-Link models with similar functionality.

Oh, and the BSS import is moving along.

If you’d like to see the live feed from this unit:

(we’ve discovered that a lot of places won’t let this through their proxy/firewall/gateway, but it’s known to work from SLO, at least)

I see your BSS and raise you my BSS


As of this morning, it looks as though the RESEARCH.BSS service holds about 105,000 files, of which approximately 95,000 are images from the Appleton office camera.  Very cool.  Now we just need to think of something to do with them.

I did create a massive (approaching gigabytes) animated GIF, but really need something to just assemble them all into an AVI or something similar.

BSS service details screen capture

Lessons from first pass at IPv6


The Short Version (recommendations and opinions)

There’s no marketing or technical need for IPv6 in the current product in the next 1-3 years.  There would be significant costs(1) associated with adding complex networking code at the lowest levels of a stable product.

Don’t do it.

So don’t do IPv6, then?

I didn’t say that.  I said, “don’t add it to the existing product.”  Given the known architectural and quantitative (data volume) limitations in the existing products, build a new version of CygNet (CygNext) that supports IPv6 (only(1)) and Unicode/DBCS.  This would allow us to enter all likely international markets (India & China) which not coincidentally are the customer bases driving the adoption of IPv6, primarily due to the impending exhaustion of IPv4 address.

CygNext would also be designed to allow several (TBD) orders of magnitude more data, more types of data (e.g.  video, audio, analog streams), integration with customer security infrastructure, SOA features, and a wider variety of UI/HMI development options.

For the moment we’re going to put this on a back burner and move on to some other projects.


(1) There is no way to add v6 code without updating/changing existing v4 code and incurring non-trivial testing costs.  Forking the codebase to support separate v4 and v6 versions would consume amounts of extremely scarce developer (familiar with network code) time.

(2) – Based on the assumption that greenfield SCADA operations in developing markets will be using new, IPv6-capable sensor/net technologies.  We would probably need to build an IPv4-IPv6 gateway service (at additional cost) to support customers who have older devices.


The Longer Version

The story to date

I’ve spent the past months working on understanding how we use IPv4, how IPv6 works,  how one deals with IPv6 infrastructure, and what it would take to add IPv6 to the existing IPv4 CygNet in such a way as to keep a single code-base and allow the operation of CygNet in either v4 or v6 mode (but not both).

This involved a lot of reading.  A lot.  More than that.  Srsly.  My brain hurts, and one reason is due to the immaturity of the IPv6 marketplace. 

After that, lots of coding.  And recoding.

In the end, I did not have a running version of the ARS or the networking library that could use IPv6, but we learned a lot.

Coding, coding, coding

Nothing like being dumped in the base of the Sears Tower with faded, 20-year old blueprints and told to fix the building so aquatic mammals can live there.  As much as anything I’ve ever done, this was incredibly interesting.  The code in the base of CygNet is only C++ in name.  It’s really C and it’s really tight, nicely written.  But…it’s old and hairy, and I am young and innocent in the ways of networking.  Oh…wait, no I’m not. 🙂

The most important thing* to know about the guts of our networking is a class called CAddressBytes.  It’s a vector (aka array), because there no reason not to treat a v4 address as a series of 4 characters (e.g.  In fact it’s 16-bytes long because that’s the size of the standard data structure used to keep track of v4 hosts.

The minimum size data structure for IPv6 is 28 bytes.  For the non-programmers and non-accountants I’ll point out that 16 is not equal to 28, not even for Extremely Large Values of 16.  This is a Big Problem because we have to store information about hosts, and everything, everything, *everything* is built around the not-so-secret knowledge that an address is 16-bytes long.

Jeff pointed out some places where we had “extra” space in the networking structs left over from the days of Banyan Networking, but by and large it was a bit of a maze.  For the limited purposes of experimentation, this would probably be adequate.  For complete implementation, though, it looks as though there’s no way to get around needing to extend the size of various structures in ways that would make it difficult to retain compatibility with a pure (current) v4 implementation.

I believe, too, that a case could be made for converting the CAddressByte class from a vector to something more like an actual IP address object, especially since the future of networking will almost certainly involve networks wherein hosts/hostnames and IP addresses have a Many-To-Many relationship, something that we categorically cannot deal with in the current code.  Clusters, clouds, and other forms of distributed computing represent a next-gen level of architectural complexity that cannot be adequately dealt with using a simple, small vector.

We tried both ways, that is, extending the size of the vector and actually switching the base type to SOCKADDR_STORAGE, and each approach had problems I’ve detailed in past posts.

*of the many Most Important Things, that is

It’s a Special Feeling

Try to buy IPv6 from your ISP.  Go ahead.  I’ll just have a cup of coffee while you try it. 

All done?  Yeah, that’s what I thought.  You can’t buy it.  I can’t.  Almost no one can.  On the rare occasions you can get someone at a major ISP (e.g. Time Warner Business Cable) who even knows what it is, they tend to say something like, “No one’s asking for it.”

“I’m asking for it,” you say.

“Well, you don’t count, and besides, since no one else offers it, we’re going to wait until they do.”

Catch-22, Turing flavoured.  Oh, and that “special feeling” I mentioned?  It’s anger.  And rage.  And frustration.

I was eventually able to route v6 packets by signing up with a tunneling host provider, meaning that my packets went from my network to someplace in Chicago, where a miracle occurred and they then showed up in Los Angeles, to be carried the rest of the way to the research server’s external (public) IP address.

My current opinion

It’s an informed opinion, but still an opinion.  I can think of no likely technical justification for adding IPv6 to the existing version of CygNet.

It will require updating existing code, and adding new code.  This increase the likelihood of problems with IPv4 networking, while adding the certainty of running into problems with IPv6 networking, and since v6 is effectively a new standard, there are going to be problems, no question about it.

Existing customers are unlikely to switch out IPv4 for IPv6 on their SCADA networks for several reasons (most of which boil down to cost):

  • Existing legacy technologies that cannot be upgraded.  20-year old devices are apparently not uncommon in our existing customer installations.  In 1990, we were still debating whether TCP/IP was going to be the “winner” in the protocol wars.
  • The use of NATted IPv4 infrastructure eliminates the need for IPv6’s increased address space.  Since neither we nor they have applications in place or in planning that need v6-specific n-cast or routing features, there’s no compelling technical need.
  • IPv4 can be carried over IPv6, and will have to be in order to deal with legacy devices.