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.
Month: May 2013
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.
(emphasis theirs)
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…