In some use cases getting rssi signal from one channel is more stable (less variance) than rssi from the three advertising channels.
This change allows you to specify which channels are used to advertise.
In case you have multiple APs with the same SSID/password and WiFi.begin(ssid, pwd) is called, ESP32 defaults to connect to THE FIRST AP FOUND matching ssid - according to:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network/esp_wifi.html#_CPPv418wifi_scan_method_t
This can cause situations that ESP32 is trying to connect to AP which is far away from it (weak signal) even there is AP close to it, just as in my house - I have AP on channel 6 which is in the 1st floor (quite far from room where I do the programming) and AP on channel 13 in the same room I do the programming (which is in the 2nd floor) - result: ESP32 is trying to connect to the AP on channel 6 because it finds it first and never try the AP on channel 13 in the same room, result of this is very unreliable WiFi connection.
When scan_method is set to WIFI_ALL_CHANNEL_SCAN, ESP32 scans all channels and choose the nearest / strongest AP (matching the ssid of course) as expected - result is no connection problems at all.
Therefore I propose adding this parameter into WiFi.begin, connection problems as described above are quite confusing (especially for beginners), I can imagine that for example Schools there are usually using mutliple APs and this can cause intermittent connection problems without obvious reason.
Fixes: #4884
* Use HTTP method table from ESP-IDF's nghttp
* Parse methods using IDF's HTTP method list
* Make example's loops to allow the CPU to switch tasks
- File might not eval to false if opened with write/append and SD is gone
- Allow card to be formatted if FAT partition was not found
- Mark card as gone in certain situations
- Fix several logic errors in low level SD API
mbedTLS requires repeated calls to mbedtls_ssl_write() whenever it returns MBEDTLS_ERR_SSL_WANT_READ or MBEDTLS_ERR_SSL_WANT_WRITE. this happens when the client sends data faster then the server or the connection can handle.
- Remove client from the list of devices in case registration fails
- Filter other events not related to registration during registration phase
- Cleanup if connect fails
- Reset if after disconnect
- Disconnect callback *after* cleanup is done so object can be deleted
This fixes some of the issues I had like:
- `BLEClient::connect` hangs up and never recovered because registration failed
- `BLEClient` could not be deleted after disconnect or deletion creating ghost events https://github.com/espressif/arduino-esp32/issues/4047
- `BLEClient` could not be properly reused after a connection was attempted (successful or not)
* Cleanup in case of registration and connect failure.
Cleanup before calling disconnect callback for safe delete.
Reject other events during registration.
Adresses #4047, #4055
* Clear if after unregister #4047
fixes#4596
* Prevent possible undefined behaviour by get methods not taking an index as parameter
* Add methods to get the count of service data UUIDs and service UUIDs
* Various code improvements
* Speed up upload by a factor of 17
Uploads are very slow because of an unnecessary "client.connected()" check in _uploadReadByte().
Here is what happens:
client.connected() is called for every byte read. WiFiClient::connected() calls recv(fd(), &dummy, 0, MSG_DONTWAIT); which takes a relatively long time, so the optimized path of returning a buffered byte via client.read() is effectively nullified.
Removing the one line changed the upload speed for a 2 MB file (discarding the received data) from 22 KB/sec (before) to 367 KB/sec (after).
The change is safe in the face of disconnects because client.read(), when it no longer has buffered data, calls (WiFiClient) fillBuffer(), which calls recv(), so the disconnection will be detected in due course.
* Move disconnect check into the timeout loop
Compiler complains on unused parameter pCharacteristicMap:
framework-arduinoespressif32\libraries\BLE\src\BLERemoteService.cpp: In member function 'void BLERemoteService::getCharacteristics(std::map<short unsigned int, BLERemoteCharacteristic*>*)':
\framework-arduinoespressif32\libraries\BLE\src\BLERemoteService.cpp:246:89: warning: parameter 'pCharacteristicMap' set but not used [-Wunused-but-set-parameter]
void BLERemoteService::getCharacteristics(std::map<uint16_t, BLERemoteCharacteristic*>* pCharacteristicMap) {
See #3960 for more details of the problem and the solution. I only implemented what was proposed in this ticket, as it solves my problem, which was the same as in this ticket. Credits for the code going to @etrinh ;-)
This also is a more consistence behaviour compared to esp8266, where it also is possible to restart the wifiserver immediately on the same port.
* fix typo in WiFiMulti
* clean up trailing spaces
* clean up script file used in cleaning
Co-authored-by: Me No Dev <me-no-dev@users.noreply.github.com>
* improve & fix BLEScan when too many BLE devices
- when wantDuplicates, no need to check duplicate and no more insert into vector
- delete advertisedDevice when not insert into vector, fix memory leak
- add showParse when you just want raw advertised data
Remove device from Peer list if connection fails.
Only call onConnect callback if connection was successful.
Only call onDisconnect callback if the connection was previously connected (ESP_GATTC_DISCONNECT_EVT is fired on a unsuccessful connection attempt also).
Resolves a number of issues with phantom events and callbacks being fired.
::addPeerDevice and ::removePeerDevice are called with m_appId, so should ::updatePeerDevice as all use the same parameter for the underlying map's key.
* Fix for issue #4158: Crash with stack trace originating in Bluedroid
Improved configuration of scan response data in 'BLEAdvertising' avoids the crash:
- Added member variable 'm_scanRespData' to configure scan response differently from advertising data
- Initialization of 'm_scanRespData' in BLEAdvertising constructor
- Use of 'm_scanRespData' within BLEAdvertising::start() to configure the scan response
- 'Flags' and 'Appearance' are cleared in the scan response data
- With this fix, device names of up to 29 characters can be used without causing a crash.
Fixes: #3460
This code has been run in production for 1 month and it looks stable, no data dropped and it definitely fixes the issue described. I think that this can be merged to avoid using custom package referencing in PlatformIO that has been used in quite a few projects for now.
Co-authored-by: Ivan Golubic <ivan@mvt-solutions.com>
The UpdateClass in the Updater component has the ability to update data to
a SPIFFS partition. It selects the first available partition using the
ESP-IDF esp_partition_find_first() function.
That behaviour is problematic if one has multiple SPIFFS partitions.
This change allows a user to pass the label argument (defaults to NULL)
to UpdateClass::begin() so a specific SPIFFS partition can be updated.
Additionally, ArduinoOTA can set this partition label using the
new method ArduinoOTAClass::setPartitionLabel which is optional.
This change does not break compatibility.
* Add partition label argument to SPIFFSSPIFFS currently assumes there is only ever one partition.This change allows a user to pass the label argument (defaults to NULL)to SPIFFS::begin() so a specific SPIFFS partition can be referenced.This change does not break compatibility.
* BLERemoteChar: fix descriptor 2902 write for characteristic notifications
When registering a notification on a characteristic, the 2902 descriptor
(CCCD) value is set to 1 (or 2 for indication).
According to the BLUETOOTH CORE SPECIFICATION Version 5.2, Revision Date
2019-12-31, section 4.12.3 "Write Characteristic Descriptors" (page 1588),
the characteristic descriptor write must expect a response.
Currently, the descriptor write is performed without expecting a reponse,
which prevents the notification to be functional with some BLE stacks.
This commit modify the write to expect the response.
Signed-off-by: Jimmy Durand Wesolowski <jimmy.durand.wesolowski@commsolid.com>
* BLERemoteChar: forward GATT client event to characteristic descriptors
This commits prevents a permanent wait when calling BLERemoteDescriptor
readValue function, on the m_semaphoreReadDescrEvt semaphore.
ESP32 BLE stack calls to remote characteristic
- notification,
- value read
- value write
and remote characteristic descriptor
- value read
are asynchronous.
When such a call is performed by this library, a semaphore is taken prior
to the BLE stack read or write operation, and waited on after it.
Releasing the semaphore is done by the characteristic event handling
function (gattClientEventHandler), when the appropriate event is received.
However, the characteristic descriptor events are discarded, and the
value read semaphore is never released.
This commits forwards the GATT client events from the remote
characteristic down to their remote characteristic descriptor, and
implements their event handling.
Adding a semaphore for the remote characteristic descriptor value write
will be done in a separate commit.
Signed-off-by: Jimmy Durand Wesolowski <jimmy.durand.wesolowski@commsolid.com>
* BLERemoteDescriptor: add semaphore to characteristic descriptor write
This adds a semaphore to characteristic descriptor value write, to mimic
the value read function, and to ensure completion of the operation before
we carry on.
Signed-off-by: Jimmy Durand Wesolowski <jimmy.durand.wesolowski@commsolid.com>
Co-authored-by: Jimmy Durand Wesolowski <jimmy.durand.wesolowski@commsolid.com>
* Add an aditional (void *) arg to the RMT callback - to allow more flexible handling of the callback (e.g. by passing a private struct or a class pointer). Same pattern as used by the Ticker() and many others. Example updated & new example with a trapoline added.
* Fix example for new API
* Fix lint warnings
* Add a second missed example.
* Correct timeout & improve socket error handling.
I met problem while I was working with the WiFiClientSecure.
I tried to found the source of the problem, and I found it in the sll_client.cpp.
Please check my contribution.
I've open this problem in #4335 but received no response.
I spent quite a while today figuring out how to get an OTA update over HTTPS on a custom port working. A part of my problem was not putting a slash before the .bin filename, since it wasn't there in the example. This produced invalid HTTP requests. Adding the slash would make it clear that it needs to be there.
Given that the URL in line 53 contains the same words "server" and "file.bin", one might assume that in line 55, the slash after the port number would get added automatically, however I have found out that without a slash you get an invalid request. Adding the slash removes any doubt.
I was playing with the mDNS service and noticed the method MDNSResponder::addService could return a Boolean with the way it is implemented just like other functions in this library.
This would be handy to know at a higher level weather or not the service was added correctly to the mDNS server of the ESP32.
This is a fix for missing scan responses after a first successfull scan.
While running the BLE_scan.ino sketch with wantDuplicates=false, i got
only one result with correct advertising and scan response length (31,26):
pBLEScan->setAdvertisedDeviceCallbacks(new MyAdvertisedDeviceCallbacks(), false);
pBLEScan->start(scanTime, false);
...
[W][BLEScan.cpp:109] handleGAPEvent(): bytes length: 31 + 26, addr type: 1
All following calls to start() just returned the advertising data without
scan response data:
pBLEScan->start(scanTime, false);
[W][BLEScan.cpp:109] handleGAPEvent(): bytes length: 31 + 0, addr type: 1
With "wantDuplicates=true" i got:
pBLEScan->setAdvertisedDeviceCallbacks(new MyAdvertisedDeviceCallbacks(), true);
pBLEScan->start(scanTime, false);
[W][BLEScan.cpp:109] handleGAPEvent(): bytes length: 31 + 26, addr type: 1
[W][BLEScan.cpp:109] handleGAPEvent(): bytes length: 31 + 26, addr type: 1
[W][BLEScan.cpp:73] handleGAPEvent(): ESP_GAP_SEARCH_INQ_CMPL_EVT
Devices found: 1
Scan done!
pBLEScan->start(scanTime, false);
[W][BLEScan.cpp:109] handleGAPEvent(): bytes length: 31 + 0, addr type: 1
[W][BLEScan.cpp:109] handleGAPEvent(): bytes length: 0 + 26, addr type: 1
[W][BLEScan.cpp:109] handleGAPEvent(): bytes length: 31 + 0, addr type: 1
[W][BLEScan.cpp:109] handleGAPEvent(): bytes length: 0 + 26, addr type: 1
Explicitly initializing m_scan_params.scan_duplicate of BLEScan solves
this issue (In my case the un-initialized value was
m_scan_params.scan_duplicate == 1073599044).
Co-authored-by: Me No Dev <me-no-dev@users.noreply.github.com>
* If WebServer.handleClient is run in a tight loop, it will starve other processes. So, if there is no connection, throw in a delay(1). Fixes#4348
* Made a variable to control the delay behavior
* Update Parsing.cpp
When uploading TLS cert files the end of file "-----END CERTIFICATE-----" (or any kind of file with the sequence "CRLF--") is taken as posible end boundary. Then it is compared to the start boundary string. As it is expected, comparison turns to be false, and the whole end boundary string is put to _currentUpload->buf through _uploadWriteByte(). Here you have the problem: if you read boundary.length() bytes from HTTP request and you have some of the actual end boundary bytes in it, when you put all those bytes into _currentUpload->buf you are making a mistake. You will miss the actual end boundary string because some of those bytes were put in _currentUpload->buf.
* Update Parsing.cpp
SPIFFS causes crashes if you attempt to rmdir. Since there are no true directories in spiffs, this ought to be a noop. It looks like @me-no-dev worked around this by using unlink instead of rmdir, which works in fatfs and doesn't panic spiffs. This behavior is not universal. In order to get littlefs working, it would be good to get this back to conformity. Rather than digging deep into the upstream spiffs, I just check the mountpoint and noop if it is "/spiffs". So, if the user has changed the mountpoint, this will not work, but I think it's a pretty good tradeoff.
Successful exploitation could lead to arbitrary code execution.
The bug can be reproduced by running the following in a browser:
```
const formData = new FormData();
for (let i = 0;i < 33;++i) { formData.append("foo", i.toString()); }
await fetch("http://esp.local", { method: 'POST', body: formData });
```
Informed by the discussion in the bug and the code in 'that other branch'
the fix was clear. Just set a flag if we start handling a write, and
use that flag to guard the long write complete call.
