mptcp inside lxc container can't access /proc/sys/net/mptcp_enabled

[VenkateswaranJ]

Hi,

I have created an lxc container (ubuntu 20.04) with privileged mode and my host machine has mptcp kernel installed ubuntu 20.04. For some reason, I don't see the file /proc/sys/net/mptcp_enabled inside the container. I can access the file on my host machine without issue.

Please take a look at my container config

probe2@probe2:~/Documents$ lxc config show panel1
architecture: x86_64
config:
  image.architecture: amd64
  image.description: ubuntu 20.04 LTS amd64 (release) (20220308)
  image.label: release
  image.os: ubuntu
  image.release: focal
  image.serial: "20220308"
  image.type: squashfs
  image.version: "20.04"
  raw.lxc: lxc.mount.auto=proc:rw sys:rw
  security.privileged: "true"
  volatile.base_image: 06460ff79260729ba686608f11eb3d6eff26a72449dfd71e9d22a42f0038b897
  volatile.eth0.host_name: vethf910dc17
  volatile.eth0.hwaddr: 00:16:3e:a4:f0:d1
  volatile.eth1.host_name: veth9bdc9b62
  volatile.eth1.hwaddr: 00:16:3e:0c:23:43
  volatile.idmap.base: "0"
  volatile.idmap.current: '[]'
  volatile.idmap.next: '[]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
  volatile.uuid: ce94e0de-fd47-4187-9527-48d700ef3b07
devices: {}
ephemeral: false
profiles:
- panel-1
stateful: false
description: ""

You can see that I even mapped the sys and proc files in the config

raw.lxc: lxc.mount.auto=proc:rw sys:rw
security.privileged: "true"

I even tried with Docker but experienced the same problem.

docker run -d --sysctl net.mptcp.mptcp_enabled=1 --name=loki -p 3100:3100 grafana/loki

75dcbdc65a1539ce734a413cb6e23bf216aea76f6533c52280d3e866270424b9
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: write sysctl key net.mptcp.mptcp_enabled: open /proc/sys/net/mptcp/mptcp_enabled: no such file or directory: unknown.

[matttbe]

Hi,

mptcp_enabled (and most/all MPTCP sysctl) are global for all net namespaces. It means that you can only read and write values from the "main" net namespace and this will affect all netns.

I guess you can still mount /proc/sys/net/mptcp in a different directory in your container to be able to read/change values. (not sure it is recommended but well :) )

[vandit86]

mptcp_net-next (mptcpv1) allows per namespace configuration..

[VenkateswaranJ]

This might not be related to mptcp but I'm asking it here as you guys have expertise in the Linux net.

As you can see in the above image I have a Debian based docker container that is connected to two networks. So there are two bridges configured in my host and they get connected to the docker network namespace via veth links. I'm running a small program inside a docker container that detect IP change via rtnetlink.

So now my task is to consider the bridge like a virtual switch and if I bring down the bridge interface in my host machine I expect the veth link between my host and docker to go down and the program (rtnetlink) inside my docker container detects this link down event. But unfortunately, nothing happens, even the IP address of both bridge and docker interface not removed.

Maybe my understanding of veth links are wrong (I thought it react similarly to pulling out lan cable from the physical switch 😁 )

My end requirement is to connect more docker containers to these two bridges and try to shut down one bridge will remove one subflow of mptcp connection running in all the containers. But for that I need the netlink event when the bridge goes down.

Currently, I only get Netlink events on running ip addr del 192.168.10.2/24 eth0 inside docker container.

@matttbe is possible to achieve my above requirement in any other way ? (LXC or something else)

[matttbe]

It is strange but maybe normal for the veth to act like that, I cannot tell.

Did you run something like ip monitor in the docker to check if you don't get any other useful events?
Maybe you have to first delete the IPs from each container to make sure the proper signal are sent?