This patch adds a new RAW_FLAGS_HDRINCL flag to the raw core
implementation. When this flag is set on a RAW PCB, the raw send
routines expect the caller to supply an IP header for the given
packet, and will use that IP header instead of prepending one to
the packet themselves.
This feature allows the IP_HDRINCL socket option to be implemented
in higher layers with no further effort. Even thoguh that option is
traditionally supported for IPv4 sockets only (e.g., see RFC 3542
Sec. 3), the RAW_FLAGS_HDRINCL flag supports both IPv4 and IPv6, as
much of the lower-level infrastructure was already in place anyway.
Similar to the core UDP API, the new function may be used to implement
IPV6_PKTINFO (RFC 3542 Sec. 4), for example. This patch makes no
further functional changes; it merely moves code around a bit.
The support for connecting raw sockets is extended to match the
support for UDP sockets, while keeping the current API unchanged:
- for connected sockets, filter incoming packets on source address;
- use a flag to indicate whether a socket is connected, at no extra
memory cost; the application may check this flag if needed;
- added raw_disconnect(), which so far existed in documentation only.
The caller of tcp_listen_with_backlog_and_err() usually check if the return
pcb is NULL before checking the err reason. I think the commit adding
tcp_listen_with_backlog_and_err() accidently change the behavior, Fix it.
Fixes: 98fc82fa71 ("added function tcp_listen_with_backlog_and_err() to get the error reason when listening fails")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
If MLD support is enabled, each locally assigned IPv6 address in the
appropriate state must be a member of the solicited-node multicast
group corresponding to that address. Ensure that this is always the
case by (re-)deciding on the membership upon every address state
change. By doing so, this patch enforces that user-initiated state
changes to addresses (e.g., deletion) never cause a desynchronization
with the corresponding solicited-node multicast group membership,
thereby making such user-initiated state changes simpler and safer.
The code in the for loop checks tmp_group->next == group, so current code
actually checks from the 3rd entry in the linked groups list. Fix it.
Fixes: 5c1dd6a4c6 ("Optimization in igmp_remove_group() pointed out by Axel Lin")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
This commit adds support for responding to a zero-window probe when
the refused_data pointer is set
A zero-window probe is a data segment received when rcv_ann_wnd
is 0. This corrects a standards violation where LwIP would not
respond to a zero-window probe with its current ACK value (RCV.NXT)
when it has refused data, thus leading to the probing TCP closing
out the connection
lwIP produces a TCP Initial Sequence Number (ISN) for each new TCP
connection. The current algorithm is simple and predictable however.
The result is that lwIP TCP connections may be the target of TCP
spoofing attacks. The problem of such attacks is well known, and a
recommended ISN generation algorithm is standardized in RFC 6528.
This algorithm requires a high-resolution timer and cryptographic
hashing function, though. The implementation (or best-effort
approximation) of both of these aspects is well beyond the scope of
lwIP itself.
For that reason, this patch adds LWIP_HOOK_TCP_ISN, a hook that
allows each platform to implement its own ISN generation using
locally available means. The hook provides full flexibility, in
that the hook may generate anything from a simple random number
(by being set to LWIP_RAND()) to a full RFC 6528 implementation.
Implementation note:
Users of the hook would typically declare the function prototype of
the hook function in arch/cc.h, as this is the last place where such
prototypes can be supplied. However, at that point, the ip_addr_t
type has not yet been defined. For that reason, this patch removes
the leading underscore from "struct _ip_addr", so that a prototype
of the hook function can use "struct ip_addr" instead of "ip_addr_t".
Signed-off-by: sg <goldsimon@gmx.de>
Fix below build error when LWIP_ND6_RDNSS_MAX_DNS_SERVERS == 0
../../../../lwip/src/core/ipv6/nd6.c: In function ‘nd6_input’:
../../../../lwip/src/core/ipv6/nd6.c:400:10: error: unused variable ‘rdnss_server_idx’ [-Werror=unused-variable]
u8_t rdnss_server_idx = 0;
^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
../Common.mk:93: recipe for target 'nd6.o' failed
make: *** [nd6.o] Error 1
Fixes: 6b1950ec24 ("nd6: add support for RDNSS option (as per RFC 6106)")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Previously, ethip6 and lowpan6 each had their own copy of code that
used internal nd6 data structures to decide whether to send a packet
on the local link right away, or queue it while nd6 performed local
address resolution. This patch moves that code into nd6, thereby
eliminating all remaining cases of external access to internal nd6
data structures, as well as the need to expose two specific nd6
functions.
As a side effect, the patch effectively fixes two bugs in the lowpan6
code that were already fixed in the ethip6 code.
This patch rearranges the code division between nd6.c and ip6.c such
that the latter does not need to access ND6-internal data structures
(specifically, "default_router_list") directly anymore.
The new function, while currently not used internally, allows external
code to clear the ND destination cache in the case that it may have
become inconsistent with the current situation, for example as the
result of a change of locally assigned addresses, or a change in
routing tables implemented through the LWIP_HOOK_ND6_GET_GW hook.
On failure, nd6_get_next_hop_entry() returns an ERR_ type negative
error code. ethip6_output() erroneously assumed that that error would
always be ERR_MEM, even though it may also be ERR_RTE in practice.
With this patch, ethip6_output() simply forwards the returned error.