VPN on a ship

There are many reasons for a VPN on a ship, and I was quite impressed that my other hack for UDP over fake TCP worked at all.

It did work, but was slightly strange. The experience was that normally VPN (via UDP or TCP) worked, but had 700ms latency round trip.

However, some of the time, the ship would have packet loss on the back haul, and then things changed. The UDP VPN would lose enough packets that normal TCP really struggled. Indeed, some times the VPN itself struggled to establish or stay up. It was actually for this reason that we even tried the TCP based solution.

However, in such cases, the TCP based VPN is special. It is very reliable, but has silly latency (up to many seconds).

The reason is what the satellite link it doing behind the scenes with TCP. It is doing an accelerator, which (I assume) is some level of local ACK combined with some internal re-transmission for dropped packets. But this means our VPN over TCP has the problems of doing TCP properly rather than faked, in that dropped packets result in high latency for every following packet.

Given the "cleverness" going on, it is amazing our faked TCP was good enough at all!

However, we like to have proper IP addresses here. There are a lot of reasons for that, but one of them is simple, it puts us, and our apple TV, geo-located at home. This was rather important for watching the episodes of Picard as they came out, even when in the middle of the Pacific.

So the challenge was proper UK IP addresses but still using the ship's TCP acceleration.

The solution was to de-NAT the traffic. The local brick here would NAT and send via ship's internet, which NATs again, but we change the destination IP to go to a brick in the UK. That then de-NATs, mapping back to original source and destination IP addresses and ports, or NAT the source. This works a treat, but you may have spotted the challenge here... How does the far end know where you wanted to send the packets in the first place?

The answer was to tack them on to the TCP SYN and look a them at the remote end!

My first thought was push them in to TCP options, but that is a challenge as there are only 40 bytes, and MSS takes 4 of those, leaving not enough bytes for two IPv6 addresses and ports. We could for IPv4, or we could just send target IP/port and NAT in UK. So we tried that.

The buggers NOP out any TCP option they do not understand, arrrg!

Alternative was put actual data in the initial SYN. To our surprise that worked, and as a SYN does not normally carry data, it works well (it is one of those theoretical TCP things I have never seen used). But it survives, and does not have the small size limit. We do have to move the SEQ back to allow for it, and strip out at the far end before sending on, but end result is public IPv4 and public IPv6 here, working. There is even space to add some authentication. (Note, this is not encrypted as assumes we will encrypt over it with TLS/https, ssh, etc).

Sadly sessions do not persist over glitches, and no incoming sessions, but I could watch Picard, so mission accomplished.

P.S. We have a choice of how to connect now, VPN over UDP, TCP (faked), relayed TCP, or just NAT on to ship's network raw (no good for Apple TV). Today we found UDP the best - the ship's TCP was unbearably slow (relaying, or not), but UDP was way better. To be honest this is much more what we are used to - everyone on the ship saying internet is crap and we're like "high latency, but not bad really" because the UDP based VPN works so well. The main thing is we can switch between different approaches as needed on a trip like this.

VPN over UDP over *fake* TCP

It has become a bit of a tradition for us now that, on a cruise with my mates, we spend maybe a day on some serious FireBrick development that is relevant to the cruise. In the past we have greatly improved the PPP stack. Last time we greatly improved the SIP handling of retries and duplicate packets and dropped packets (I had a working VoIP phone on my desk, and even got a junk call). Basically, the internet access on a cruise ship is, for want of a better word, "special". It can have horrid packet loss, and typically has 700ms latency but can be way more (as I type this I am seeing 2s). It creates problems for a variety of networking.

So this time, I have coded a special new feature on the FireBrick to make UDP in to fake TCP. The reason was that at one port (Guatemala) even UDP was being a problem.

Let's just be clear here first, this is not hacking in any computer misuse sense - we have paid for the most expensive internet. Not just the premium "unlimited", but the premium "unlimited" with steaming. That's right, "unlimited" somehow has a limitation of not allowing streaming! It specifically says it allows VPN but they are unable to say which VPN, and out-of-the-box IPsec on my phone or laptop simply does not work (even when it uses UDP). Oddly, unlike previous cruises, simple L2TP was blocked, meaning it had to be mapped to another random UDP port to work. But when even UDP struggled somehow, we considered TCP. Let's get that VPN, for which we have paid, working.

