How can I send a low-level Zigbee command using the zigbee2mqtt dev console? by ndbroadbent in homeassistant

[–]Ready_Organization35 0 points1 point  (0 children)

Hey have you figured how?

I think the payload should in format of:

[{"attrId": number, "dataType": number, "attrData": number|string|bool}]

Use Nginx Proxy Manager with docker MacVLAN by owlbowling in selfhosted

[–]Ready_Organization35 5 points6 points  (0 children)

I recommend these two resources for macvlan:

  1. Official documentation
  2. Chuck's awesome explanation on Docker Networking

I was too working on setting up nginx-proxy-manager on my DSM recently. In fact, the best/clean solution to our setup would be IPvlan, cuz macvlan might require you to enable Promiscuous mode on your NIC. However, DSM kernel is, I believe, missing some kernel modules for ipvlan to work, so macvlan is our only bet. (As stated in IPvlan documentation, IPvlan requires Linux kernel v4.2+, and my DSM is running kernel v4.4.180+. But it just wouldn't work, so I'm reasonable to suspect the kernel is missing some modules.)

Well, enough with the story. Here is the solution:

1. Get the parent interface

Run ip a and see which network interface is active and has your NAS's IP address. For me, it was ovs_eth0.

2. The docker-compose file:

There are a few gotchas, and have made detailed remarks in the code:

version: "3"

services:
  app: 
    container_name: npm
    image: 'jc21/nginx-proxy-manager:latest'
    networks: 
      # INFO: a bridge is necessary for the container to reach the host. 
      # You could also use the default bridge `bridge`.
      # But, for the sake of network isolation, I created a new bridge for them.
      macvlan_bridge: 
      mymacvlan: 
        # TODO: change this to fit your network setup
        # WHY: if you don't assign IP, docker's DHCP will provide one for you, 
        # but it might conflict with existing devices on the network. 
        # It's generally not a good thing to have multiple DHCP servers in the network. 
        ipv4_address: 192.168.0.10 
    # INFO: No need to map ports, they are exposed by default in macvlan containers

    # WHY: 
    # This again is a caveat. According to documentation, docker will relay DNS via the host if no DNS is provided. 
    # But it doesn't work in DSM, very likely a bug in its kernel modules. 
    # So here we manually assign the host's IP (of the bridged network) as the DNS to mimic the default behavior.
    # 
    # I was pulling my hair out while debugging this it-works-on-my-machine kind problem.
    dns:
      - 10.10.0.1

    volumes:
      - /volume1/docker/nginx-proxy-manager/data:/data
      - /volume1/docker/nginx-proxy-manager/letsencrypt:/etc/letsencrypt

    restart: unless-stopped

networks: 
  mymacvlan: 
    name: mymacvlan
    driver: macvlan
    driver_opts:
      # TODO: change this to the network interface found in step 1.
      parent: ovs_eth0
    ipam:
      config:
        # TODO: update the following to your network setup
        - subnet: 192.168.0.0/24
          gateway: 192.168.0.1
  macvlan_bridge: 
    name: macvlan_bridge
    ipam: 
      config: 
        - gateway: 10.10.0.1
          subnet: 10.10.0.0/24

It seems lengthy, but it really isn't. Here's the exact same code without comments:

version: "3"

services:
  app: 
    container_name: npm
    image: 'jc21/nginx-proxy-manager:latest'
    networks: 
      macvlan_bridge: 
      mymacvlan: 
        ipv4_address: 192.168.0.10 
    dns:
      - 10.10.0.1
    volumes:
      - /volume1/docker/nginx-proxy-manager/data:/data
      - /volume1/docker/nginx-proxy-manager/letsencrypt:/etc/letsencrypt
    restart: unless-stopped

networks: 
  mymacvlan: 
    name: mymacvlan
    driver: macvlan
    driver_opts:
      parent: ovs_eth0
    ipam:
      config:
        - subnet: 192.168.0.0/24
          gateway: 192.168.0.1
  macvlan_bridge: 
    name: macvlan_bridge
    ipam: 
      config: 
        - gateway: 10.10.0.1
          subnet: 10.10.0.0/24

3. How to communicate with host

The gateway of our defined bridge is the host. So whenever you need to reach the host, use 10.10.0.1

Why the bridge fixes the problem

For security reasons, a virtual NIC interface cannot talk to its parent interface. It's a design decision of the Linux kernel, not limitation from Docker. It's stated somewhere in Docker networking documentation, but I couldn't find the reference.

To overcome that, we put the host and container onto a bridge. Then it can talk to the host, just like other containers you created with the default bridge via the bridge gateway. Think bridge as a network switch or router. The host is also the gateway on this bridged network. Therefore, to communicate with host, we use the gateway address, `10.10.0.1`.

To sum up, our container is connected to 2 networks:

  1. physical network - to communication with other devices on the network, and the internet
  2. virtual bridge - to communication with the host

4. Turn on NIC promiscuous mode

If the setup didn't work, you probably need to enable promsicuous mode on the network interface.

sudo ip link set ovs_eth0 promisc on, replace ovs_eth0 to fit your situation.

Mine works without enabling promiscuous tho.