Using the ESP32-S3-USB-Bridge in a wireless mode at a remote site behind a firewall (AEGHB-753) #99
Comments
github-actions
bot
changed the title
|
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. |
|
Any progress on updating for IDF v5.3 or master. It would be of great value to have some idea of when we can expect to start testing, even if just an early beta version? In your post about a month ago you mentioned that some clients have already developed related products, any chance you can provide me with links to those so I can have a look at viability to purchase/use? The requirement to debug and flash remote devices behind a firewall has high priority on our side... Thanks |
|
@lijunru-hub, sorry to continue bugging you but...
If we can find something already available with the required minimum functionality and at a justifiable price that can buy us (and yourself) some time. Please, please, please, becoming critical this side.. |
|
@ammaree That's odd. I can access the link normally from my side using Chrome, and my IP address is based in Hong Kong. |
|
Thanks for the info, got to the link, translated, but the PW200 but cannot get more info, nor can I create a login from South Africa. Found www.powerwriter.com, only product that MIGHT be able to do the trick is the PowerDebugger. None of the PW200/300/400/PWLINK2/PWX1 has wifi capabilities. Considering the list of functionality it seems the product is focussed on ARM and limited RISC-V with SWD/ITM/JTAG etc, none of which we are interested in. All we need is remote access via public IP to ESP32xxx UART port for monitoring and flashing. Have looked for a price to determine feasibility but cannot find it anywhere, so maybe you can help with separate pricing for PowerDebugger TX and RX items. But considering we need 2xTX and ~10xRX to start with, very unlikely to be justifiable. |
|
Any chance you can assist to move this issue forward, please? We are based in South Africa and the TaoBao link provided is of no help to us. The proposed alternative product does not look viable to us, not specifically ESp32 focussed and unlikely justifiable price. If we can just get the existing example updated to successfully compile with v5.3 or preferably master, that will be a big step forward. Although the ultimate goal still has to be full IP support to access remote devices behind a firewall. Thanks |
|
@ammaree |
|
Thanks for the update, have synced the repo, done full clean (couple of times) but still coming up with errors Any suggestions? |
|
I am unable to reproduce this error on my side; the compilation completes successfully. |
|
Are you building using Master or a different version?
I am using absolute latest master on macOS.
On 24/10/25, 13:24, "Li Junru" ***@***.******@***.***>> wrote:
I am unable to reproduce this error on my side; the compilation completes successfully.
—
Reply to this email directly, view it on GitHub<#99 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAYT7GHXR2DDVIT2REWG7PTZ5IS7PAVCNFSM6AAAAABLSZSFY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZXGUZTKNJSGM>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Apologies, fault is my side. Cleaned everything, resync'd and tried again, all working. Will now try to flash the new firmware and then start looking at adding the remote IP support. Just so I know, is there a changelog available that I can look at to be aware of changes? Thanks again. |
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: