This moves the write_offset variable from struct netconn to struct api_msg
This optimizes the storage by only having the space claimed when it is
needed (during a netconn_write_partly() call) and not throughout the
lifetime of the netconn
This also reduces code space/execution by not having to separately manage
clearing/checking write_offset from the current_msg pointer
Lastly, we also save execution by using msg.w.offset as the output
rather than marshaling the result to msg.w.len. Previously, len was used
as input length of dataptr and output for the write operation.
netconn_write_partly() also has access to msg.w.offset, so we can use
that
So far, the UDP core module implemented only IPv4 multicast support.
This patch extends the module with the features necessary for socket
layers on top to implement IPv6 multicast support as well:
o If a UDP PCB is bound to an IPv6 multicast address, a unicast source
address is selected and used to send the packet instead, as is
required (and was the case for IPv4 multicast already).
o Unlike IPv4's IP_MULTICAST_IF socket option, which takes a source
IPv4 address, the IPV6_MULTICAST_IF socket option (from RFC 3493)
takes an interface identifier to denote the interface to use for
outgoing multicast-destined packets. A new pair of UDP PCB API
calls, udp_[gs]et_multicast_netif_index(), are added to support
this. The new definition "NETIF_NO_INDEX" may be used to indicate
that lwIP should pick an interface instead.
IPv4 socket implementations may now also choose to map the given
source address to an interface index immediately and use the new
facility instead of the old udp_[gs]et_multicast_netif_addr() one.
A side effect of limiting the old facility to IPv4 is that for dual-
stack configurations with multicast support, the UDP PCB size is
reduced by (up to) 16 bytes.
o For configurations that enable loopback interface support, the IPv6
code now also supports multicast loopback (IPV6_MULTICAST_LOOP).
o The LWIP_MULTICAST_TX_OPTIONS opt.h setting now covers both IPv4
and IPv6, and as such is no longer strictly linked to IGMP. It is
therefore placed in its own lwIP options subgroup in opt.h.
The IPV6_MULTICAST_HOPS socket option can already be implemented using
the existing IP_MULTICAST_TTL support, and thus requires no additional
changes. Overall, this patch should not break any existing code.
This commit adds support in if_indextoname() to return ENXIO when
no interface is found. This conforms to the Open Group/RFC 3493
specification
In order to leverage errno set support, the set_errno macro from
sockets.c was moved to sockets_priv.h
This commit introduces a sockets_priv.h header for socket API internal
implementations intended to be used by sockets API C files, but not
applications
This commit moves struct lwip_setgetsockopt_data to the private header
because this is not part of the public sockets API, but needs to be
shared between sockets.c and memp.c
This header lays ground work for sharing other internal sockets types
/macros between API files (sockets.c and if_api.c)
This fixes the following build failure with MSVC 2013:
sockets.c(323): warning C4242: '=' : conversion from 'const u32_t' to 'u8_t', possible loss of data
This casts sin6_scope_id to a u8_t before calling ip6_addr_set_zone()
Couple of more cleanups for task #14314 involving includes:
1) if.h name should match if_api.c due to LwIP convention and history.
Standard if.h include can be used with compatibility header in
posix/net/if.h
2) API header (if.h) should not be included in core code. This include
has been eliminated by moving the definition of IF_NAMESIZE to
netif.h as NETIF_NAMESIZE. This is now the canonical definition
and IF_NAMESIZE just maps to it to provide the standard type
This patch adds full support for IPv6 address scopes, thereby aiming
to be compliant with IPv6 standards in general and RFC 4007 in
particular. The high-level summary is that link-local addresses are
now meaningful only in the context of their own link, guaranteeing
full isolation between links (and their addresses) in this respect.
This isolation even allows multiple interfaces to have the same
link-local addresses locally assigned.
The implementation achieves this by extending the lwIP IPv6 address
structure with a zone field that, for addresses that have a scope,
carries the scope's zone in which that address has meaning. The zone
maps to one or more interfaces. By default, lwIP uses a policy that
provides a 1:1 mapping between links and interfaces, and considers
all other addresses unscoped, corresponding to the default policy
sketched in RFC 4007 Sec. 6. The implementation allows for replacing
the default policy with a custom policy if desired, though.
The lwIP core implementation has been changed to provide somewhat of
a balance between correctness and efficiency on on side, and backward
compatibility on the other. In particular, while the application would
ideally always provide a zone for a scoped address, putting this in as
a requirement would likely break many applications. Instead, the API
accepts both "properly zoned" IPv6 addresses and addresses that, while
scoped, "lack" a zone. lwIP will try to add a zone as soon as possible
for efficiency reasons, in particular from TCP/UDP/RAW PCB bind and
connect calls, but this may fail, and sendto calls may bypass that
anyway. Ultimately, a zone is always added when an IP packet is sent
when needed, because the link-layer lwIP code (and ND6 in particualar)
requires that all addresses be properly zoned for correctness: for
example, to provide isolation between links in the ND6 destination
cache. All this applies to packet output only, because on packet
input, all scoped addresses will be given a zone automatically.
It is also worth remarking that on output, no attempt is made to stop
outgoing packets with addresses for a zone not matching the outgoing
interface. However, unless the application explicitly provides
addresses that will result in such zone violations, the core API
implementation (and the IPv6 routing algorithm in particular) itself
will never take decisions that result in zone violations itself.
This patch adds a new header file, ip6_zone.h, which contains comments
that explain several implementation aspects in a bit more detail.
For now, it is possible to disable scope support by changing the new
LWIP_IPV6_SCOPES configuration option. For users of the core API, it
is important to note that scoped addresses that are locally assigned
to a netif must always have a zone set; the standard netif address
assignment functions always do this on behalf of the caller, though.
Also, core API users will want to enable LWIP_IPV6_SCOPES_DEBUG at
least initially when upgrading, to ensure that all addresses are
properly initialized.
This renames if.c to if_api.c in order to avoid using a common source
file name which may collide with other source files from non-LwIP
projects. See discussion in task #14314
This corrects a case in lwip_netconn_do_writemore() where if a
non-blocking socket receives ERR_MEM in a call to tcp_write(), it would
return ERR_MEM, which would result in ENOMEM coming out of the socket
layer
This case can be gracefully handled by returning ERR_WOULDBLOCK since the
socket is already marked as no longer writable and sent_tcp/poll_tcp will
mark the socket as writable again based on available buffer space
This is very similiar to how ERR_MEM is resolved for blocking sockets
It is better to present correct IP types in netconn API.
Netconn API now accepts IPv6 mapped IPv4 addresses as well as IPv6 and IPv4 in send(), bind() and connect(), but does NOT map IPv4 to IPv6 mapped IPv4 in getaddr() and receive() functions.
IPv6 netconns are created as IPADDR_TYPE_ANY raw/udp/tcp PCBs internally
bind, connect and sendto now accept IPv6 mapped IPv4 addresses or IPv4 addresses as argument
getaddr and receive functions now return IPv6 mapped IPv4 addresses instead of IPv4 addresses
This behavior is close to BSD socket API
Slightly improve readability by testing apiflags with NETCONN_DONTBLOCK.
Also remove an empty else clause.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
This also fixes build error in non-debug build because err_strerr is
guarded by LWIP_DEBUG.
Fixes: a1c0a0185b ("bug #48823: posix errors should be removed from arch.h (to new file 'lwip/errno.h'))"
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Let lwip use functions/macros prefixed by lwip_ internally to avoid naming clashes with external #includes.
Remove over-complicated #define handling in def.h
Make functions easier to override in cc.h. The following is sufficient now (no more LWIP_PLATFORM_BYTESWAP):
#define lwip_htons(x) <your_htons>
#define lwip_htonl(x) <your_htonl>
Use memset to zero the allocated memory rather than explicitly init each field.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: goldsimon <goldsimon@gmx.de>
Simon and I think it can be removed - the receive window handling get a little less precise, but that should be OK for a lightweight stack.
Receive window is now updated with the whole pbuf size (instead of only count of read bytes from socket) as soon as socket implementation gets a pbuf from netconn layer.
Work on bug #47512: MPU_COMPATIBLE may fail on empty pool (still not finished)
This commit optimizes the sendmsg UDP pbuf chain creation by not
allocating/freeing a netbuf per io vector and instead building a pbuf
chain directly in the sockets layer
Same as in my last commits - this avoids errors in lwIP code where ip addresses are dereferenced (e.g. for IP type checking) without handling thinking about NULL pointers.
This commit adds support to the sockets and netconn layer to update the
backlog by calling listen when the netconn is already in the listen state.
When backlog is not enabled, the call returns successfully
This commit also introduces a macro for setting the backlog value that
prevents a 0 sized (invalid) backlog
Fix a bug in the socket API's ioctl for FIONREAD. If the socket's
lastdata was assigned the function returned without error but did not
update the argument pointer.
The cast type for argp was also changed to int to conform with the
other SO_RCVBUF handling.
This makes a couple of simple re-arrangements in lwip_selscan() that
should improve performance in the following ways:
1) The old code linearly walked all sockets to maxfd regardless of
whether they were set in the fd set. The process involved
acquiring sys arch protect, looking up the socket, and then
checking if the socket was present in any of the fd sets. On
systems with lots of sockets and a heavy SYS_ARCH_PROTECT
infrastructure (a mutex) this can result in a lot of extra work.
Now we skip this process for any fd that is not in the input sets
2) If the socket from tryget_socket() is NULL we no longer continue
and compare the input fd sets with a zeroed out set of events
3) We no longer need to zero out our event sets because they are
only accessed when tryget_socket() is successful
lwip_selscan() is called at most once per select call and sometimes up to three times
This fixes a bug in close when LWIP_SO_SNDTIMEO is enabled, but
the option is not in use on the socket
A simple mis-typed comparison against zero would cause the close_timeout
to get set to zero if conn->send_timeout was 0
The intended check was to over-ride the default close timeout if a
send timeout had been specified via SO_SNDTIMEO
tcpip_callback_with_block() can fail with ERR_MEM or ERR_VAL, and in the
error paths the code does not post the msg to the mailbox thus the
sys_sem_wait() call might wait forever. Fix it by testing return value of
tcpip_callback() and return error immediately.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
The TCPIP_APIMSG_ACK will call NETCONN_SET_SAFE_ERR for both
LWIP_TCPIP_CORE_LOCKING and !LWIP_TCPIP_CORE_LOCKING cases.
So remove superfluous NETCONN_SET_SAFE_ERR call before TCPIP_APIMSG_ACK.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Adds sendmsg implementation for TCP and UDP sockets. Control messages
are not supported at this point, but could be added in the future
https://savannah.nongnu.org/bugs/?44805
Change-Id: Iddb287fd4b693f7563f8c923f76785cdde782d2f
The overall lwIP design on data flows (netif,udp,tcp) is to use a user
defined callback to get data from stack and a static function to send
data to stack, which makes perfect sense. The SIO port was an exception,
the PPP stack never really used the SIO port by only using the
sio_send() function (and the ignominious sio_read_abort() function a
while back).
The way the SIO port is currently designed adds a tight coupling between
the lwIP port and the user code if the user need to do specific user
code if the current uart used is the PPPoS uart, which is not nice,
especially because all the lwIP stack is quite clean at this subject.
While we are at stabilizing the PPP API, change this behavior before
it's too late by replacing the static sio_write() calls to a user
defined callback.
This commit address two issues with sockaddr struct implementations for
IPv6:
1) struct sockaddr_in6 should have 32-bit unsigned field sin6_scope_id
as specified in Section 3.4 of RFC 3493 (Basic Socket Interface
Extensions for IPv6)
2) struct sockaddr is not extended in IPv6 to contain space for
struct sockaddr_in6. Applications should be using struct
sockaddr_storage when needing generic storage. This removes the
extra bytes added when LWIP_IPV6 is defined
Replaced ip4_addr_t to ip_addr_t in pppapi_pppol2tp_create() prototype,
now binding to UDPv6 or UDPv4 depending on the passed ip_addr_t type.
Removed pppol2tp_create_ip6() and pppapi_pppol2tp_create_ip6().
ip_addr_t is used for all generic IP addresses for the API, ip(4/6)_addr_t are only used internally or when initializing netifs or when calling version-related functions
Follow-up of the #44565 bug fix, renamed the misnamed
PPP_INPROC_MULTITHREADED to PPP_INPROC_IRQ_SAFE because it is
IRQ safe but not thread safe.
Updated PPP documentation which now clearly state when and how
this feature can be used.
!NO_SYS users may now use as well the TCPIP API for PPPoS input data,
this way they can disable PPP_INPROC_MULTITHREADED and run pppos_input()
inside the lwIP thread, which fixes, at least for them, all the
threading issues related to PPP_INPROC_MULTITHREADED.
Makes it clear we are initiating the PPP session with ppp_connect
(i.e. acting as a PPP client) so there is no confusion possible
between ppp_connect and ppp_listen.
