They broke multicast PING in El Capitan (well, kinda!)

I've written in the past about how much I rely on the multicast PING for getting the basic network settings out of a piece of equipment (that's has come back from a customer in some unknown state). Imagine my horror when I discovered they've broken it in OS-X v 10.11 El Capitan.

 So, here's the setup, piece of gear connected directly via an Ethernet interface to my laptop (with a hard-set IP address). Ordinarily using;

PING 224.0.0.1

would force the equipment to respond with it's IP address. Then it's easy to change your laptop's IP to be on the same subnet and you're in (like Flynn). No worries that the computer and equipment are on different subnets, multicast PING forces it to respond.

It appears I'm not the only one to notice this. See here on Apple's support site.

So here's the answer; you can see the effect "No route to host", then I attach to a pocket-router with only the Amulet box on it and by attaching to it over WiFi (it's a router, no need to worry about "wrong" IP subnets) I can PING and determine the Amulet is on 192.168.6.102

I can only assume that by now having an ARP table in the way (the pocket-router) we have a source of H/W address to IP conversion. When there was just a cable between the devices and hard-set IP addresses multicast relies on the second device to answer the broadcast PING with it's H/W address in the return packet. I can only assume that OS-X 10.11 ignores that and instead does an ARP equiry of the router to match the H/W and IP addresses?

It's not a big deal as I do carry one of those little pocket routers in my rucksack as they are supper useful for lots of things;

• Isolating yourself from an (untrusted) client's network
• Isolating an untrusted machine from your network whilst working on it
• Making wired-only demo equipment wireless to aid in customer demos
• A source of IP addresses when lashing up an ad-hoc network.

Managing multiple identical sound devices in OS-X

I use Skype (although I may be looking for alternatives due to Microsoft's proved snooping - see here) and I like to have two sound devices so that the radio can keep playing through my speakers without me having to reach for volume control when I take a call. Also, when podcasting, I use the same laptop to run the presentation, keep the Skype call going and make the recording (that chews up three sound devices!). So along with the laptop's internal sound chip I have two cheap external USB dongles. Since they are identical they show themselves with the same name is all apps and invariably (especially if I've been away from my desk for a day and re-booted the OS without any of the USB devices attached) Skype picks up the wrong sound devices as default. It's trivial to change back but I always get it wrong ("..is the headset the first or second one"?!)

In Utilities is the Audio MIDI setup application (which I've never used before) where you can set "aggregated sound devices" - presumably to allow the same audio to play through several outputs? But - it allows you to create a proxy for a device and give it a sensible name.

So, I made new devices for the two USB sound dongles and gave them sensible names.

This now means that when I look at available sound devices in other apps (particularly Skype) I see things I can distinguish!

Amulet's temporal dithering KEXT & fear of OS-X's console!

I've written previously about Amulet's fix for both nVidia and Radeon graphics cards doing temporal dithering under OS-X and how that spoils any KVM-over-IP system's ability to do compression. I had a good meeting with Amulet on Friday relating to a proposed customer's requirements but also got to chat to James Seward (@jamesoff on Twitter). He showed me a couple of interesting things:

• My assumption that the current version of his Kext wasn't working under Snow Leopard was actually due to the method he was using to signal the Kext had installed correctly - the error basically says that NScolor doesn't understand the call - never fear the Console! It showed that all was well;

• His worry that any other KVM-over-IP manufacturer could just take his Kext and use it to make OS-X displays work using their system has been circumvented by checking for the presence of Amulet hardware (that's an expensive dongle!);

Now the week after next is BVE, this time it's at the Excel Center in Docklands (goodbye Earl's Court!) and I'm doing some training tasters but all of the workstations on our stand will be extended over Amulet. I think this is one of the most significant technologies we've taken on in recent years and so come and grab me for a demo.