Link-local multicasting

Question

I'm trying to do multicast imaging in an environment without practical access to a DHCP server.
I have a 48-port switch which I'm assured is configured as a "flat" switch.
If I connect two or more computers to this switch (without connecting the switch to an uplink), boot them to the ZENworks Imaging Preboot Environment, and run 'dhcpcd -d -t 1 eth0' to get them link-local IP addresses, they can ping one another without issues.
After having confirmed that the pings succeed, if I attempt to initiate a multicast via 'img s flat m' on one computer and 'img s flat cl' on the others, img exits almost instantly with a "network is unreachable" / "could not contact the server" message and an elapsed-time report of 00:00. This happens as soon as the command is issued, not when the clients connect or when the "start multicast" button is pressed.
If I instead attempt to initiate the multicast via the menus of the curses interface to the 'img' program, as soon as I hit Next after selecting the "master" role, img segfaults. (I haven't yet tested selecting the 'client' role, but I expect it would be much the same.) I got a similar segfault on master machine for the first try with the command-line variant, but haven't been able to reproduce it since.
This is with ZENworks 11.2.2, and a preboot environment manually updated to use a more recent version of the Linux kernel (3.8 or later, I think - I haven't checked lately), which is needed for driver support.
Is multicast imaging across a "flat" switch using link-local IP addresses expected to work?
If it is, any idea what may be going wrong (or how to figure out the same), and/or how to get this working?
If it is not, is there any means of multicast imaging without an available DHCP server which *is* expected to work?

Answer 1

This turns out to be another manifestation of the problem described in TID 7011873.
The workaround described in that TID appears to assume that there is an available DHCP server, and that it just isn't handing out a default-gateway address when it hands out IP addresses to its clients.
In our scenario, there is no DHCP server at all, and no gateway as far as I'm aware; this is an entirely isolated network. It might be possible to get things working by specifying a default-gateway address anyway, but I have no idea what address to specify, since in that situation there is no machine with any special role (except for the multicast master itself, which is special for a different reason); I tried specifying 0.0.0.0, as a known-unused address, and the route command quite reasonably rejected it. There might be an IP address for the "flat" switch itself, but if so I don't know what it is and don't have any apparent way of finding out.
I managed to get this working anyway, at least to the point of the clients getting multicast-session numbers. To do that, I booted the SLAMPP live-CD server environment on a spare machine connected to the "flat" switch (from a USB drive), brought up the installed DHCP server in that live-CD environment, and specified the IP address of the live-CD machine (192.168.0.1) as the default gateway on the clients using the command described in that TID.
(The SLAMPP DHCP server does not appear to have any option to specify a default gateway address, so it still has to be specified manually as far as I've been able to tell.)
This approach means we have to have two machines connected to the switch in addition to the ones actually being imaged (the DHCP-server machine and the multicast master), but at least it should mean we can get imaging done outside of the realm of our normal network.
That TID is a year and a half old, and is still listed as "Reported to Engineering". Is there any indication of possible progress towards a fix?
At the least, I'd like to see some acknowledgement of the fact that this also applies to environments with no DHCP server, rather than just to ones where the DHCP server doesn't behave as the imaging client expects.