Closed JanneKiiskila closed 2 months ago
It seems that the device connected to Wi-Fi successfully and get ipv4 address 192.168.178.56
.
For command wifi state
returns disconnected
at auto start mode
, it is a legacy issue present in esp-thread-br v1.0
, which has been resolved in the latest code. You can switch to esp-idf v5.1.3
and esp-thread-br main
, and try again.
Additionally, when manually connecting to Wi-Fi, the SSID must be specified. For example, use wifi connect -s my_ssid -p my_password
instead of wifi connect
.
Why would you not then update the documentation to match this? Though it's probably not good to point to a floating main, but you should then advice:
I can confirm Wi-Fi now stays online. However, the NRF 52840 is now not able to connect fully to the OpenThread network. Earlier it (ESP-IDF 5.1.2 and v1.0) was able.
<inf> net_state: Waiting for OT connection
Is the place where it hangs in the NRF 52840. If I run discover in the ESP32 it says:
> discover
| Network Name | Extended PAN | PAN | MAC Address | Ch | dBm | LQI |
+------------------+------------------+------+------------------+----+-----+-----+
| OpenThread-7491 | 590a87a6774a99a3 | 7491 | d69404908b004a00 | 14 | -60 | 9 |
I(1612049) OPENTHREAD:[N] MeshForwarder-: Failed to send IPv6 UDP msg, len:56, chksum:c694, ecn:no, to:None, sec:no, error:Abort, prio:net
I(1612049) OPENTHREAD:[N] MeshForwarder-: src:[fe80:0:0:0:d8d5:c426:8c38:9ece]:19788
I(1612049) OPENTHREAD:[N] MeshForwarder-: dst:[ff02:0:0:0:0:0:0:2]:19788
Done
With the version 1.0 it did not give those errors of not being able to send.
There is still something funny going on with the Wi-Fi or connectivity overall as well, as I would assume I should be able to do for example dns resolve www.google.com
w/o issues.
It does not work, it times out.
> dns resolve www.google.com
DNS response for www.google.com. -
Error 28: ResponseTimeout
Ping does not seem to accept anything but direct IP-addresses.
> ping 142.251.116.94
Pinging synthesized IPv6 address: fdc5:5592:9dc2:2:0:0:8efb:745e
1 packets transmitted, 0 packets received. Packet loss = 100.0%.
Done
> ipaddr
fd16:e34a:a433:eea8:0:ff:fe00:fc37
fd16:e34a:a433:eea8:0:ff:fe00:fc10
fdc5:5592:9dc2:1:b1e1:43a3:9ad6:b3d9
fd16:e34a:a433:eea8:0:ff:fe00:fc00
fd16:e34a:a433:eea8:0:ff:fe00:c000
fd16:e34a:a433:eea8:55ed:c28b:cb21:f776
fe80:0:0:0:d8d5:c426:8c38:9ece
Done
> netdata show
Prefixes:
fdc5:5592:9dc2:1::/64 paros low c000
Routes:
fdc5:5592:9dc2:2:0:0::/96 sn low c000
::/0 sa med c000
Services:
44970 5d fd16e34aa433eea855edc28bcb21f776d11f s c000
Contexts:
fdc5:5592:9dc2:1::/64 1 c
Commissioning:
49983 c000 - 00000000000000000000000000000000
Done
> ping 8.8.8.8
Pinging synthesized IPv6 address: fdc5:5592:9dc2:2:0:0:808:808
1 packets transmitted, 0 packets received. Packet loss = 100.0%.
Done
In the documentation, we default to using the latest esp-thread-br commit. In fact, if you follow the git clone xxx
command in the document, esp-idf will be on v5.1.3 and esp-thread-br will be on the main branch by default, with no need to manually switch.
For the esp-thread-br tag
, we will specify the corresponding esp-idf tag at the time of release. Please refer to:
https://github.com/espressif/esp-thread-br/releases/tag/v1.0
There is still something funny going on with the Wi-Fi or connectivity overall as well, as I would assume I should be able to do for example
dns resolve www.google.com
w/o issues.It does not work, it times out.
> dns resolve www.google.com DNS response for www.google.com. - Error 28: ResponseTimeout
Ping does not seem to accept anything but direct IP-addresses.
> ping 142.251.116.94 Pinging synthesized IPv6 address: fdc5:5592:9dc2:2:0:0:8efb:745e 1 packets transmitted, 0 packets received. Packet loss = 100.0%. Done
> ipaddr fd16:e34a:a433:eea8:0:ff:fe00:fc37 fd16:e34a:a433:eea8:0:ff:fe00:fc10 fdc5:5592:9dc2:1:b1e1:43a3:9ad6:b3d9 fd16:e34a:a433:eea8:0:ff:fe00:fc00 fd16:e34a:a433:eea8:0:ff:fe00:c000 fd16:e34a:a433:eea8:55ed:c28b:cb21:f776 fe80:0:0:0:d8d5:c426:8c38:9ece Done > netdata show Prefixes: fdc5:5592:9dc2:1::/64 paros low c000 Routes: fdc5:5592:9dc2:2:0:0::/96 sn low c000 ::/0 sa med c000 Services: 44970 5d fd16e34aa433eea855edc28bcb21f776d11f s c000 Contexts: fdc5:5592:9dc2:1::/64 1 c Commissioning: 49983 c000 - 00000000000000000000000000000000 Done > ping 8.8.8.8 Pinging synthesized IPv6 address: fdc5:5592:9dc2:2:0:0:808:808 1 packets transmitted, 0 packets received. Packet loss = 100.0%. Done
Hi @JanneKiiskila Please refer to 3.3. Service Discovery, Notice a suffix .default.service.arpa.
is needed, and also, the dns resolve
should only work for the thread devices(not BR but the other device in the thread network.) For the BR, it can access the wifi link, so if you want to resolve some websites on BR, you can use the LWIP api directly.
For the ping command, also only works for the thread device. Hope this FAQ can help you a lot.
@JanneKiiskila Hope the previous answers helped, feel free to reopen if you have any follow up questions.
Checklist
How often does this bug occurs?
always
Expected behavior
I would assume the ESP32 can connect to a Wi-Fi and stay connected - in the esp-thread-br context.
I have been following the documentation in the OpenThread.io website to build the SW.
ESP-SDK:
Example version v1.0:
Actual behavior (suspected bug)
The Wi-Fi connection does not stay up, Wi-Fi is in state disconnected. When trying to connect manually with wifi connect - the device reboots.
Network SSID and passphrase have been provided via the configuration.
Error logs or terminal output