On Mon, 20.04.15 14:15, Spencer Baugh ([email protected]) wrote: > Lennart Poettering <[email protected]> writes: > > On Mon, 20.04.15 13:01, Spencer Baugh ([email protected]) wrote: > >> Lennart Poettering <[email protected]> writes: > >> > Hmm, so you say the initial connection does not work but triggers the > >> > container, but the subsequent one will? > >> > >> Not quite; the initial connection seems to actually make it to sshd, as > >> sshd has logs of getting it, but the connection is interrupted at some > >> point by some thing before anything useful can be done. > >> Subsequent connections indeed work fine. > > > > Interrupted? What precisely does sshd in the container log about the > > connection? > > I've just noticed that there are in fact two cases: The case where I > first ssh from the host to the container, and the case where I first ssh > from another unrelated machine with IPv6 connectivity to the > container. Neither works, but they do appear to have different > behavior. In both cases, all subsequent ssh connections work fine no > matter where they originate from. Here are logs for both cases, both ssh > and sshd side.
My guess is that this is actually quite simple: when the first connection is set up the first packets arrive on the host, and are thus processed by the host, and processed by the the first TCP socket. Howeverm when the network interface is moved into the container, then all subsequent packets of that connection are instead routed to the container's IP namespace, which cannot make any sense of the packets, and drop them/disconnect the client... The connection from the host hence will not receive any packets anymore... I figure the take-away here is that as of now private networking and socket activated containers don't mix well (And I don't even have an idea how to make them work better)... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
