OPenWRT mesh and mDNS/broadcast traffic

I have just spend a frustrating three hours trying to figure out a problem on my home network. I am working on a project with an ESP8266 and mqtt. I am also using a Raspberry Pi which runs the mosquitto MQTT broker and Node-Red. This evening I suddenly found that the ESP could not communicate with the broker and that the Arduino IDE could n longer 'see' the mDNS advertised network port for the ESP.

Just to explain my setup, I have a Vigor router connected to the Internet. This connects to a Zyxel WSM20 router running OpenWRT that provides WiFi. Upstairs I have a second identical Zyxel router that is meshed with downstairs and broadcasts the same WiFI SSID. I turn it on when I watch streamed programmes and it helps significantly almost entirely eliminating buffering.

After going through a process of elimination it turns out that the problem occurred precisely because I had turned on the upstairs OpeWrt router. This caused wifi clients in the immediate vicinity, including the ESP and the Pi running the MQTT broker to connect to the upstairs router. While they had a good strong signal, it seems that the mesh does not pass the mDNS and other broadcast traffic which was causing the problems.

The problems were a bit weird because my laptop could ping the streaming box, the Pi and the ESP. The Pi could ping my P but not the ESP. The ESP could not connect to the Pi to subscribe to MQTT topics. I had observed on the upstairs router that wifi clients were taking a very long time to register their IP address or not at all. Once eventually the IP address came up in the list it was possible to ping stuff, but not always. When I turned off the upstairs router, everything started working normally again.

I am not sure whether the problem is just with broadcast traffic, because mqtt operates over TCP. However, if arp requests were not being passed this might also explain why the ESP could not connect with the Pi and why the Pi could not ping the ESP. It doesn't however explain why my PC was able to ping both unless, as it had not been rebooted, was able to obtain get the required information in its arp cache....

So the question is, what is actually going om here? Do I need to turn something on or off to pass broadcasts, mDNS and arp? I had understood that the mesh was essentially a WiFi LAN extender operating as if one had plugged in a long Ethernet cable into the router, except that it operates over WiFi. Whether this analogy is correct I am not sure, but perhaps the reality is rather more complex... The mesh does seem to operate as one subnet with DHCP requests being served across the entire WiFi network. Internet browsing and streaming also seems to be work perfectly fine.

Any insights would be appreciated.

Please show the output of mesh11sd status on the downstairs Zyxtel when the problem is occurring, it should give some insight into the issue.

I have not yet been able to replicate the problem tonight, but below is the current output. The first two mac addresses in the active stations list are the pi and the ESP. I will have to wait until it happens again and then post another update for comparison.

root@OpenWrt:~# mesh11sd status
{
  "setup":{
    "version":"2.0.0",
    "enabled":"1",
    "procd_status":"running",
    "portal_detect":"1",
    "mesh_basename":"m-11s-",
    "checkinterval":"10",
    "interface_timeout":"10",
    "debuglevel":"1"
  }
  "interfaces":{
    "m-11s-0":{
      "mesh_retry_timeout":"100",
      "mesh_confirm_timeout":"100",
      "mesh_holding_timeout":"100",
      "mesh_max_peer_links":"8",
      "mesh_max_retries":"3",
      "mesh_ttl":"31",
      "mesh_element_ttl":"31",
      "mesh_auto_open_plinks":"0",
      "mesh_hwmp_max_preq_retries":"4",
      "mesh_path_refresh_time":"1000",
      "mesh_min_discovery_timeout":"100",
      "mesh_hwmp_active_path_timeout":"5000",
      "mesh_hwmp_preq_min_interval":"10",
      "mesh_hwmp_net_diameter_traversal_time":"50",
      "mesh_hwmp_rootmode":"3",
      "mesh_hwmp_rann_interval":"5000",
      "mesh_gate_announcements":"1",
      "mesh_fwding":"1",
      "mesh_sync_offset_max_neighor":"50",
      "mesh_rssi_threshold":"-70",
      "mesh_hwmp_active_path_to_root_timeout":"6000",
      "mesh_hwmp_root_interval":"5000",
      "mesh_hwmp_confirmation_interval":"2000",
      "mesh_power_mode":"active",
      "mesh_awake_window":"10",
      "mesh_plink_timeout":"0",
      "mesh_connected_to_gate":"1",
      "mesh_nolearn":"0",
      "mesh_connected_to_as":"0",
      "mesh_id":"babbage20g1c",
      "device":"radio0",
      "channel":"1",
      "tx_packets":"139726725",
      "tx_bytes":"177724611447",
      "rx_packets":"62967602",
      "rx_bytes":"16542036095",
      "active_peers":"1",
      "peers":{
        "d6:1a:d1:14:7a:c5":{
          "next_hop":"d6:1a:d1:14:7a:c5"
        }
      }
      "active_stations":"7",
      "stations":{
        "b8:27:eb:e5:76:72":{
          "proxy_node":"d6:1a:d1:14:7a:c5"
        },
        "44:17:93:10:f8:91":{
          "proxy_node":"d6:1a:d1:14:7a:c5"
        },
        "42:6c:1c:09:34:77":{
          "proxy_node":"d6:1a:d1:14:7a:c5"
        },
        "78:3a:84:93:bc:b8":{
          "proxy_node":"d6:1a:d1:14:7a:c5"
        },
        "00:23:15:ec:b5:1c":{
          "proxy_node":"d6:1a:d1:14:7a:c5"
        },
        "10:ce:e9:3e:a1:44":{
          "proxy_node":"d6:1a:d1:14:7a:c5"
        },
        "d4:1a:d1:14:7a:c4":{
          "proxy_node":"d6:1a:d1:14:7a:c5"
        }
      }
    }
  }
}