Does Azure IoT Edge frequently reset container networking?

I have a Module deployed to a Raspberry Pi that’s running Azure IoT Edge. The Module is a Node-RED app which is wanting to interact with gpiod. The Module is (of course) a containerized app, and gpiod is running on the host.

Everything is running as “defaults”, so the Module is running as --network="bridge", so to find out what IP I should be using to get from the Module (container) to the host, I did:

sudo docker exec hub-nodered route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         UG    0      0        0 eth0      *          U     0      0        0 eth0

And using, everything works!

Except, about 35 seconds after I’ve sent a 1 or 0 to a GPIO pin, I appear to lose access to the host network, and Node-RED reports ETIMEDOUT

I’ve no idea where is coming from other than it’s within the docker0 subnet:

$ sudo ip addr show docker0
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:94:f2:b2:ca brd ff:ff:ff:ff:ff:ff
    inet brd scope global docker0
       valid_lft forever preferred_lft forever
    inet brd scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::3bea:3383:36b7:fbd7/64 scope link 
       valid_lft forever preferred_lft forever

If I change nothing and go ahead and send another 1 or 0 to, it still works! But a little while later I will again appear to lose access to again and see the ETIMEDOUT error.

Using docker0‘s does exactly the same thing.

host.docker.internal does not yet work on Linux.

Is Azure IoT Edge periodically resetting the networking of the system so that I’m briefly losing access to the host IP?

Is there some other way I should be getting out from my module down to the host?

Source: StackOverflow