Unable to reach ESP32 modules with v1.14.2 #816
Comments
|
Thanks for providing detailed logs and the note about mDNS. It sounds reasonable that mDNS might be the problem here. If it doesn't work, nothing will connect. I remember two code changes that could cause this:
|
|
OK, it is just weird and some others have reported similar issues here and here. About this log entry:
It mentions static_ip, but DHCP is used and is therefore confusing to me. Is it a red herring? I should add that if I refresh Chrome’s mdns browser app often enough, I do see the v1.14.2 ESP32 mdns entries albeit very briefly whereas the v1.14.2 ESP8266 mdns entries and v1.13.6 ESP32 mdns entries are always visible. |
No. After DHCP negotiation it's essentially the same as using a static IP - the log line shows that it got a valid IP from the DHCP server.
That's odd. The mDNS records have a TTL of around 2min, so if the extension should leave them there for at least 2min no matter what happens |
|
Added arduino_version: esphome:
name: esp32test
platform: ESP32
board: esp32doit-devkit-v1
arduino_version: 1.0.2but no change in resolving the hostname and no mdns entry in the mdns browser app. Also tried another brand keyesstudio ESP32, but same behaviour as the DoIt board. Are there other options to try? |
This comment has been minimized.
This comment has been minimized.
|
Not sure if this will help, but I use a Mikrotik 962UiGS-5HacT2HnT capable of packet sniffing. This is a Wireshark capture from two ESP32 nodes ESPHome Issue 816.zip. Mdns for both appear the same, but have never dealt with mdns before. |
|
Thanks for supplying detailed packet logs @DasBootU96! I had a look at them with wireshark and could not find anything.
What's missing is any device sending mDNS requests to the device - if HA or some other ESPHome client is on the network and trying to connect, they would be sending mDNS queries to which the ESP would respond. But that might be due to filtering the PCAP file. I tried an ESP32 with my own setup here and can't reproduce the issue. You also tried the
Edit: For reference, there's also #810 open with semi-similar symptoms. But I also doubt it's related because the ESP32/ESP8266 wifi and mDNS code is very different - they wouldn't happen at the same time with the same symptoms. |
This comment has been minimized.
This comment has been minimized.
|
@Spirituss That's a different issue -> #824 |
|
Tried without captive_portal and wifi AP enabled like so: wifi:
ssid: "WIFIAP"
password: "password"
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Esp32Test Fallback Hotspot"
password: "wGmReCrulAVP"
# captive_portal:No difference. Also, a few existing ESP32 nodes were upgraded from 1.13.6 to 1.14.2 and do not have fallback hotspot since as this is a new feature, but do have the same problem with mdns resolving. Previous Wireshark captures were filtered to two ESP32 MAC addresses only, I've attached new captures. Captured starts, then in ESPHome Dashboard, clicked 'show logs' for these two nodes: Once ESPHome logs show, Wireshark capture was stopped. For node Esp32test it took many retries and eventually showed logs after more than 2 minutes. For Node1 it took no retries and log showed after seconds. Here are Wireshark logs: Packet filtered on hassio (Pi4) and all ESPHome node MAC addreses only. You may notice other, excluded traffic. Of note are: issue #810 does have very, very similar symptoms, but for me three ESPHome 1.14.2 ESP8266 nodes work perfectly and have no issues resolving. Though I have never tested ESP8285. Hope this helps. |
This comment has been minimized.
This comment has been minimized.
|
I have the same issue: after updating to 1.14.2 from 1.13.6 I have issue with devices: can't connect to them in order to read logs or for the OTA updates. This forces me to downgrading to 1.13.6. |
|
@mikkaat @Gooman-rus Please confirm what you're facing is really an mDNS issue and not a more general disconnect issue. Please post what symptoms you're seeing, especially with @mikkaat I believe it is a case of #824 |
I don't use BLE tracker or other Bluetooth related things. My hardware is ESP32 and Waveshare E-ink display. I use this display in order to show data from homassistant. After updating to 1.14.2 I could not connect to my device via "show logs" button. It said that it can't determine IP of my device. Now I have used a homeassistant snapshot in order to downgrade ESPHome to 1.13.6. Also it forced me to manually install 1.13.6 firmware to my ESP32. And not it works very well. |
|
Update: Now mdns entries for ESPHome ESP32 nodes v1.14.2 are all visible and remain visible in Chrome's mdns browser. In the ESPHome Dashboard, show logs using the .local name works fine and I can update new builds to ESP32 nodes v1.14.2 using the .local name without issues or delays. However, opening any ESPHome node (v1.13.6 or v1.14.2 ESP8266/ESP32) webpage does not work via mdns .local (tried Chrome and Opera while on the same subnet as the nodes and Hassio), open webpage via its IP is fine. Also a few ESP32 nodes v1.14.2 have become unavailable which is easily resolved by deleting and adding again. Had the same webpage .local issue with the mDNS_Web_Server.ino Arduino example sketch on any of Espressif's ESP32 Arduino cores v1.0.1 through v1.0.4 regardless if I used FWIW: the original setup used Mikrotik 962UiGS-5HacT2HnT connected to a VLAN trunk and the Wifi connections for IOT Wifi and regular Wifi traffic were separated via a tag configured in Mikrotiks config on different VLANs with their own SSIDs. PFsense takes care of routing. Wired Hassio (Pi4) was connected to the same VLAN as the IOT Wifi network. All worked fine until the ESPHome v1.14.2 mdns resolving issues. It seems ESPHome ESP32 nodes v1.14.2 and VLANs don't play well toghether, but unsure what to exactly make of all this yet... Hope it helps. |
This comment has been minimized.
This comment has been minimized.
|
@DasBootU96 Thanks for the update. Yeah it might be due to the router. First assumption would of course be that an update changed the mDNS format and the router does not accept that format. But the packet captures you supplied looked fine - all valid mDNS packets. Also there were no major changes to esp-idf mDNS lately, so I don't think it's related to that. If it's the router and VLAN I would just say it's an issue with some network component in the chain not being happy with mDNS format. Since mDNS is sadly quite flaky anyway (from the protocol itself), I don't think there's much that can be done. |
|
I'm going to close this issue because I think it's due to some other/upstream issue. If there's more clear evidence showing that ESPHome is involved please re-open or create a new issue linking here. |
This comment has been minimized.
This comment has been minimized.
all those are ESP8266s. This issue refers to ESP32s. That's also part of the issue with resolving this - people post their symptoms all across several threads, and it gets really hard to understand what's related to what issue etc. You're probably looking for #838 |
The M in MDNS stands for multicast. It doesn't route across subnets, so if the devices are on a different vlan and subnet than your server it wont work unless you run a MDNS repeater with an interface on each network. That doesn't explain the drops, so there may be other issues, but I would definitely try to troubleshoot MDNS separately from the connectivity issues. |
|
Thanks, I'm aware mdns does not route across subnets. To clarify: Hassio, all ESP nodes and the system used to run Chromes mdns browser app are all on the same IOT VLAN subnet. Yet I experience missing mdns entries for ESP32 v1.14.x, while ESP8266 v1.14.x and ESP32 v1.13.6 node mdns entries are always visible. |
This comment has been minimized.
This comment has been minimized.
|
@mikkaat From your initial report, it's related to esp32_ble_tracker. See #824 for that. @DasBootU96 You see, from my perspective what I see is mDNS fails suddenly with 1.14.x, but there was no change to mDNS in that version - the only change was the SDK version, which you've ruled out by setting And from the packet captures (which is the best truth we're going to get on this issue), there are also no visible issues - if there were, we would see them there. Next, some of the other things mentioned here have also been ruled out. You don't have BLE enabled (as in @mikkaat's issue), you don't have an ESP8266 (which is using totally different code) as with @fribse. Adding to that, I can't replicate this issue. I've tried a bunch of setups with ESP32s and mDNS names with various names, but all work just fine. The only conclusion I can come to is that mDNS is not working well together with your router. I don't know what the real problem is, but with my time working with mDNS I also know that it doesn't make much sense exploring why mDNS does/doesn't work. mDNS itself is not that complex of a protocol, but some routers just don't like certain mDNS packets for whatever reason. |
|
So I just changed Mikrotiks wireless interface setting Here is what the Mikrotik manual says about Previously its was left as default which was: Thanks @OttoWinter and all others, yet I still do not know exactly why this change is required for v1.14.x while v1.13.6 was working fine without this change. Then again I'm not a hardcore networking guy. Hope this helps others with similar issues. Edit: I should have added that opening any EspHome nodes webpage by its .local/ url does not work for some reason, only works when typing in its ip. I have yet to figure that out, but it is minor for me. |
|
@OttoWinter thank you, I have been running those settings for about 3 hours now with no drops. |
Operating environment/Installation (Hass.io/Docker/pip/etc.):
Hassio 0.101.2 with ESPHome addon 1.14.2
ESP (ESP32/ESP8266, Board/Sonoff):
ESP32 - esp32doit-devkit-v1
Affected component:
mdns - https://esphome.io/guides/faq.html?highlight=mdns
Description of problem:
After uploading 1.14.2 to ESP32 (DoIt DevKit v1.0) modules, ESPHome Dashboard shows module as offline, I can no longer reach its webpage or upload new builds and there is no mdns entry for it in Chrome’s mdns browser app (running on same subnet). Current workaround is using fixed IPs.
After uploading 1.14.2 to ESP8266 (Wemos D1 mini or ESP01) modules have no problem and I can see an mdns entry.
Existing ESP32 modules still running 1.13.6 have no problem and I can see an mdns entry.
Problem-relevant YAML-configuration entries:
Logs (if applicable):
Additional information and things you've tried:
Using fixed IPs.
The text was updated successfully, but these errors were encountered: