* LWIP_MARK_TCPIP_THREAD moved to include/lwip/sys.h
* Unix port macro definitions moved to sys_arch.h
* LWIP_MARK_TCPIP_THREAD
* LOCK_TCPIP_CORE
* UNLOCK_TCPIP_CORE
(goldsimon@gmx.de: fixed unix Makefile build and win32 build)
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
In timeouts.c commit 7d1c26cc0c replaced
timeout for AUTOIP with a timeout for ACD, however the value of
LWIP_NUM_SYS_TIMEOUT_INTERNAL was not updated and still counts
LWIP_AUTOIP instead of LWIP_ACD. If user has AUTOIP disabled (or not
explicitly enabled) and DHCP enabled, then ACD gets automatically
enabled too. In this case there will be one timeout too little for lwIP
and first TCP packet received causes an assertion.
Also add LWIP_IPV6_DHCP6 to the value of LWIP_NUM_SYS_TIMEOUT_INTERNAL,
as it was also not accounted for.
This reuses the member 'int socket' by making it a union containing
both int and void pointer.
See bug #56593.
Signed-off-by: Simon Goldschmidt <goldsimon@gmx.de>
Suggested-by: Wilfred <wilfrednilsen@hotmail.com>
The err field is removed from struct lwip_sock since commit e0a2472706
("netconn/sockets: remove fatal error handling, fix asynchronous error handling, ensure data before RST can be received")
sock_set_errno() simply calls set_errno() now, so use set_errno() instead.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Dirk Ziegelmeier <dziegelmeier@de.pepperl-fuchs.com>
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
```
When using the MEMP_MEM_MALLOC option, memp_malloc() can not be relied on to
limit the number of allocations allowed for each MEMP queue, as the ND6 code
had been. This caused the ND6 queue to keep growing until the heap allocation
failed when using the MEMP_MEM_MALLOC option. So add an explicit queue size
check in ND6.
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
