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.
Background
The current implementation of Update() uses the spi_flash_* api to write and read from flash. These functions ignore the partition->encrypted flag and always write raw data to flash even if the partition is marked as encrypted.
Changes in this PR
Update() now uses the esp_partition_* api.
Wrapper functions for esp_partition_* added to ESP.cpp. This was done to maintain a consistent approach to the way the spi_flash_* functions were used. I note though that not all of the esp-idf functions are used are wrapped, for example esp_ota_get_next_update_partition() so it may be that these should not be added?
The current implementation of Update() changes the first (magic) byte of firmware to 0xFF on write, and then when the firmware is completely written changes it back to ESP_IMAGE_HEADER_MAGIC. This works without erasing the sector because flash bits can be changed from 1->0 (but not 0->1). If the flash is encrypted then the actual data written to flash will not be all ones, so this approach will not work. In addition, encrypted flash must be written in 16 byte blocks. So, instead of changing the first byte the changed code stashes the first 16 bytes, and starts writing at the 17th byte, leaving the first 16 bytes as 0xFF. Then, in _enablePartition() the stashed bytes can be successfully written.
Benefits
Whilst it's not possible to use encrypted flash directly from either the Arduino IDE or PIO it's reasonably straightforward to compile and flash a bootloader with the necessary support from a simple esp-idf project and then use ArduinoOTA for subsequent updates. This PR enables the use of this workflow until such time as encrypted flash is supported, and is a first (small) step toward adding support.
Regardless of the above, the esp_partition_* api is recommended over the api_flash_* api.
Application code should mostly use these esp_partition_* API functions instead of lower level spi_flash_* API functions. Partition table API functions do bounds checking and calculate correct offsets in flash, based on data stored in a partition table.
By default the disconnect is broadcasted to every clients. So if you call disconnect on one connected client, they'll all be disconnected if we don't filter the event by conn_id.
* ESP.getChipModel() returns model of the chip
* ESP.getChipCores() returns the core count.
* Example gives chip model, revision and core count.
* Read efuse for chipmodel
Co-authored-by: Martijn Scheepers <ms@SDNengineering.nl>
* Fix issue #3833, data parsing of Eddystone TLM data frame
Add Beacon scanner example to show usage of BLEEddystoneTLM class and BLEEddystoneURL class
Add EddystoneTLM beacon example
Add EddystoneURL beacon example
* Fix buffer size for .toString()
When connecting using transportTraits, the CA and client certificates are ignored after the initial _client->connect() is called. This is because on connect, WiFiClientSecure will call start_ssl_client with _CA_Cert and other cert options set to null unless setCACert, setCertificate etc. are called before connect. Running _transportTraits->verify after connect therefore does exactly nothing. It's easy to verify that this is the case by passing a CACert to HTTPClient with verbose logging enabled - the logs will say "WARNING: Use certificates for a more secure communication!" which is only present when both PSK and CA are null. This change fixes the issue.
Real DNS resolving timeout used by lwip library is 14[s] (7[s] for DNS1 + 7[s] for DNS2). Function WiFiGenericClass::hostByName() has timeout set to lower value (only 4[s]), so callback function may be called after this low timeout and it may overlappe stack memory used now by other function.
Fixes#3722
They are all broadly similar, all being based on the ESP32-D0WD core, but have
some subtle differences between variants around PSRAM inclusion and camera pin
mappings.
The ESP32CAM "unit" product (SKU: U007) has no PSRAM and maps the
"Pixel Data 0" (Y2 GPIO/OV2640 D2) camera pin to IO17 rather than IO32 as is
the case with most other M5Stack ESP32 camera devices.
The ESP32CAM also requires the "hmirror" and "vflip" camera configuration
bits setting in order to capture a true image.
The relevant M5Stack pin configuration documentation can be found here:
https://docs.m5stack.com/#/en/unit/esp32cam?id=pinmap
According to ESP-IDF API
dc14d027ce/docs/en/api-reference/peripherals/sdmmc_host.rst :
"To configure the bus width, set the width field of :cpp:class:`sdmmc_slot_config_t`. For example, to set 1-line mode:
sdmmc_slot_config_t slot = SDMMC_SLOT_CONFIG_DEFAULT();
slot.width = 1;
"
1. WiFiProv.ino sketch is added that allows arduino users to do provisioning via SoftAP or BLE. WiFi.beginProvision( ) API is designed for provisioning in Arduino.
2. In WiFiProv.h provisioning class is defined.
3. WiFiProv.cpp contains implementation for provisioning class.
4. README.md file is added which contains detail information for working.
The boundary delimiter (_STREAM_BOUNDARY) needs to be send before the
body part (_STREAM_PART) too follow RFC2046. This caused ffplay/ffmpeg
to fail to open the MJPEG stream.
* std::shared_ptr Memory Leak
clientSocketHande and _rxBuffer are std::shared_ptr, the stop() call was not correctly releasing them and the operator= had similar problems fix for #3679
* operator= second attempt
* operator= third time
WiFiClient.connected() was hanging thinking there was still a connection when the remote had already closed. The one-liner in this patch addresses recv() returning 0 and errno==128. I couldn't find the corresponding errno for 128 but its caught by the case statement which includes EPIPE, ENOTCONN, ECONNRESET and ECONNABORTED so I assume its one of those. Broken pipe maybe?
```c
[D][WiFiClient.cpp:511] connected(): Disconnected: RES: 0, ERR: 128
```
EDIT: added comment to reflect that recv() can set errno when it returns 0.
* Fix flush
flush should not flush the read buffer, it should wait till all output is drained from the write buffer.
* Update BluetoothSerial.cpp
Co-authored-by: Me No Dev <me-no-dev@users.noreply.github.com>
fixed the connected() function so that it only checks errno if recv returns a value of -1.
"in the even of an error, errno is set to indicate the error" --manpage
This fixes the ESP32 Webserver when dealing with a modern webserver with a slow SD card.
* Updated BLERemoteCharacteristic to exposre esp_gatt_auth_req_t parameter for readValue and writeValue.
* Updated BLERemoteCharacteristic/Descriptor to expose a setAuth method to allow tweaking the authentication request type for that remotecharacteristic/descriptor without the need to add auth on each read/write.
If two headers with overlapping names are added while replace == true, like in:
```cpp
http.addHeader("api_token", "pMXFOLpinQqajaRQJYMeWObg2XYmcX1");
http.addHeader("token", "1234");
```
then replacing went wrong. This is fixed with this PR.
This event name was missing in the list:
d5e2bb12ca/tools/sdk/include/esp32/esp_event_legacy.h (L43)
E.g., it was giving
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 24 - ETH_GOT_IP
When it should have been
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 24 - ETH_DISCONNECTED
Especially if the user wants to use the library as component in IDF,
there are some pitfalls while doing make menuconfig. One is this missing
dependency which will now fail with a better error message with a hint to
the user how to fix it.
refs #2154#3215
This changes all SPI functions that take data pointers which are
not modified so that the declaration is const. This allows them
to be used with const data (i.e. held in flash). No functional
changes are required.
The defnitions of spiWrite() and spiTransferBytes() in
esp-hal-spi.h/c have been updated to be consistent.
Tests:
- Build a simple sketch using SPI.writePattern() and
SPI.transferBytes() which uses const data and verify that the
attached device functions as expected.
I compiled the sample "WebServer -> HttpAdvancedAuth". But the right username and password can not login in. I found the file "Webserver.h" may be have some problem. So I fix it. Please check it.
* 20190916 - initial: support for Master mode, Pin and SSP
* 20190916 - initial: Add example app for Master mode
* 20190916 - initial: Force another build
* 20190916 - connect would use resolved address as preference and remove now redundant _remote_address
* 20190916 - rework set/reset/default pin logic
* 20190916 - cleanup: remove static vars, add/use constants, fix typos
* 20190916 - fix build issues and implement geoup events for status verification.
* 20190916 - remove extra lines,misc
* 20190916 - rework ESP_BT_GAP_DISC_RES_EVT, added SPP_DISCONNECTED bit for disconnect event. + timeout for disconnect()
* 20190916 - Small log change to improve log sequencing
* 20190916 - remove static from local vars
* 20190916 - Limited scope and duration for the scan, log device address during scan in info mode as it is very difficult to find out sometimes. Fixed get_name_from_eir() not resetting the name when called.
* 20190916 - break property for loop during scan when name matches.
* 20190916 - misc
* 20190916 - SPP_DISCONNECT state updates
* 20190916 - formatting, remove some strange syntax from initiator code
* 20190916 - Add comments to the example about connect(...) usage and timeouts
* 20190916 - fix disconnect() without timeout
* 20190916 - Add example comment to view BT address and name during connect(name)
* 20190916 - wording in example comments
* 20190916 - rework connect() and disconnect() methods to help with concurrency and more authoritative status returned back to caller. Automatic disconnect in connect() methods
* 20190916 - optimize code
* 20190916 - optimize code - more
* 20190916 - add timeout for pin set
* 20190916 - change scan mode to ESP_BT_SCAN_MODE_CONNECTABLE_DISCOVERABLE
* 20190916 - update example code slightly
* 20190916 - increase READY_TIMEOUT to 10 secs
* 20190916 - typo in example and move waitForConnect() to static area
* 20190916 - update example comments
* 20190916 - update example comments
* 20190916 - update example comments
* 20190916 - add new example to remove paired devices from ESP32
* 20190916 - correct typo in example
* 20190916 - update example comment, add remove_bond_device() method for convenience.
* 20190916 - reword example comment.
* 20190916 - rename remove_bond_device()
* 20190916 - rename removePairedDevice() to unpairDevice()
* 20190916 - code review changes
* 20190916 - fix return value in setup() od example
* Add Added unimplemented getCharacteristicsByHandle function
Defined in BLERemoteService.h
But, Not included in BLERemoteService.cpp
* Delete log output
Pretty sure this was a typo as the deinit doesn't actually allow for reinit if that is an ifndef. Changed in my local copy and can now deinit and reinit just fine. Also, not sure why we are checking for the architecture here. Just curious.
