Open jpatriarca opened 2 years ago
probot-esphome[bot]
commented
2 years ago Hey there @esphome/core, mind taking a look at this issue as it has been labeled with an integration (mdns) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
OttoWinter
commented
2 years ago Probably related to https://github.com/espressif/arduino-esp32/issues/4406 and https://github.com/espressif/esp-idf/issues/7453
So probably would be fixed by an updated arduino framework, but we're still waiting for a new release to be pushed to pio (https://github.com/platformio/platform-espressif32/issues/619)
OttoWinter
commented
2 years ago Checking multicast-relay logs on the specific docker image, I can see that when the devices boot, they send multicast request to all VLAN configured during the first 5 seconds the device are online, but then stops.
Correct me if I'm wrong, but this sounds like the correct behavior. The mDNS RFC only requires devices to respond to queries and broadcast when initially connecting, but periodic broadcasts are not required. Edit: https://datatracker.ietf.org/doc/html/rfc6762#section-10.2
jpatriarca
commented
2 years ago Checking multicast-relay logs on the specific docker image, I can see that when the devices boot, they send multicast request to all VLAN configured during the first 5 seconds the device are online, but then stops.
Correct me if I'm wrong, but this sounds like the correct behavior. The mDNS RFC only requires devices to respond to queries and broadcast when initially connecting, but periodic broadcasts are not required. Edit: https://datatracker.ietf.org/doc/html/rfc6762#section-10.2
Sorry if it wasn't clear enough.
Each device does the initial mDNS broadcast. But ESP8266 continues to broadcast when requested or when there's communication between devices are needed (HA->ESP->HA). The difference is that with ESP32 there is an initial broadcast and then is stops. It runs for about 15 seconds and then... nothing.
patagonaa
commented
2 years ago (TL;DR below) This can also be reproduced with a basically empty ESPHome project:
esphome:
name: esp32-mdns-test
esp32:
board: esp32dev
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_passAfter about two minutes after reset or upload, the device just goes offline in the UI. There is a mDNS reflector inbetween the ESP and ESPHome, but that hasn't caused any issues in the past and as you can see below, it always breaks no matter how I test it.
Also interesting:
Another device that uses an ESP32 as well that hasn't been upgraded in a while (log says ESPHome version 2021.12.0 compiled on Dec 13 2021, 19:40:45, framework arduino) works fine (avahi-resolve works and device is shown as online).
My devices using ESP8266 also work just fine with old and current versions alike.
What I've tried:
Testing using a device in the same network as the ESP32
Tested on a Raspberry Pi with avahi-daemon and avahi-utils installed:
$ avahi-resolve -n esp32-mdns-test.local
esp32-mdns-test.local 192.168.120.107and after about 2 minutes:
$ avahi-resolve -4n esp32-mdns-test.local
Failed to resolve host name 'esp32-mdns-test.local': Timeout reachedusing esp-idf instead of arduino-esp32
I tested with the current version of esp-idf (4.3.2) as well and with MDNS_STRICT_MODE: y and the issue is also there (though I don't know if 4.3.2 already includes the fix for this https://github.com/espressif/esp-idf/issues/7453 as there is only a major and minor (no patch) version in the esp-idf repo).
esp32:
board: esp-wrover-kit
framework:
type: esp-idf
version: "4.3.2"
sdkconfig_options:
MDNS_STRICT_MODE: ylooking at packets on the network
From the Raspberry Pi as above, I captured the packets while trying to resolve the mDNS host name using sudo tcpdump -i wlan0 -n -w capture.pcap -v port 5353, but the captured packets show the mDNS query but no response. Thinking about it (and if I understand the issue correctly), this should also disprove the theory that https://github.com/espressif/esp-idf/issues/7453 is the issue, because there isn't an invalid response to the mDNS request, but none at all
TL;DR:
patagonaa
commented
2 years ago OH MY GOD I fiddled around with everything a bit more and got it working. The damn WiFi access point (Unifi 6 Lite, latest firmware version) apparently just stopped forwarding mDNS traffic between the LAN and WIFI (how can this even happen?). The settings for this network (in the Unifi controller) are all set to the default values (no Broadcast/Multicast blocking, no IGMP, nothing) and it just started working after a reboot of the AP. The access point has been up for 64 days, but an AC Pro and an AC Lite with the same uptime work fine (the device with the older ESPHome version was connected to another AP so it worked, probably had nothing to do with the version at all).
Honestly, this was the last place I would've suspected to be the issue, but here we are 🤦.
I suspect you (@jpatriarca) might have the same issue.
jpatriarca
commented
2 years ago @patagonaa I effectively use Ubiquiti AP but I don't use their Avahi implementation, but another solution that brings a lot of stability to all devices in my IoT setup (that I could not get with Ubiquiti one). I got more than 20 IoT devices on my network, all of them with mDNS and every single one of the works, except ESP32 devices (this includes ESP8266). I'm aware that Ubiquiti mDNS implementation works (or worked before I made the mDNS changes) but it makes no sense for ESP8266 works out-of-the-box but ESP32 don't. So something in ESP32 firmware seems to not be properly working.
At this moment, setting up domain in wifi configuration bring me the control I need to check logs and update device firmware, as the issue now is just "cosmetic" in the ESPHome portal.
For more details, the solution I'm using is this one: https://github.com/alsmith/multicast-relay
patagonaa
commented
2 years ago Are the devices that work and don't work on the same access point? Also, I'm not using the Unifi mDNS Relay either (as I don't have a UDM or USG), but as the issue also occured without relaying the packets, that wasn't the problem.
If the issue occurs for ESP8266 and ESP32 devices on the same AP and you've tried rebooting the AP, there might be something else actually related to the ESP32 mDNS, but for me, it just started working after rebooting the AP.
jpatriarca
commented
2 years ago I have two ESP32 (both not working) and one ESP8266 connected to the same AP with the same SSID for IoT devices.
I've rebooted the AP several times, no change on the behavior.
Thank you for your help
patagonaa
commented
2 years ago Then you might actually have the issue described in https://github.com/espressif/esp-idf/issues/7453, maybe the multicast reflector you're using can't handle these malformed packets? I'm using avahi as an reflector and it works fine with the packets the ESPs send. Maybe connect a computer/laptop to the same network as the ESP32s and listen with Wireshark or tcpdump to see if there is actually no response or if the reflector or malformed packets are the issue?
nagyrobi
commented
2 years ago @rradar
donnyyu
commented
2 years ago Hi Guys, I solved this "Error resolving IP address of esp32.local" error by running a flungo/avahi container along with esphome and enable REFLECTOR_ENABLE_REFLECTOR
avahi:
container_name: avahi
image: flungo/avahi:latest
restart: "always"
network_mode: bridge
environment:
- REFLECTOR_ENABLE_REFLECTOR=yes 
ronaldvdmeer
commented
2 years ago I'm wondering. I have multiple ESP devices that have a hostname starting with multisensor-<random short string>. If I scan the network I only see those devices with a unique name in front of the dash like:
multisensor-abc123
fijnstofsensor-abc123
slimmemeter-abc123I don't see multisensor-123abc. Could it be that somehow the part before the dash causes a conflict cause else I would expect to see the other multisensor devices as well.
mDNS-scan
While on network:
didiermiller
commented
2 years ago I have the exact same problem as the OP. I have two devices on my network (yes same AP and SSID) and the ESP32 one will not register it's mDNS entry. As other suggested, created a "blank" ESP32 config straight from the ESPhome wizard, and same problem. Tested with multiple ESP32's and multiple ESP8266's, also with different APs and SSIDs.
DeltaTangoLima
commented
1 year ago I'm having the exact same problem. First ever use of an ESP32 board, have many ESP8266 devices that aren't displaying this issue. Currently on 2022.11.4.
This one ESP32 board will advertise mDNS on boot but, soon enough after, stops advertising it and the esphome dashboard can no longer find it. Confirmed by watching the services I readvertise across VLANs on my Aruba access points. The workaround I'm using is the use_address directive (with the device's IP address) to at least be able to connect to it for updates or to pull logs.
One other weirdness I noticed was that, when pulling logs from the device compared to any of my ESP8266 devices, this device doesn't list the DNS servers it would've received via the DHCP lease, whereas my ESP8266 devices do. I know that shouldn't impact mDNS advertising, but this definitely indicates a core difference in how each of the two platforms are behaving.
ESP8266 log excerpt:
[07:23:19][I][app:102]: ESPHome version 2022.11.4 compiled on Dec 4 2022, 12:27:52
[07:23:19][C][wifi:504]: WiFi:
[07:23:19][C][wifi:362]: Local MAC: [redacted]
[07:23:19][C][wifi:363]: SSID: [redacted]
[07:23:19][C][wifi:364]: IP Address: 192.168.40.116
[07:23:19][C][wifi:365]: BSSID: [redacted]
[07:23:19][C][wifi:367]: Hostname: 'climate-dining-ac'
[07:23:19][C][wifi:369]: Signal strength: -52 dB ▂▄▆█
[07:23:19][C][wifi:373]: Channel: 1
[07:23:19][C][wifi:374]: Subnet: 255.255.255.0
[07:23:19][C][wifi:375]: Gateway: 192.168.40.1
[07:23:19][C][wifi:376]: DNS1: 192.168.254.8
[07:23:19][C][wifi:377]: DNS2: 192.168.254.16
[07:23:19][C][logger:293]: Logger:
[07:23:19][C][logger:294]: Level: DEBUG
[07:23:19][C][logger:295]: Log Baud Rate: 115200
[07:23:19][C][logger:296]: Hardware UART: UART0ESP32 log excerpt:
[07:22:48][I][app:102]: ESPHome version 2022.11.4 compiled on Dec 7 2022, 08:12:31
[07:22:48][C][wifi:504]: WiFi:
[07:22:48][C][wifi:362]: Local MAC: [redacted]
[07:22:48][C][wifi:363]: SSID: [redacted]
[07:22:48][C][wifi:364]: IP Address: 192.168.40.119
[07:22:48][C][wifi:366]: BSSID: [redacted]
[07:22:48][C][wifi:367]: Hostname: 'bbq-temp-sensors'
[07:22:48][C][wifi:369]: Signal strength: -43 dB ▂▄▆█
[07:22:48][C][wifi:373]: Channel: 1
[07:22:48][C][wifi:374]: Subnet: 255.255.255.0
[07:22:48][C][wifi:375]: Gateway: 192.168.40.1
[07:22:48][C][logger:293]: Logger:
[07:22:48][C][logger:294]: Level: DEBUG
[07:22:48][C][logger:295]: Log Baud Rate: 115200
[07:22:48][C][logger:296]: Hardware UART: UART0This weekend, if I get time, I plan on pcapping inside my IoT VLAN to see if I can determine what's different.
savageautomate
commented
1 year ago OH MY GOD I fiddled around with everything a bit more and got it working. The damn WiFi access point (Unifi 6 Lite, latest firmware version) apparently just stopped forwarding mDNS traffic between the LAN and WIFI (how can this even happen?).
@patagonaa , Thank You for posting your findings! I was struggling with this issue as well and was chasing various bonjour/mdns settings and implementations for a few days. Just like in your case the problem all came down to a single Unifi 6 Long Range (U6-LR-US) access point. I have multiple Unifi access points that are older than the new "6" series and those were working fine. After a reboot of the U6-LR-US, all my ESP8266/ESP32 esphome devices started reporting correctly as online via the ESPHOME dashboard.
Did you find any settings or anything to stop this from occurring? I am running the latest firmware on the access point.
Thanks, Robert
patagonaa
commented
1 year ago Did you find any settings or anything to stop this from occurring? I am running the latest firmware on the access point.
@savageautomate I'm glad that I could somewhat help, but no, didn't change any settings, maybe some later Unifi firmware update fixed it, at least it seems to work for me now 🤷♀️
efaden
commented
1 year ago I'm having a similar problem. Can't figure out out, but some of my devices work and some don't. All on the same network. Some of the devices are even the same device and config except the IP/etc
EDelsman
commented
1 year ago I too seem to have this problem, but I don't have Unify. I have a Fritzbox mesh wifi. I have several ESP32's configured identically as bluetooth proxy (esp-idf). Their names only differ in the number, e.g. ble-proxy-3 All the nodes work just fine, but mdns stops after a while on some.
Rebooting the mesh node or the esp32 does not help. There seems to be no common factor in what works and what not.
I do have an esp32 that works fine on the ground floor but not in the attic. So it does seem the fritzbox is part of the problem. But again, both places use an identical wifi satellite node. And on the ground floor I have other esp's that work fine. If anything, the only common ground I can think of is that it fails on mesh nodes that only have one esp32 connected, but that may be a coincidence.
joerocklin
commented
11 months ago The settings for this network (in the Unifi controller) are all set to the default values (no Broadcast/Multicast blocking, no IGMP, nothing) and it just started working after a reboot of the AP.
I was having a very similar problem, but the reboot didn't persist the fix. I discovered I had some bad inform URLs. I made sure they were all correct and pointing to my controller, and then things started working okay.
Before discovering this, I also removed the IGMP Snooping and Multicast DNS settings, saved, waited some time, then turned it back on. This didn't appear to help any. I can't easily go back and try without doing this though, so I don't know if it was a necessary step along the way.
Update: This seems to have been a short-term fix. Still having issues on a unifi network. I don't think this is an esphome problem in my case.
bdraco
commented
11 months ago Checking multicast-relay logs on the specific docker image, I can see that when the devices boot, they send multicast request to all VLAN configured during the first 5 seconds the device are online, but then stops.
Correct me if I'm wrong, but this sounds like the correct behavior. The mDNS RFC only requires devices to respond to queries and broadcast when initially connecting, but periodic broadcasts are not required. Edit: datatracker.ietf.org/doc/html/rfc6762#section-10.2
Right, it should only respond when asked questions after the initial unsolicited broadcast
https://datatracker.ietf.org/doc/html/rfc6762#section-8.3
A Multicast DNS responder MUST NOT send announcements in the absence of information that its network connectivity may have changed in some relevant way. In particular, a Multicast DNS responder MUST NOT send regular periodic announcements as a matter of course.
bdraco
commented
11 months ago If its not answering questions that is authoritative for than this is a different problem. It seems like what is described above is that the ESP8266 is incorrectly sending regular periodic announcements which is specifically a MUST NOT. Unsolicited announcements are quite bad for network stability as broadcast traffic can be more significant for WiFi than unicast traffic https://web.archive.org/web/20201019031102/https://help.ui.com/hc/en-us/articles/115001529267-UniFi-Managing-Broadcast-Traffic
I can't replicate the misbehavior of the ESP8266 though so I suspect something else is going on here.
JamesHancockAtteria
commented
10 months ago All of my devices just stopped showing up although they're still there in dns. Is there a way to do a query from the docker container of esphome to see what it sees?
PS: Ubuntu sees all of the esphome devices, but windows does not.
emilianogetino
commented
8 months ago I have this same problem I think. I cannot connect to my devices by name (device.local), however by IP I can and the updates via ota work. This only happens to me with the esp32, I have an esp8266 and it doesn't have that problem. I use the esp-idf framework with the MDNS_STRICT_MODE: y option, but it doesn't solve anything. My wifi network is with Ubiquiti AP, my Mikrotik router and I do not have a vlan. Can I solve this somehow? Thank you.
Robbe-B
commented
3 months ago @emilianogetino, Same network, same problems here. For me, restarting all unifi AP's solves the problem for a while.
jankornblum
commented
1 week ago I can confirm this behaviour. First, i thought there might be anything wrong with my mDNS and VLAN setup, but that's not the case, because all other devices work fine! Even the ESP8266 works fine. But not ESP32. The ESP32 name resolution works just a few seconds after rebooting the device, then the name resolution gets lost.
The problem
Detected that ESP32 devices are not properly announcing mDNS .local domain when using multicast-relay solution. Before moving to this mDNS solution, I was using Avahi service that was working as expected. This brings the Offline status on ESPHome main page.
The nuance in this issue is that I have a ESP8266 with almost the same settings as my ESP32 (2 devices) and this is working as expected.
On my local network, in multiple VLAN configured, I can ping ESP8266 .local DNS name but the ones for ESP32 are not pingable. For the IoT VLAN, I have a specific internal DNS domain and all the devices are pingable. If I set the
domain:setting using my internal DNS for the specific IoT VLAN, nothing changes but I'm able to access the logs and upgrade ESP32 firmwares.Checking multicast-relay logs on the specific docker image, I can see that when the devices boot, they send multicast request to all VLAN configured during the first 5 seconds the device are online, but then stops. Instead, for ESP8266, it initiates the initial announce broadcast and then continue to broadcast each 15-90 seconds, as expected.
Which version of ESPHome has the issue?
2022.1.2
What type of installation are you using?
Home Assistant Add-on
Which version of Home Assistant has the issue?
2021.12.10
What platform are you using?
ESP32
Board
esp32dev
Component causing the issue
mDNS
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
multicast-reply logs for ESP8266 device:
Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br0/0.0.1.1 Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br10/0.0.10.1 Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br20/0.0.20.1 Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br40/0.0.40.1 Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br0/0.0.1.1 Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br10/0.0.10.1 Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br20/0.0.20.1 Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br40/0.0.40.1 Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br0/0.0.1.1 Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br10/0.0.10.1 Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br20/0.0.20.1 Jan-31 15:31:22 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 74 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br40/0.0.40.1 Jan-31 15:31:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 104 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br0/0.0.1.1 Jan-31 15:31:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 104 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br10/0.0.10.1 Jan-31 15:31:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 104 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br20/0.0.20.1 Jan-31 15:31:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 104 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br40/0.0.40.1 Jan-31 15:31:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 104 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br0/0.0.1.1 Jan-31 15:31:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 104 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br10/0.0.10.1 Jan-31 15:31:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 104 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br20/0.0.20.1 Jan-31 15:31:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 104 bytes from 0.0.0.2:5353 on br30 [ttl 255] to 224.0.0.251:5353 via br40/0.0.40.1multicast-relay logs for ESP32 device (presented logs are the only available on device boot time and only for some brief minutes):
Jan-31 10:57:34 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br0/0.0.1.1 Jan-31 10:57:34 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br10/0.0.10.1 Jan-31 10:57:34 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br20/0.0.20.1 Jan-31 10:57:34 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br40/0.0.40.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br0/0.0.1.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br10/0.0.10.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br20/0.0.20.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br40/0.0.40.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br0/0.0.1.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br10/0.0.10.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br20/0.0.20.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 132 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br40/0.0.40.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br0/0.0.1.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br10/0.0.10.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br20/0.0.20.1 Jan-31 10:57:35 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br40/0.0.40.1 Jan-31 10:57:36 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br0/0.0.1.1 Jan-31 10:57:36 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br10/0.0.10.1 Jan-31 10:57:36 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br20/0.0.20.1 Jan-31 10:57:36 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br40/0.0.40.1 Jan-31 10:57:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br0/0.0.1.1 Jan-31 10:57:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br10/0.0.10.1 Jan-31 10:57:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br20/0.0.20.1 Jan-31 10:57:37 ./multicast-relay/multicast-relay.py INFO: [mDNS] Relayed 247 bytes from 0.0.0.1:5353 on br30 [ttl 1] to 224.0.0.251:5353 via br40/0.0.40.1