Hi guys, I have partially good news about this.

We are not looking at a bug per se but more at limit with current implementation, and in general sub-optimal math skill of our engineering team =P

The problem arises in this method https://github.com/jboss-fuse/fabric8/blob/1.2.0.redhat-6-2-0-patch/fabric/fabric-utils/src/main/java/io/fabric8/utils/Ports.java#L119-L132

public static int mapPortToRange(int port, int minimumPort, int maximumPort) {
    if (maximumPort == 0) {
        maximumPort = MAX_PORT_NUMBER;
    }
    if (minimumPort >= maximumPort) {
        return port;
    } else if (minimumPort == 0 && port <= minimumPort) {
        return port;
    } else if (port >= minimumPort && port <= maximumPort) {
        return port;
    } else {
        return port % (maximumPort - minimumPort) + minimumPort;
    }
}

That implements our strategy to map a part to a specified number within a range [min.max]
As you can see the distribution is not really that smart.

And what is worse, is that we use a seed = 100 in the function that uses the above one:

https://github.com/jboss-fuse/fabric8/blob/1.2.0.redhat-6-2-0-patch/fabric/fabric-core/src/main/java/io/fabric8/service/child/ChildContainerProvider.java#L309-L311

int sshFrom = mapPortToRange(Ports.DEFAULT_KARAF_SSH_PORT, minimumPort, maximumPort);
int sshTo = mapPortToRange(Ports.DEFAULT_KARAF_SSH_PORT + 100, minimumPort, maximumPort);
int sshPort = portService.registerPort(child, "org.apache.karaf.shell", "sshPort", sshFrom, sshTo, usedPorts);

If you do the math, based on our implementation and the specified very narrow range in your Fabric configuration min = 5180, max = 5190 we have collisions.

If you just tweak those limits, you should be able to avoid them. I probably need an Excel paper to be able to produce useful values. In particular because using module operator sometimes we produce maximum range values that happens to be smaller than the minimum ones.