It is ironic that using the "simpler" switch actually complicated the configuration due to the lack of a DHCP server.
However, assuming these are Windows clients, it's well known Windows will self-assigned an APIPA address (from the 169.254.x.x block) when a DHCP server cannot be located (not sure if Linux works the same, probably does). In fact, it works by randomly generating an IP in that block and then tries to communicate w/ it. If it finds it in use, it randomly generates another IP and tries again, until eventually it has a unique IP address.http://www.conniq.com/Windows-networkin ... sta-04.htm
The idea being, that in the face of no DHCP server, the two PCs *should* be able to communicate without having to manually configure TCP/IP, it would just be two IP addresses randomly selected in the 169.254.x.x block.
So it raises the question, why didn't this work in the presence of only the switch?! Again, that’s the whole point of the APIPA protocols.
What I suspect is that it would have worked. Because the network was generated randomly, it’s “unidentified”. And since it has no default gateway, access is “limited”, but you still have local access. IOW, all the information reported by Windows is purely informational, and doesn’t necessarily reflect a problem. It’s only a problem in specific contexts, namely when you’re actually expecting a DHCP server to respond, which is not the case here.
In the absolute worst case, you might have to dig out what IP addresses where assigned and use them explicitly (Windows naming in the absence of a master browser is notoriously unreliable). But again, it *should* have worked. I suspect Windows naming was the issue, not TCP/IP.