-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using the ESP32-S3-USB-Bridge in a wireless mode at a remote site behind a firewall (AEGHB-753) #99
Comments
I am trying to build the usb_wireless_bridge example using ESP-IDF latest Master. the follow errors (and warnings) come up.
Any suggestions for trying to fix this? Although the example does not support standard Wifi and thus won't operate at a remote site behind a firewall (with NAT) we are just trying to test the concept. Thanks |
A month later and noresponse from anybody. The current repo does not build with ESP-IDF master, comes up with 100's of errors. Can we please get to a point ASAP where this can build with 5v3 or master, we would like to start a process to add normal IP support to access a device at a remote site. Please !!!! |
Sorry for the late reply. The public network debugging solution is quite interesting, and we already have clients who have developed remote debuggers based on the public network. However, we currently don't have the resources to dedicate to this feature, so you might need to experiment on your own. We will work on fixing the compilation issue as soon as possible. In the meantime, you can revert to the IDF version before release/v5.2 to ensure correct compilation. |
Thanks for the response, sorry about nagging. A: https://github.com/espressif/esp-dev-kits/tree/master/esp32-s3-usb-bridge/examples/usb_wireless_bridge 1: Why are there 2 different repos, both focussing on very much the same functionality Thank |
|
Thanks for the response. So if I understand correctly you will be focussing on A (usb_wireless_bridge) ASAP. Any plans or ideas for adding normal IP type communication as alternative to or replacement for ESP-NOW? |
It may be necessary for you to implement IP-based debugging on your own, but it is feasible, as some clients have already developed related products. |
@lijunru-hub We would like to get started working on the LWIP functionality but unable to do so with current state of the repo. Thanks for your help |
I'll look into it as soon as possible. |
Answers checklist.
General issue report
We would like to use this dev board to access remote target devices located at customer site and behind a firewall, across the internet. For this we believe ESP-NOW need to be replaced with a normal IP stack and the remote host device need to be configured to act as STA to the local Wifi at the customer site.
To make installation easier the remote device should also enable AP mode if it cannot connect to the local SSID. The remote host device should also be able to be powered from the target device via 5V or 3V3
To fulfil our remote diagnostic and support requirements we need to be able to access and control the remote target (RxD, TxD, EN and IO0) through the remote host, allowing us to monitor (UART) reset, read and write flash of the remote target.
This configuration working across the internet brings complications of firewalls (NAT config we can handle) and latency / propagation delays. It also requires some enhanced telnet support to control the RST and BOOT signals between the central site and the remote host to target connection.
At the central support site we would like to use standard Espressif tools in idf.py and esptool.py, both with the socket://remote.host:port addressing scheme:
Any reason why this functionality is not demonstrated in an example?
Is there any reason why this is not (easily) possible to achieve, something we might be missing.
Ultimately we are looking for a reliable, higher performing version of ESP-Link focussed on ESP32xx target devices, but without the MQTT etc bells and whistles.
All advice appreciated.
The text was updated successfully, but these errors were encountered: