System crashes when Docker bridge network is used

TorinCooperBennun

I'm using an OAK-4-PRO-W, batch 4525E1.

Some system info:

~ # uname -a
Linux kalama 5.15.144-android13-8-1.23.1-dirty #1 SMP PREEMPT Wed Jan 7 21:38:51 UTC 2026 aarch64 GNU/Linux

~ # cat /etc/os-release
ID=luxonisos-rvc4
NAME="Luxonis OS RVC4"
VERSION="1.23.1"
VERSION_ID=r851-1.23.1
PRETTY_NAME="Luxonis OS RVC4 1.23.1"
IMAGE_REV="112c73e63a9576c7023b6692e249359b1439ae32"
MANIFEST_REV_REV="8ad1fdc"
BUILD_ID="20260107220615"

~ # cat /etc/docker/daemon.json
{"data-root": "/data/docker"}

~ # docker version
Client:
 Version:           20.10.25-ce
 API version:       1.41
 Go version:        go1.17.13
 Git commit:        911449ca24
 Built:             Wed Jan  7 23:03:46 2026
 OS/Arch:           linux/arm64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.25-ce
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17.13
  Git commit:       791d8ab87747169b4cbfcdf2fd57c81952bae6d5
  Built:            Thu Nov 10 20:12:34 2022
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v1.6.19.m
  GitCommit:        1e1ea6e986c6c86565bc33d52e34b81b3e2bc71f.m
 runc:
  Version:          1.1.4+dev
  GitCommit:        v1.1.4-8-g974efd2df-dirty
 docker-init:
  Version:          0.19.0
  GitCommit:        b9f42a0-dirty

And here's how to crash it:

  # create bridge network - OK
  docker network create test_bridge

  # start container on bridge - OK
  docker run -d --name test_box --network test_bridge busybox sh -c "while true; do sleep 1; done"

  # make outbound traffic - CRASH
  docker exec test_box ping -c 1 8.8.8.8

And when I say "crash", I mean this:

TCP connections, including SSH, hang almost immediately (fraction of a second after execution)
Front LED goes from blue to off, approx 7 seconds after the command is executed
System is unrecoverable until physical power cycle

I've tried, to no avail, to get system logs from the crash. I started a program to log kernel messages to a file in /data but it cuts off before the crash occurs. There's nothing in /sys/fs/pstore.

I can obviously work around this, but it's a frustrating limitation! I have an existing software stack which utilises bridge networks, which I was hoping to run on the OAK-4 with minimal changes.

Edited to reflect OS update to 1.23.1, which had no effect.

TorinCooperBennun

I've done some digging. I'm able to reproduce the crash by messing with network interfaces alone (trying to replicate what Docker does when you create a bridge network and attach a container to it):

# create veth pair - OK
ip link add name veth_host type veth peer name veth_ns

# create bridge, connect veth_host to it - OK
brctl addbr testbr0
ip link set testbr0 up
brctl addif testbr0 veth_host

# create namespace, add veth_ns to it - OK
ip netns add testns
ip link set veth_ns netns testns

# bring veth pair up - CRASH!
# (these two lines in *any order* cause the crash after the second one is executed)
ip link set veth_host up
ip netns exec testns ip link set veth_ns up

Hope that helps. 🙂

jakaskerl

Hi TorinCooperBennun
This is a known issue and is not on the roadmap for a fix. That's why we recommend you use oakapps.

Thanks,
Jaka

TorinCooperBennun

jakaskerl

Thanks for replying so quickly.

To be honest, I'm a little disappointed to hear that. Am I right that this is a kernel module bug? If so it is likely fixed upstream. Are there no kernel updates on the roadmap?

In any case… could you please confirm whether it's possible to achieve container network isolation (via bridge interfaces or otherwise) when configuring OAK apps? I haven't spotted anything in the documentation yet!

Thank you!

jakaskerl

Hi TorinCooperBennun
I think it's a kernel limitation.

TorinCooperBennun In any case… could you please confirm whether it's possible to achieve container network isolation (via bridge interfaces or otherwise) when configuring OAK apps?

Similar issue upon trying it I'm afraid. Can you describe your use-case (the need for network isolation, etc)?
We should be able to find a solution, but would need more info on what's actually important to you.

Thanks
Jaka

Ales

I’d like to add some context to Jaka’s first suggestion about using oak-apps.

On each OAK4 device, we run our own oak-agent service, which provides a runtime for applications and can be managed via oakctl. We do not use Docker (or Podman) under the hood, and in most cases we do not recommend Docker as the default option for several reasons:

We want more direct control over the application lifecycle, which is particularly important for handling scenarios like power outages or unexpected restarts.
Instead of thinking in terms of “containers,” we think in terms of applications that run continuously on the device (*.oakapp files). These applications can be installed on other OAK4 devices and updated with minimal downtime.
We provide ready-to-use oak-examples, which makes prototyping extremely fast and lowers the barrier to getting something running on the device.
This approach enables fleet-level management through Luxonis Hub, where you can control devices, monitor applications, access a terminal over WebRTC, update Luxonis OS, and deploy application and AI model updates fleet-wide through a UI.

That said, there are cases where Docker is the better choice. These typically include situations where:

You already have your own or a custom deployment process.
You’re porting an existing Docker-based solution to OAK4.
You require more advanced container features.
You don’t plan to use Luxonis Hub.

There is also a compromise approach: creating your own base image and running it via oak-agent. However, this option is not suitable for this use case, as oak-agent does not provide network isolation. So at this point, I'd recommend sticking with running containers in a host mode.

We release OS updates every few weeks, so improvements may arrive soon (see the Luxonis OS changelog for details).

Joe-Davidson

One of our development engineers dug into this a little more. Here is a fix that should work for you:
Disabling some netfilter functionalities "fixes" the issue:

# disable netfilter on bridge traffic
sysctl -w net.bridge.bridge-nf-call-iptables=0
sysctl -w net.bridge.bridge-nf-call-ip6tables=0
sysctl -w net.bridge.bridge-nf-call-arptables=0

There are two things that aren't supported with the above configuration (details here), but should be good enough to run your existing software stack.

The developer verified that basic functionality:

port forwarding from container to host using -p
container1 -> container2 communication works, if they use the same bridge network (wget http://container1:8000 from container2 was tested).
container1-> container3 communication doesn't work, if they use different bridge networks (this is one of the 2 items the fix does not support)