DLNA, UPnP and multicast routing

I have a problem which is probably unusual in most home networks, which is that I have multiple subnets coming off one of my LAN interfaces on my router.  For most IP-routed things, this is obviously not a problem, but there is seemingly one exception to this rule, and that is multicast packets.

Multicast (which is a way of sending a packet once and many machines receiving the same packet simultaneously, so you don’t have to send the packets to every machine individually) isn’t very well understood by many people in the IPv4 world, because firstly it’s optional, and secondly hardly anyone seems to use  it.  In contrast, IPv6 effectively makes the use of multicast compulsory because it is used extensively by IPv6 itself, as well as protocols which run on top of it, even if only at the link-local level to other machines that can be reached without a router.

A few weeks ago, I decided to try and make my home router (which is built on Debian) into a multicast-capable router, both IPv4 and IPv6.  Not knowing an awful lot about this subject, other than it doesn’t “just work” despite the Linux kernel having multicast support built in, I started to Google.  It would appear that I need to run programs on top of the kernel that supports IGMP for IPv4, and MLD for IPv6, and both need to support PIM as well, which appears to be the multicast equivalent of things like OSPF and RIP, which do the dynamic routing.  (Although this seems bit like overkill since my LAN only has one router, but there you are.)

Debian doesn’t seem to have a lot of choice on which programs to use, but I narrowed it down to pimd (which works with IPv4 only) and mrd6 (which works with IPv6 only).  So far so good.  I configured the programs with a configuration that I thought worked, and started up the daemons, which appeared to work, and thought no more about it.

Until…

I wanted to play a few tracks from my DLNA server.  For those not familiar, DLNA (or UPnP AV Specification) servers use Universal Plug and Play to advertise themselves.  In IPv4, this is done by sending packets to the multicast address 239.255.255.250 and in IPv6 this is done by sending packets to ff0x::c (where x is the scope ID).  So, had my configuration of pimd actually worked (we’ll have to ignore mrd6 for the minute because my mediatomb DLNA server does not support IPv6, and I can’t find an open-source DLNA server that does yet) this should have “just worked”,  because the router would have routed the packets between the network my server was on, and the network my client was on.  But it wasn’t working.  But the $64 million question was why  on earth not?

The answer turned out to be a little obscure, but worth noting nonetheless (and almost certainly had the DLNA server and client been listening on IPv6 this would never have broken).  After doing a bit of investigating and searching the Web (and also trying and failing to get upnpproxy and igmpproxy to work), it would appear the problem was that my ‘servers’ network interface had not one subnet on it, but three subnets.  This appeared to confuse pimd into not knowing what to route where.

The solution was to tell pimd specifically which other subnets were on the same interface.  You can do this by specifiying the altnet keyword in the phyint interface definitions in the /etc/pimd.conf file, as in this example:

phyint eth0 enable altnet 10.10.10.0/24 altnet 10.11.12.0/24

To make this work, I had to put in an altnet parameter for every extra IPv4 address range I had on the same interface, otherwise nothing else will see it.  Normally, you wouldn’t need this parameter if you have exactly one IPv4 subnet parameter per interface, but it’s necessary if you have more than one so that pimd knows which subnets should be accepted from which interface.

Problem solved!

Well, nearly.  This works on most clients, but it would appear even Microsoft’s own UPnP AV/DLNA client in Windows Media Player doesn’t even bother to use multicast, and the UPnPlay app on Android 6.0.1 also does not work (although this may be because multicast sockets in Android are probably still broken, so this would affect all apps).  However, my Panasonic TV works fine with it, so does Kodi for Windows, so I’m happy enough for now.  I have my tunes back.

Non-domain MIT Kerberos logins on Windows 10

Note: The article here requires features that don’t appear to come with the Home edition of Windows 10, such as the Group Policy Editor.  These steps may well work on previous versions of Windows, but I haven’t tried it out on them.  This article assumes you’re familiar with setting up and administrating an MIT Kerberos KDC and password server.

Most people who have ever dealt with Windows domains will know that the Active Directory system uses Kerberos as its authentication mechanism, but did you know it was possible to configure a standalone Windows 10 to log on to an MIT Kerberos server running on (e.g.) Linux?

Although I knew of the ksetup.exe program that used to come with the Windows Resource Kit and latterly with Windows itself, I had never figured out how to use it.  However, whilst Googling for ksetup, I came across a few blog postings which showed me how to get this working.

