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.
