On Tuesday, Google released an iOS update for it’s Authenticator app, which adds support for the iPhone 5′s screen-resolution, an iOS 7-like user interface… and wipes all of your existing tokens.
After a colleague with a PhD in Networking and myself spent the best part of a day trying to NAT UDP syslog packets without success (the Destination-NAT half is fine, but Source-NAT eludes: the external system still sees the internal IP), I decided to change tack and solve the problem by handling packets in user-space.
I today received an email from Dyn (previously DynDNS), stating:
Starting now, if you would like to maintain your free Dyn account, you must log into your account once a month. Failure to do so will result in expiration and loss of your hostname. Note that using an update client will no longer suffice for this monthly login.
Now, if this were a service which requires interaction then this would be an unfriendly but potentially fair way to weed-out inactive accounts. This isn’t one of those cases, though – I can happily go for months or even years where my only interaction with Dyn(DNS) is via auto-update clients. And this is the heart of the problem – many routers and embedded devices have built-in DynDNS clients, frequently with no option to switch to an alternative service. Possibly this is worth $25/year, possibly it isn’t. Personally, I’m not paying a penny to a company trying to hold its users to ransom like this. For my usage, there are a handful for hostnames in a Dyn(DNS) domain – and therefore these cannot to transferred to a different provider. I keep them going purely so that historic links will still work.
For a long time, the only way to get the full functionality out of NICs which use the in-kernel ‘r8169′ driver was actually to eschew using the driver all together! Realtek offered their own driver, somewhat confusingly named ‘r8168′. This is available from their own highly unreliable FTP server, or from Google Code. This meant that whenever a new kernel was released you then had to await an update from Realtek before being able to upgrade.
However, the most recent r8168 release, version 8.0035.00, was released towards the end of December 2012 – and, whilst it builds against Linux kernels up to and including 3.7, it doesn’t work with kernel 3.8 or kernel 3.9.
… so I took a look at the r8169 source, and it looked suspiciously as if:
- It has been updated;
- It supports to specific Realtek device I’m using;
- It has full 9k Jumbo-frames support.
Finally, after several years, there’s no longer any need to use a proprietary driver in order to have full-sized frames!
It would, of course, have been nice if Realtek had posted a simple message saying that they were no longer updating their driver as the in-tree driver has now caught up in terms of functionality.
The interesting thing will be to see whether the occasional (every 3-6 months or so?) kernel panic within the networking subsystem will now also have gone away…
The stock Raspberry Pi kernel, as supplied with the default Raspbian distribution, is pretty good – albeit not always especially streamlined. However, building a custom kernel with different options can be an unexpected minefield: many seemingly innocuous changes can cause the Pi to fail to boot – often with the VideoCore system failing to initialise or with USB networking problems.
There follows a list of patches and observations which should hope to make this process less trial-and-error…
BT ships a variety of modems for its VDSL/Infinity product. There are ongoing discussions regarding the merits of each, but what all do have in common is that they are locked-down and inaccessible. The Huawei HG612 is theoretically the easiest to root, as described – but this does require loading a custom firmware. Additionally, mine re-locked itself and I’ve been unable to get into firmware-recovery mode since
The ECI B-FOCuS V-2FUb/I Rev. 1B can be unlocked via a serial connection without any need to replace the stock firmware – details here.
That is all.