- When the "_services._dns_sd._udp.local" meta-query is received, an
enumeration of services types is now returned (e.g. "_http._tcp.local")
instead of an enumeration of instances (e.g.
"MyService._http._tcp.local"). This is consistent with Section 9 of the
RFC.
- When a response is sent, the response records are now properly
partitioned as either answers or additional records. Only response
records that were explicitly requested as a result of the questions
should be treated as answers. This is consistent with Section 12 of the
RFC.
- The "MDNSResponder::advertiseServices()" method has been removed as it
was declared as "private" and is no longer being called. This method
was sending a response on multiple interfaces when available, but this
wasn't really necessary since the interface from which the request was
received that caused it to be invoked is known.
MDNSResponder::advertiseServices() was transmitting all service adverts
on the same interface (AP) rather than once on STA and once on AP. Fix
this simple mistake.
With this change, both "ping esp8266.local" and "avahi-browse -a" see
the ESP8266 from a test Linux PC, on both AP and STA interfaces (where
applicable), with the ESP8266 running mDNS_Web_Server.ino modified for
each of AP-only, STA-only and AP+STA modes.
Note that no attempt has been made to make MDNSResponder::queryService()
operate correctly with multiple interfaces, either in this commit or the
commit this commit fixes.
Fixes: a546d64e07d2 ("ESP8266mDNS: support AP and STA interfaces at once")
Fixes#3101
- update ssl_client_new signature
- add max fragment length negotiation support (hardcoded to 4096 bytes)
- build axtls with -f{function,data}-sections, ~1k less DRAM usage,
~3k less flash
- strip prefix from build paths in debug symbols
* minimum changes for libraries to compile with lwip2
* add WiFiClient::availableForWrite() (similar to Serial::) which indicates how much data can be sent without buffering
This is a simple implementation of an LLMNR responder for the ESP8266
Arduino package. Only support for advertizing a single hostname is
currently implemented.
LLMNR is a very similar protocol to MDNS. The primary practical
difference is that Windows systems (at least Windows 7 and later;
perhaps earlier) support the protocol out-of-the-box, whereas additional
software is required to support MDNS. However, Linux support is
currently more complex, and MacOS X support appears non-existent.
I know it was in the body, but so many users have had questions and found esp8266.com late in their searches for answers.... really don't know, just making people happy....
- add probe request event handler (#2910)
- update WiFi events handling example to use new handler
Pro tip: replace blinking LED with ‘analogWrite’ and connect the pin to
a loudspeaker (or use a servo to hit a bell). Get notified when someone
with a smartphone wanders around your country house.
- Update SDK header files and libraries to SDK 2.0.0 plus 2.0.0_16_08_09
patch
- Remove mem_manager.o from libmain.a (replaced with umm_malloc)
- Disable switch from DIO to QIO mode for certain flash chips (saves
IRAM space)
- Add user_rf_cal_sector_set; it points to rf_init_data sector.
- Change the way rf_init_data is spoofed.
This is now done by wrapping spi_flash_read and returning the data we
need during startup sequence.
- Place lwip library into flash using linker script instead of section
attributes (saves IRAM space)
* Suppressed -Wunused-parameter and -Wunused-function by casting to void unused identifiers.
* Explicit initialization of all fields to suppress -Wmissing-field-initializers.
* Fixed signed/unsigned integer comparison.
* memset initialization of structs.
* More -Wunused-parameter fixes.
* Fixed libb64 decoder.
Libb64 decoder works when "char" type is signed. In esp8266 xtensa gcc "char" is unsigned, so libb64 decoder does not work. In the implementation file I replaced "char" to "int8_t" and created function wrappers in order to keep existing interface.
* For style consistency.
* Prevent divide by zero error causing code to crash
As per the issue at #2491, there is a divide by error issue resulting from the specification of 0 as the frequency. This does not appear to affect the AVR implementation, but it crashes on ESP8266s. I have merely removed the division if the frequency is zero, which appears to be giving the expected results (no tone), without any code crashes.
To test, simply load the toneMelody sketch included with the Arduino IDE (Examples -> 02. Digital -> toneMelody) and change the piezo to something else if you need to. On the Witty module used to test this, I could also tell by the wifi led blinking every time the code crashed as the ESP8266 immediately rebooted.
* Use noTone when frequency is zero
When a frequency of zero is given to tone(), instead call noTone() and exit. Placed after some of the initialisation stuff to ensure the pin is mapped as a output, etc. Tested as functional against a Node MCU 1.0 board and the toneMelody example sketch, using GPIO5 (pin D1).
* Errant tab in formatting
* Rest of tabs that crept in from web editor
Defaulted to tabs and 8 indent :sigh:
Bind the UDP connection to IP_ADDR_ANY rather than a specific interface
IP, so that it can receive queries from all interfaces at once.
When processing a query, detect which interface it was received on, and
pass this information to the reply code. Set the IP multicast interface
before each transmission, so that we can route each packet to a
different interface if required. These changes enable the code to
respond correctly on both AP and STA interfaces at once. The original
code only worked correctly for the STA interface if both were enabled.
When advertizing all services, do it on both AP and STA interfaces if
they're both enabled.
Provide an API for the application to notify the MDNS code if the AP
configuration changes (enabled, disabled, IP changed). Ideally, the WiFi
core would provide an event callback for this purpose, as it does for
STA changes, but it does not appear to, so the application must provide
this information.
Manually specifying the AP IP isn't required; the next change will modify
the MDNS code to correctly handle any combination of AP and STA modes, and
correctly respond to requests on all active interfaces.
This reverts commit b682d597c5f100ac71e74997880d95404200d759.
For downcasting, static_cast<> is the appropriate cast. Using reinterpret_cast<> will NOT correctly adjust the `this` pointer and dereferencing such a value is undefined by spec. See [expr.reinterpret.cast]p7 for the relevant passage. The only legal use of this pointer is in another set of reinterpret_cast expressions that either land it into a numeric value, or back to the original type.
Many people have problems with using ESP8266 as WiFi-client due to
none of the examples mentioning that you should use WIFI_STA if you
only want the ESP8266 to act as a WiFi-client. Many WiFi-devices
will randomly try to connect to the ESP8266 if used as STA+AP and
complain about not being able to access the Internet or other devices
on the network.
About the simplest change possible, just delete two characters and add one. The PUT(String) convenience method called the full POST method instead of calling the PUT method