One idea was simply to open a TCP connection and push UDP packets through it. Not hard, but has issues. For a start, the entire latency / throughput has to be buffered on the firewall for that to work. But also, one dropped packets causes a backlog of all streams until received, as TCP is always in order. At 700ms+ that matters. So we wanted UDP behaviour but something that the ship would think is TCP.

Dumb idea (thanks Mike) was simply change protocol tag from UDP to TCP. After all the ports are in the same place at the start for both. Unfortunately even the dumbest NAT will look at the TCP flags for SYN, FIN and RST at the least.

So, less dumb, change to a TCP header with sensible flags (SYN on first, SYN+ACK on first reply, and ACK on the rest). But pack the otherwise lost 12 bytes (TCP uses 20, UDP 8), in to the SEQ, ACK, Window, and Urgent fields in TCP. That way, NAT can play with ports and look at the TCP flags but pass through the same data with no extra overhead. I am quite sure that would work on some NAT. I think FireBrick NAT would pass that with no problem.

However, we found that the ships system has a rather heavy handed NAT that not only changes ports but also sequence numbers (why?!). It also expects valid sequence numbers to be used in SEQ and in ACKs. Simply resending a SYN with a different SEQ or sending an ACK that is before the SEQ of the SYN caused a RST and dropped session. So we had to make the TCP look the part.

The answer was that the first packet was changed to just a SYN (and later updated to a SYN with window scale, just in case it cared). At the start we set a random sequence and store it, and for SYN send the SEQ to that minus 1. Only once we had a SYN+ACK did we consider the session properly started and we could send the UDP packets as TCP, moving on the stored SEQ for each to look like a legit TCP stream. On the other side, for a SYN, we generate a SYN+ACK response, and consider the session started. Any protocol over the top loses the first packet to the SYN, but as it is UDP it will resend, which is exactly what L2TP does. Obviously the MTU was dropped by 12, but we were working on 1280 to get through whatever shit the ship was using between us and dry land anyway. The ACK was then based on highest SEQ+length received regardless and so there is no buffering or resending - that is all handled by the VPN and ultimately individual TCP sessions over the VPN.

End result, after more hours than I would have hoped, it works. It is in FireBrick release1.53.025 Flint+ Alpha, as experimental. Part of firewalling rules allowing a protocol 6 to be set to 17, or 17 to be set to 6. Have fun. Likely to change some time, perhaps with option to try using the 12 bytes in TCP header to avoid extra overhead.

Far from #Brexit - some civilised drinks

It happens that, at the time, my friends and I were far from Brexit. Indeed, we were exactly 14.48054467N and 94.175880624W (or -449786.479813 -6160429.922092 1584520.022083 in ECEF) which is in the Pacific ocean.

However, as there were a few Brits on the ship, we got the concierge to invite some to our suite for a few drinks. We engineered nearly live BBC on the TV via a convoluted set of kit and VPN back to the UK, and we had my brexit clock.

It was remarkably civilised, with those for and against agreeing that whatever we do, we now have to find a way to live with this and make the best of any opportunities created.

It is the first time we have "hosted" a party from the suit, but butler managed it quite well and the ship even provided a couple of bottles of champagne for the party.

Amusingly at least one couple assumed it was a scummy NCL promotion to try and up-sell the suites, LOL.

Diabetes, and CGMs (Freestyle), non-diabetic using one!

I have been diabetic for a few years. My mum was too, since she had me, and we suspect this is what did my grandfather in (undiagnosed) to be honest. It is often hereditary.

I have often felt almost like some sort of fraud. I have insulin, as just taking tablets was not working, but the process is to review my HbA1c, maybe once a year, which is a test that sort of gives an average blood glucose over some months, which is not that good a "picture". But (having lost some weight) I am on a low daily dose of insulin now. That has advantages (one jab) and disadvantages (cannot adapt to changing circumstances easily). I have tablets too. It is "mild" compared to many people.

However, when I started losing weight, I also decided to buy, with my own money, at a cost of some £100+ a month, a continuous glucose monitor (CGM). It sticks on my arm and logs interstitial glucose levels and keeps a history. It has its quirks, like only 8 hours of data (and some times I try and sleep more than that!) so has to be scanned at least that often for a full picture. It is also maybe half an hour behind blood sugar levels, so I can feel hypo when it shows higher as it has not caught up.

However, I have found it hugely useful with managing my diabetes and diet. It is really good for making me aware of the wrong things to eat (basically sugar) and what I can eat in moderation and get away with in, and how much I can eat of something without getting away with it. This is mostly feedback of history rather than "am I really hypo now" which a blood test can do.

Sadly they are not cheap, but I feel they should be used more. They are normally only prescribed for people with severe diabetes, but I can see they should be really useful, even for people just trying to control it with diet. It is a shame they are not cheaper and prescribed more.

Recently I was able to see what a "normal person" is like on one of these. That said, it was rather odd. A friend of mine (who will, no doubt, read this blog) was diagnosed with gestational diabetes. So I gave her a CGM (and another as she knocked the first one off on a car door, FFS). She did not want to do the requested 8+ finger pricks a day, so my treat.

The thing is, having used the CGM, no way is she remotely diabetic. This is one day (with her permission)... Yes, charge that battery FFS!

Subsequent days I have seen are lower than that. She does not spike over 7 even when eating stuff she knows she should not.

For me this was really interesting as I did not know what a "normal", non-diabetic person looked like on a CGM, and now I do. It puts my graph to shame, and I am well controlled (apparently).

Like I say, I almost felt like a fraud, until I saw that, and I know I am nothing like that good. My diabetes is mild, under good control, but very real. I don't feel like a fraud any more, and even wonder if I need fast acting insulin doses when I eat as I can peak at 10 mmol/l, and occasionally more.

Interesting stuff.

P.S. As requested, here is one of mine, on a really good day... Most days I am peaking higher.

New printer (Canon PRO-1000)

I have had, and used, many printers over time (for paper, not 3D).

Just off the top of my head :-

• Simple line of pins impact dot matrix through ribbon - classic. I had a few of these.
• Single "pin" with rotating roller behind paper to do dot matrix through ribbon - slow - prints one dot at a time moving up through the character, then the blade shaped head moves right to do next pixel one dot at a time.
• Band printers - I did not own one, but used one - has all the letters on a band, and it is fascinating watching the line form as each letter is printed when it is over the right space, printing many in the line at a time, so the line of text sort of forms in seemingly random order in front of your eyes.
• Daisy wheel, impact print through ribbon, but fun doing some graphics with a lot of full stops.
• A spark based printer, single wire high drags at high speed across the paper for each row burning off a silvered surface of the paper, dot matrix - creates a black on silver text.
• A spark jet printer, with a carbon rod in a glass tube making a spark to the paper and carrying carbon deposited on the page. Single glass tube moves at high speed back and forth over the paper. Like printing with pencil. I did my degree dissertation on that.
• A variety of thermal printers on thermal paper - head the width of paper. Fades rather easily.
• A variety of thermal transfer printers, transfer from film to normal paper, head the width of paper.
• A variety of thermal transfer multi-colour ribbon printers for photo printing.
• The plastic card printer we use at work, thermal transfer. Ive used two kinds of such printers.
• Normal A4 laser printers, postscript
• A3 laser printer, colour
• Ink jet printer
• Bubble jet printer
• Oh, and pen plotters

Wow, I have had a lot of printers. I suspect I have missed some out even.

Actually, I left out that I have used manual, movable lead type printing machines and done typesetting using actual fonts of lead type characters. Genuine upper and lower "cases". That was a long time ago. I must be old.

The printer I have used for a long time is a wax based printer - originally Tektronix, but now bought by Xerox. I like them as they are not as messy as using toner and do solid colours really well. You just drop in these wax blocks to load the ink, neat and tidy. They are OK (ish) for photo print, but for colour letterheads (which is why we got them originally) they are really nice. I even print red wax seals to use with an embossing seal, and well, it was actually wax.

The office moved on to other laser printers some time ago, and my printer here finally started playing up (sheet feeder issues), so I have decided it is time for a new printer, and I thought it would be nice to get an ink jet type printer, but why not get one that can do photos...

What I eventually got was a Canon PRO-1000. It can have a stack of A4 plain paper for the normal use cases, but can also take a variety of sizes up to A2, and do impressive high resolution professional quality photo prints, edge to edge, on photo paper. It does pretty good photos even on plain paper.

So, yes, it will be used for simple A4 prints most of the time. These days I print quite low volumes, and can alway use printers at work for printing something with a lot of pages. It also has separately replaceable ink cartridges, which I prefer. However, there have been occasions where we do want to print bigger than A4, mainly for circuit drawings, etc.

But yes, I can print really nice photographs now. This is printing an A2 map on plain paper.

I did consider getting the wider models, they can do roll based prints up to A0, or even bigger. You can print proper posters for adverts and the like. But no way it would fit in the man-cave sensibly. I was also not sure if it would do the simple A4 plain paper as easily. The PRO-1000 seems a good compromise. The print quality really is rather impressive and having the option of large prints is nice.

EICAR test QR

It seems there is something of a standard test string for anti virus (wikipedia has more on this).

The idea is that systems that look for viruses will have this string loaded as a signature of a valid virus, and so react as such. This allows you to test virus checking systems without an actual virus being used. Obviously some systems may flag as "test virus" or some such, and some may not have this "standard" string.

The string is :-

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

So far, so good, but what people are doing (see tweet) is putting that in a QR code, e.g. this (feel free to copy this image).

[note the white space around the image is part of the QR code spec]

And then sticking it on a car, or a hoody, etc..

The result is that some systems that happen to log the content of QR codes they see, e.g. on CCTV and the like, promptly trip their virus detection systems. Ooops.

Of course this does raise questions of whether this could count as Computer Misuse, but then should such systems be reading QR codes off a hoody anyway?

P.S. My QR code generator is on GitHub if you want... It seems to be more efficient than most (though no advantage for this particular case), and has a lot of options (png, svg, text, binary, eps, ps, hex, data URL). Have fun.

0

It is funny how we like to see numbers clock over, whether a simple anniversary or birthday, or the odometer on a car, or even years.

Until the year 2000 I do not recall anyone having any issue with the common way decades were numbered. The '20s were 1920-1929 (inclusive), and so on. No issue, no doubt, no confusion. Sadly the year 2000, being a change of millennium, caused many to say "technically the new millennium does not start until 2001 as there was no year 0". This is one rare cases where I err aware from "technically correct" for a change, and even question if it is technically correct. The years are projected back from a more recently invented calendar and indeed go from 1BC to 1AD in one calendar. So on that basis, yes, a millennium starting at the start of 1AD means a new one in 2001. But why consider the start 1AD not 1BC? All evidence suggests that was not when Jesus was born, if he existed, so you should probably consider the third millennium starting maybe spring 2004 [citation needed]. You are picking an arbitrary start point - why?

However, it depends which calendar you pick obviously. We use the Gregorian calendar, but other calendars (e.g. astronomical) do have a year 0 and otherwise align with the Gregorian calendar (for current years). So one can be "technically correct" and still have a new millennium starting at the start of 2000 without any difficulty.

My point all along was that the only reason to consider the change of millennium as "special" in any way is the base 10 numbering that we use, and that a clocking round of 1000 years happens very rarely (oddly enough, every 1000 years), and so the only logical point to consider "special" is when the year number "clocks round" 1999 to 2000. If you are not doing it then, then why even consider 1000 special, why not consider multiples of 324.6 years as "special"?

I had thought this was all old news, but, to my surprise, I see people even now on social media saying the next decade does not start until 2021 as "there wasn't a year 0", continuing this nonsense. Sorry, but (Gregorian) decades only make sense as "special" if you consider them to be the years ending 0 to 9 (inclusive), end of story. So if anyone says otherwise just say you are using the astronomical calendar which does have a year 0, and see how they cope with that. Good luck.

But this may also help (thanks to xkcd)

P.S. this was raging on twitter later in the day on the 1st, and someone even posted that "At age 21 you start your third decade", LOL. No, 1st is 0-9, 2nd is 10-19, and 3rd is 20-29. Anyway, for those insisting "it" starts in 2021, point out that what "it" is, in that case, is "the 203rd decade of the Gregorian calendar" and not "the '20s". The '20s start in 2020, end of story.

P.P.S. a reminder that it is '20s, and not 20's, unless you are using a possessive, like "The '20's greatest hits".

---

Anyway, on a more amusing note, it seems Bulb may have finally fixed my account so I can submit a meter reading (they have been messed up since I signed up for no apparent reason, and just emailed me to say fixed). Yay, so a meter reading is needed.

I was about to submit one, on 31st Dec, and noticed it was close... very close...

This has resulted in my spending many hours on the 31st Dec, turning on extra high power kit in the house for a while, and even running the tumble drier, wasting many pence worth of electricity in order to get this picture (well, maybe not wasting as it means gas heating needs less power as house is warmer)...

It is a thing of beauty, is it not?

To my surprise Bulb had no problem with my submitting the meter reading of 00000.

All the "there was not a year 0" people would say I should not consider my meter to have rolled over until 00003 (or whatever it was when first installed).

---

There is one clock I'd rather not reach 0 though :-