## The problem
WiFiClient's connect method variant where no timeout is passed can block esp32 MCU and may then cause watchdog to kick in and reset the device. This behavior is different from that, what is in arduino-esp8266 core.
## Summary
Some cross-esp libraries (working both on esp32 and 8266), like PubSubClient simply call connect method on WiFiClient, to get connected to remote server. However, connect behavior varies betwen esp arduino 8266 and esp arduino 32 cores. This pull request tries introduce same behavior - to make connect method non-blocking on esp32, like it is with 8266 arduino core.
## Proposed solution
Introduce default fixed timeout that can be changed by #define - by default set to 3 seconds.
### Affected components:
WiFiClient
### Affected methods:
```c++
int connect(IPAddress ip, uint16_t port);
int connect(const char *host, uint16_t port);
```
### Impact
May impact projects or libraries using connect method variant without specified timeout, where:
- remote is located far away or
- connection is heavily limited, or
- remote is slow, when it comes to accept the connection
In [HTTPClient](https://github.com/espressif/arduino-esp32/tree/master/libraries/HTTPClient), if the `Transfer-Encoding` header is set to `identity`, an error (Transfer-Encoding not supported) will occur.
HTTPClient will consider the request as `identity` if the `Transfer-Encoding` header is not set. But it is also defined a response with `identity` explicitly set in the `Transfer-Encoding` header (ref:[MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding)).
This pull request will allow the request to be processed normally even when `identity` is explicitly set.
lwip lib bundled with esp32 Arduino supports only one ntp server. Any additional servers set are just silently ignored.
This default is different from esp8266 Arduino core and very confusing. Most of the examples provided uses 3 different ntp servers for redundancy while only the first one is used actually.
Addressing issue #4964
Closes#5398
Using the same non-blocking socket connect pattern for respecting connection timeout, copied from WiFiClient::connect.
WiFiClient::connect uses lwip_connect_r, whereas start_ssl_client uses lwip_connect. I haven't found what is the difference between them. I tested both, both work ok, so I kept lwip_connect.
* Fix compile archive arguments for the new toolchain
* Add menu to S2 for picking through which port to upload
Internal USB CDC requires to reset and wait for the new port (because persistence is not yet stable)
* USB CDC should also be started in main
* Fix URL and USB version for WebUSB
* Update vendor callback API
* Update CDC::write to use TX_DONE semaphore
* Update USB_Serial example
A typographical error is corrected in the 2nd line of the comment.
From = " This is un example howto use Touch Intrrerupts "
To = " This is an example of how to use Touch Intrrerupts "
* Update toolchain
* Update package_esp32_index.template.json
* add optional component dependencies after Kconfig options are known (#5404)
Until this commit, Kconfig options (e.g. CONFIG_TINYUSB_ENABLED) were
used in conditions preceding idf_component_register to determine which
components need to be added to `arduino` component requirements.
However the Kconfig options aren't known at the early expansion stage,
when the component CMakeLists.txt files are expanded the first time
and requirements are evaluated. So all the conditions evaluated as if
the options were not set.
This commit changes the logic to only add these components as
dependencies when the Kconfig options are known. Dependencies become
"weak", which means that if one of the components isn't included into
the build for some reason, it is not added as a dependency.
This may happen, for example, if the component is not present in the
`components` directory or is excluded by setting `COMPONENTS` variable
in the project CMakeLists.txt file.
This also ensures that if the component is not present, it will not be
added as a dependency, and this will allow the build to proceed.
Follow-up to https://github.com/espressif/arduino-esp32/pull/5391.
Closes https://github.com/espressif/arduino-esp32/issues/5319.
* IDF master d93887f9f
* PlatformIO updates for CI (#5387)
* Update PlatformIO CI build script
- Switch to the latest toolchains 8.4.0 for ESP32, ESP32S2, ESP32C3
- Use PlatformIO from master branch for better robustness
* Update package.json for PlatformIO
Co-authored-by: Ivan Grokhotkov <ivan@espressif.com>
Co-authored-by: Valerii Koval <valeros@users.noreply.github.com>
Commit d15e1b0e [1] in the 2.0.0 pull request #4996 introduced a filter
to connect only to WiFi networks with a RSSI of -75 or better. This
results in strage behaviour, as a scan still shows networks, that can't
be connected to, even though with older versions, connecting to those
networks was possible and the connection (albeit slow) was stable.
Remove the RSSI filter for now by setting the threshold to -127, i.e.
the lowest possible value. Maybe in the future the filter threshold
could be exposed to users, to allow filtering out nearly unreachable
networks.
[1] github.com/espressif/arduino-esp32/pull/4996/commits/d15e1b0
When iterating through APlist from first to the last element, a corrected password for already known SSID is not used. Therefore, I propose to iterate from the back of the list. With iterating from the back through the vector, an already known SSID with a corrected password is used instead.
Proposed fix to #4627 as a remediation to PR #3995#3995 introduced that a device detected on BLE would not be entered in vector if a callback has been defined.
By doing so, it was not possible anymore to have a counter in a call back (AND device in vector) to limit the number of detected device in a single scan, which could crash ESP32 as a result.
* add onMtuChanged to BLEServerCallbacks
Add method onMtuChanged to the BLEServerCallbacks so the application can be notified if the MTU size changes.
* Correct missing semicolon and misspelled method.
Correct missing semicolon and misspelled method.
Thi may happen if read() gets called repeatedly (such as in HttpClient to parse response headers) and the connection is closed unexpectedly or the remote peer may have unexpected behavior that causes the underlying socket to report an error. In that case read() itself calls stop(), which invalidates the receive buffer object. Then when read() is called again without checking, such as inside readStringUntil(), the _rxBuffer is null and ESP32 crashes.
Pull request #4999 added setMTU function to BLEClient.cpp/.h, this line provides implementation of this added functionality to the BLE client example to resolve cases in which data from notifyCallback exceeds 20 characters (3 bytes for command type and attribute ID, 20 bytes for attribute data (char*)pData).
Added new BLE5 features to use on C3/S3 family:
extended scan,
extended/multi advertising
New code is not fancy (no feedback from events), but i think it is functional. To get feedback from events i am suggesting to use custom GAP callback, which is already implemented in BLEDevice.
- Use Serial.print instead of log_i for QR code helper information,
so that it is always printed by default.
- Expose the RainMaker factory reset and wifi reset APIs.
- Simplify example to have only a Switch device. Create another example for custom device.
- Enable push button based Factory reset and Wi-Fi reset.
- Added support for the TimeZone service.
- Moved API doc to RainMaker library's top level README.
- Other minor doc changes.
Hey guys,
so I wanted to do a BtClassic Discovery without the need to call connect
and to list all found devices on a display and continue work with that list.
I wasn't capable to test the example code with my file structure, but I did use the discovery already in some different situations.
However when I noted that the Bluedroid stack won't let me enforce an RfComm SPP connection to a GPS Device (Skytraxx 2 plus, I guess its interface is built so simple that it doesn't advertise its SPP over SDP), I will probably have to switch to BtStack (BlueKitchen) and stop on this side meanwhile
The current implementation has a getMTU function which returns the mtu sent in a message.
This function allows you to set the MTU value on the connected device, it first sets the MTU locally by calling esp_ble_gatt_set_local_mtu. It then calls esp_ble_gattc_send_mtu_req to have the connected device also change its MTU size.
This adds support for the KSZ8081 ethernet phy.
Only the IDF 4+ specific code is modified, as the phy support was only
added recently:
espressif/esp-idf@aecfbf96
This is very much still work in progress and much more will change before the final 2.0.0
Some APIs have changed. New libraries have been added. LittleFS included.
Co-authored-by: Seon Rozenblum <seonr@3sprockets.com>
Co-authored-by: Me No Dev <me-no-dev@users.noreply.github.com>
Co-authored-by: geeksville <kevinh@geeksville.com>
Co-authored-by: Mike Dunston <m_dunston@comcast.net>
Co-authored-by: Unexpected Maker <seon@unexpectedmaker.com>
Co-authored-by: Seon Rozenblum <seonr@3sprockets.com>
Co-authored-by: microDev <70126934+microDev1@users.noreply.github.com>
Co-authored-by: tobozo <tobozo@users.noreply.github.com>
Co-authored-by: bobobo1618 <bobobo1618@users.noreply.github.com>
Co-authored-by: lorol <lorolouis@gmail.com>
Co-authored-by: geeksville <kevinh@geeksville.com>
Co-authored-by: Limor "Ladyada" Fried <limor@ladyada.net>
Co-authored-by: Sweety <switi.mhaiske@espressif.com>
Co-authored-by: Loick MAHIEUX <loick111@gmail.com>
Co-authored-by: Larry Bernstone <lbernstone@gmail.com>
Co-authored-by: Valerii Koval <valeros@users.noreply.github.com>
Co-authored-by: 快乐的我531 <2302004040@qq.com>
Co-authored-by: chegewara <imperiaonline4@gmail.com>
Co-authored-by: Clemens Kirchgatterer <clemens@1541.org>
Co-authored-by: Aron Rubin <aronrubin@gmail.com>
Co-authored-by: Pete Lewis <601236+lewispg228@users.noreply.github.com>