In the following examples, I am going to be using a DNS domain name of example.com and a Kerberos realm name of EXAMPLE.COM (as is the convention, that you use capital letters).

There are a number of commands you need.  You need to run these as administrator.

ksetup /setrealm EXAMPLE.COM – sets the default Kerberos realm to EXAMPLE.COM

ksetup /addkdc EXAMPLE.COM kdc.example.com – sets the name of the Kerberos KDC server.  If you miss out the name of the server, it will try to find it using the special Kerberos SRV DNS records.  You can use this more than once to add multiple servers if you have them.
ksetup /addkpasswd EXAMPLE.COM kpasswd.example.com – sets the name of the Kerberos password server, which may or may not be the same machine as the KDC.

ksetup /setcomputerpassword <password> – this sets the password for the ‘machine account’ (in reality it’s (a) host/* principal(s) on the server).  The password you set here you will need to keep for later as you will need to set the same password on the host principals.  Make it secure!

ksetup /mapuser * * – this configures a 1:1 mapping of Kerberos user names to local accounts, so if you log in as jsmith@EXAMPLE.COM this would correspond to a local account of jsmith.  If you don’t want a 1:1 mapping, you can map specific principals (the first parameter) to specific user accounts (the second parameter) instead.

There are other options (do ksetup /? to list them all) but these are the base ones you’ll need.  Some of these require a reboot to make them take effect.

Once you have configured the Windows side of things, you’ll need to use kadmin on the MIT Kerberos server to create a couple of host principals per machine.  I found that you have to create one host principal for the FQDN of the machine, and another with just the host name, so in the example above you’d need to create

host/mywindowsbox.example.com@EXAMPLE.COM
host/mywindowsbox@EXAMPLE.COM

Both of these host principals must have the password set to the password you set in the ksetup /setcomputerpassword command, otherwise Windows will give you an error along the lines of there not being a computer account when you try to log on.

There are a few extra things you can do with the Group Policy Editor to make things a little easier here.  First of all, you can set the default logon domain name.  By default Windows appears to get this one wrong (for some reason it sets it to everything to the left of the first dot as far as I can tell, so you’d get EXAMPLE and not EXAMPLE.COM). Setting it directly in the Group Policy Editor fixes this problem.  The setting is at Local Computer Policy -> Administrative Templates -> System -> Logon -> Assign a default domain for logon.  Set this to Enabled and supply the name of your Kerberos realm (case-sensitive, so if your realm name is in capitals, so should this parameter)

One more thing that I set were the Do Not Display Last User Name setting to enabled, so that it always asks for a username at the logon box, otherwise it may auto-select the non-Kerberos account.

Once this is done, it’s still possible to log into your local account directly by prefixing your user name with the name of your machine, e.g. MYWINDOWSBOX\jsmith just as you would if you want to log into a local account whilst joined to a domain.

Once you’re logged in using your Kerberos credentials, you can use the klist utility at the command line to check you’ve been issued a ticket.  You can then use any applications supporting SSPI (e.g. Firefox, Thunderbird, PuTTY, etc.)  to use that ticket to log on to other services, just like you would in a normal AD domain.  In theory, it should be possible to use a cifs/ ticket to connect to Samba, but I haven’t made this work yet.

Should you wish to undo all this and return to normal, you can use the ksetup /removerealm EXAMPLE.COM command to remove the settings from the registry and go back to user accounts.

Update: If you want delegation to work (say, for example, if you want an automatically-issued ticket to appear in an SSH session you logged into via Kerberos), you also need to set the Delegate flag using the ksetup utility.  Just run something along the lines of ksetup /addrealmflags EXAMPLE.COM Delegate to enable this feature if you need it.

Blast from the Past: Usborne Computer Books from the 1980s

For those of you who grew up in the 1980s, you  might remember the series of titles published by Usborne Books about what would be considered quite esoteric subjects today, from how to program in BASIC on your favourite home computer, to writing adventure games, and even how to write Z80 and 6502 assembler (and yes, I had a copy of the last two books!)

As various parts of the computer press have stated this week, Usborne have made PDFs available of these books for free download, which you can find here.  There is also a blog posting on how the books came about here.  (Even now, I’m still amazed they even published the book on assembler programming back then!)

Perhaps one day I should port the adventure game that’s described in “Write your own Adventure Programs for your Microcomputer” to something like Inform…

DNSSEC zone re-sign today

I’ve signed or re-signed all my domains with new more secure RSA/SHA-256 keys today (and adding some domains that weren’t previously signed).  I’m going to leave my old signing keys in for a while so you shouldn’t notice the changeover, and remove them in a few days when the new DS and DNSKEY records have had a chance to propagate to the wider Internet.

(For those of you unfamiliar with the concept of DNSSEC, it is a way of using encryption to verify that DNS lookups on the Internet, which convert names such as www.garyhawkins.me.uk to IP addresses and vice-versa, are genuine and are not being spoofed from an unauthorised server.)

Update: Old keys now gone from the server.

Yet another certificate disaster

I was dismayed to read this article on The Register today which suggests that yet another large manufacturer has shipped a security nightmare with its laptops.  You’d have thought these people would have learned after the Lenovo “Superfish” debacle, but apparently not.

It would appear that Dell ships a self-signed root CA certificate by the name of “eDellRoot” which is automatically installed by Dell software into the Windows trusted root certificate store.  This would normally be not too much of a problem, but this time they’ve managed to install the private key as well, which means (assuming the private key is the same on every machine with this certificate on) that it’s trivially easy to take the private key, sign certificates with it and then any Dell machine will blindly accept this certificate which can be used for nefarious purposes such as impersonating web sites, man-in-the-middle attacks, malware, etc, etc, etc.

What on earth were Dell thinking?!

Review: Whole (“blue top”) milk

The other day, I went to the supermarket to do the weekly shop as usual, but they’d run out of semi-skimmed milk (“green top”) which is about 2% fat), so I had to buy whole milk (“blue top”) which is 3.5%-4% fat, and I hadn’t bought for ages.

And so, the following morning, I got up as usual, reached for a bowl and put a handful of corn flakes in it, poured some milk into the bowl and sprinkled a bit of sugar on them, and started to eat them.  I’d forgotten just how nice corn flakes tasted with “unskimmed” milk!  (OK, not quite as nice as when the milkman delivered the milk bottles and you got a bit of the “cream”  on the top, but still pretty nice. If you want that you can still buy 8% fat “gold top” milk still at the supermarket.)

So the question is … do I buy whole milk next week, or go back to the decidely-inferior-on-corn-flakes semi-skimmed?  Decisions, decisions…

Likes: Tastes great.  Also nice in coffee.
Dislikes: Makes you fat(ter)

Rating: 9 out of 10
(Corn flakes with “gold top” milk would be rated at least 11 out of 10, if I had any in the fridge)

Review: Snom D765 VoIP phone

So I thought it was time I replaced my existing Snom 370 telephones, after 7 years, with a new model.   After much waiting, eventually the phone I was after came on the market, and so I bought two of the Snom D765 phones.  The Snom D765 is an updated version of the Snom 760, with better hardware inside.  The new design is considerably different to the Snom 370, and looks a lot more modern.  The new phone is taller and not as wide.  It also has a colour screen, but you’d hardly notice because not much of the screen is in colour except for the green box to show the phone has been registered.  (I suspect the colour screen works a lot better when you start including photographs of your contacts)

The Web interface is largely similar to previous Snom models with a few extra features.  However, I think they’ve got some bugs to fix on the 8.7.5.28 firmware because pushing certain buttons on the Web UI causes the wrong thing to happen, especially when you push red crosses to delete lists of missed calls etc.  The really irritating thing is that the IPv6 support works, but I cannot understand for the life of me why on earth it will not resolve AAAA records.   The only way I can get it to work is to put IPv6 address literals in instead!  (And yes, I have reported the bug.)  Once I did that, it connected to my IPv6-capable FreeSWITCH installation perfectly.

What can I say about this phone?  Well, it’s a Snom.  If you’re used to previous versions of the Snoms it’s pretty much more of the same.  However, they’ve got some stupid bugs to fix in the firmware but otherwise the phone works fine.  Still no Opus support yet which is a shame.  Also new (relative to the 370s) are Bluetooth and USB sound card support so you can plug in a USB headset, and multicolour (red/green/yellow) LEDs, unlike the 370 which only had yellow.  Lots of possibilities with that, I’m sure once I’ve worked out how to control them.

Likes: New modern design, IPv6 support, USB headset support, colour screen
Dislikes: Firmware still full of stupid bugs, lack of Opus support, can’t resolve AAAA records.

Rating: 8 out of 10.  Nice phone, needs some work on the firmware

 

Just like a newspaper without any interesting news in it