First calculate and sum TLS overhead when altcp_mbedtls_write() is called.
Then take care of it when calling application sent callback. Give reveived
len from inner_conn, minus calculated overhead.
According to mbedTLS source code and documentation, calls to
`mbedtls_ssl_conf_session_cache` and `mbedtls_ssl_conf_session_tickets_cb`
are only available if mbedTLS is configured for server mode (ie. MBEDTLS_SSL_SRV_C
is defined). This cannot be used on client mode to resume a previous session.
To allow session reuse in client mode, application must save session parameters
(including tickets provided by the server if any) after successfull connection
and restore them before attemting to reconnect. Since `alctp_close()` free the
structure, it cannot be used to store the required information.
So, two new API were added, directly wrapped to mbedTLS functions, allow application
to do that by itself.
Also added full declaration of `struct altcp_tls_session` in altcp_tls.h to allow
easier usage in application when using mbedTLS port.
In some noisy WiFi environment, it may be necessary to increase this value to
300ms to accomodate WiFi latencies which may result in less than the required
250ms between two probe frames received by the Apple BCT application.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
- Count tiebreaking loss in num_conflicts to include them in rate limit detection
- Restart probing using mdns_resp_restart allowing rate limiting for those cases
This ensure rate limiting is well activated during Apple Bonjour Conformance Tests.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
This allow Apple Bonjour Conformance Test to not fail with the following tests:
- DISTRIBUTED DUPLICATE SUPPRESSION
- MULTIPLE QUESTIONS - DISTRIBUTED DUPLICATE SUPPRESSION
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
TXT records isn't required to be unique in network, so it shouldn't be
included in probe packets.
Additionnaly, when TXT record is present, the Bonjour Conformance Test
from Apple Inc. always fail because generated probe nevert have TXT record.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Called with `MDNS_INITIAL_PROBE_DELAY_MS` or `MDNS_PROBE_DELAY_MS` according to
needs.
When `mdns_resp_restart_delay()` called by `mdns_resp_rename_(netif|service)()`
functions, it is assumed this is because a conflict. So we should not use
`MDNS_INITIAL_PROBE_DELAY_MS` because the Bonjour Conformance Test will
complain like this:
```
START (PROBING)
NOTICE 16:40:09.501911: conflicting probe:
smarTrEMotE-f8d0a4.Local.
ERROR 16:40:09.607288: Device did not provide a sufficient time gap between receiving a conflicting probe and reprobing.
ERROR 16:40:09.607333: expected_time_gap=237,actual_time_gap=105
```
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
- Send service slot index to the mdns result function. In case of conflict, the user
will have to remove the service or rename it.
- Break after hostname conflict in order to managed it first, and managed service name
conflict after.
- Provide a function to get the TXT userdata for a service (allowing app to match with
its own data).
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
When more than one service (just 2) need to be probed for conflict, generation
of the probe packet fail because pbuf is too small!
So OUTPACKET_SIZE renamed to MDNS_OUTPUT_PACKET_SIZE and moved to mdns_opts.h
to allow configuration. Default configuration raise it to 1450 to have enough
space when MDNS_MAX_SERVICES > 1 else it remain 512.
Extract from RFC 6762, chapter 17, Multicast DNS Message Size:
The 1987 DNS specification [RFC1035] restricts DNS messages carried
by UDP to no more than 512 bytes (not counting the IP or UDP
headers). For UDP packets carried over the wide-area Internet in
1987, this was appropriate. For link-local multicast packets on
today's networks, there is no reason to retain this restriction.
Given that the packets are by definition link-local, there are no
Path MTU issues to consider.
Multicast DNS messages carried by UDP may be up to the IP MTU of the
physical interface, less the space required for the IP header (20
bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
* Include lwip/inet.h in some unit tests and apps
* Since they use htons() and pals.
* test/unit/api/test_sockets.c:
* write() could be declared by external socket headers
* Call lwip_write() instead.
* Code expects fcntl() to return 6
* But O_RDWR could have another value if external
socket headers are present
* Replace 6 by O_RDWR.
* apps/tftp/tftp.c:
* recv() could be declared by external socket headers
* Rename it to tftp_recv()
If client reception buffer is bigger than the first frame we receive, the first packet test
will always fail for the second one if it is shorter the the diffence between reception
buffer size and first frame length.
For example, if we receive a PUBLISH message with length = 1517 (payload len = 1514 +
header len = 3), this result in total message length of 1517.
altcp_tls will send MQTT client frame up to 1516 bytes max. This result to PUBLISH
message splitted in two frame: first is 1516 bytes, the second of 1 bytes.
If MQTT_VAR_HEADER_BUFFER_LEN is 1520 (1516 + 4 bytes for stored fixed header), the
second frame of 1 bytes is considered as first publish frame because
client->msg_idx (1517) < MQTT_VAR_HEADER_BUFFER_LEN (1520).
This result in disconnection AND application callback never called for the end of the
payload.
The fix will check `(client->msg_idx - (fixed_hdr_len + length)) == 0` which can be
only true for the first frame of a message.
Below logs showing the bug:
```
April 3rd 2019, 23:14:05.459 lwip_dbg mqtt_parse_incoming: Remaining length after fixed header: 1514
April 3rd 2019, 23:14:05.460 lwip_dbg mqtt_parse_incoming: msg_idx: 1516, cpy_len: 1513, remaining 1
April 3rd 2019, 23:14:05.460 lwip_dbg mqtt_incomming_publish: Received message with QoS 1 at topic: v2/inte...
April 3rd 2019, 23:14:05.461 lwip_dbg mqtt_parse_incoming: Remaining length after fixed header: 1514
April 3rd 2019, 23:14:05.461 lwip_dbg mqtt_parse_incoming: msg_idx: 1517, cpy_len: 1, remaining 0
April 3rd 2019, 23:14:05.461 lwip_dbg mqtt_message_received: Received short PUBLISH packet
```
Replace '\n' with '<br>', as this allows doxygen to understand reference
names followed by newline. For some cases just drop the newline if it's
not required.
Doxygen 1.8.15 doesn't like if the name of reference is followed by
anything else than (selected?) punctuation or whitespace.
bug #56004
