If we do not receive last ACK when the connection is tore down,
then do not wait forever as that would eat all the resources in
the network stack. So when we enter the LAST_ACK state, we setup
a timer that will unref the connection if the last ACK is not
received.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The commit "net: tcp: Handle retransmitted packets from peer"
introduced over 80 character line that was missed in review.
Fixing it now.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
When we receive a packet with the sequence we already seen (and
processed), the most likely cause of it is that our ACK was lost,
and peer has to retransmit that packet. Then, we should just ACK
it, because otherwise peer will retransmit it again and again,
falling into exponential backoff and hosing the entire TCP
connection.
This makes changes to send_ack(), adding a flag to force sending
an ACK regardless of its cached status, and remove inline modifier,
as the function is big and called from many places.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
We must check if we receive RST in any of the TCP states.
If we do not do this, then the net_context might leak as it
would never be released in some of the states. Receiving RST
in any TCP state is not described in TCP state diagram but is
described in RFC 793 which says in chapter "Reset Processing"
that system "...aborts the connection and advises the user and
goes to the CLOSED state."
We need to also validate the received RST and accept only those
TCP reset packets that contain valid sequence number.
The validate_state_transitions() function is also changed to
accept CLOSED state transition from various other states.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
When we send TCP data segment, we need to set the length
of the application data by calling net_pkt_set_appdatalen().
This is done so that sequence number can be properly
advanced when we receive ACK to that pending packet.
Signed-off-by: xiaorui hu <xiaorui.hu@linaro.org>
Convert code to use u{8,16,32,64}_t and s{8,16,32,64}_t instead of C99
integer types.
Jira: ZEP-2051
Change-Id: I4ec03eb2183d59ef86ea2c20d956e5d272656837
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We need to set the connect_cb for the context before sending SYN packet.
This is required if we have a loopback connection in which case everything
is happening more or less synchronously and the connect_cb would not be
called in this case because its value would still be null.
For remote network connections this patch makes no difference.
Change-Id: Id7f837cd9e81cd79c4666c98cae84f6cb1a77af0
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
We must not let ACK timer to run if we have already cancelled it.
So keep track that the timer is cancelled and refuse to run it
if it was indeed cancelled. The reason why the timer might be run
in this case is because the timer might be scheduled to be triggered
after which one cannot cancel it.
Change-Id: I1c8b8cee72bc7a644e02db154d9d009b8d98ade2
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The local port was set to 0 for IPv6 when registering
the connection handler. For IPv4, the code was not setting
the port in local_addr struct.
Change-Id: I82f0c08641a94d75d255ac306eca7bec6c332fba
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Most of these macros are not exactly exposing a buffer, but a specific
header pointer (ipv6, ivp4, ethernet and so on), so it relevant to
rename them accordingly.
Change-Id: I66e32f7c3f2bc75994befb28d823e24299a53f5c
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
- net_pkt becomes a stand-alone structure with network packet meta
information.
- network packet data is still managed through net_buf, mostly named
'frag'.
- net_pkt memory management is done through k_mem_slab
- function got introduced or relevantly renamed to target eithe net_pkt
or net_buf fragments.
- net_buf's sent_list ends up in net_pkt now, and thus helps to save
memory when TCP is enabled.
Change-Id: Ibd5c17df4f75891dec79db723a4c9fc704eb843d
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
There have been long lasting confusion between net_buf and net_nbuf.
While the first is actually a buffer, the second one is not. It's a
network buffer descriptor. More precisely it provides meta data about a
network packet, and holds the chain of buffer fragments made of net_buf.
Thus renaming net_nbuf to net_pkt and all names around it as well
(function, Kconfig option, ..).
Though net_pkt if the new name, it still inherit its logic from net_buf.
'
This patch is the first of a serie that will separate completely net_pkt
from net_buf.
Change-Id: Iecb32d2a0d8f4647692e5328e54b5c35454194cd
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Following flow does not work:
net_context_get
net_context_bind
..
..
net_context_put
net_context_get
net_context_bind
At instance of call to net_context_bind, conn_handler
is not NULL and returns with EISCONN.
This patch sets conn_handler to NULL in net_context_unref
Change-Id: I56a50839101b22161644b3cd7c5f510fa1abae3e
Signed-off-by: Mitul Shah <mitul.a.shah@intel.com>
We incorrectly changed the state from FIN_WAIT_1 to CLOSE_WAIT.
This caused ACK be sent in CLOSE_WAIT state when the connection
was closed by peer. Sending ACK in this state is not allowed
according to RFC. The connection was still closed but slightly
wrong way.
Jira: ZEP-1961
Change-Id: Ie4aa6818128d4190230b679e26ac9630c7d45d69
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If the bind port is set to 0, then return the real bind port and
show it in the debug print.
Change-Id: If75b52bdacfc916329222d0d9e8aa4669e7a7160
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This is part of a patch series to decouple TCP/IP offload, which
currently occurs at the transport layer (L4), from the data link
layer (L2).
- Rename struct net_l2_offload_ip to struct net_offload
- Rename struct field offload_ip to just offload
- Rename include/net/offload_ip.h -> include/net/net_offload.h
Change-Id: I3cd891c2b13e0e8f3ad1c66264f90b5031ae17c2
Signed-off-by: Gil Pitney <gil.pitney@linaro.org>
This is part of a patch series to decouple TCP/IP offload, which
currently occurs at the transport layer (L4), from the data link
layer (L2).
This patch simply renames the NET_L2_OFFLOAD_IP Kconfig variable
to NET_OFFLOAD.
Change-Id: Ic8b1d004cbac09b7c636475aaed75b0a31e4be1c
Signed-off-by: Gil Pitney <gil.pitney@linaro.org>
It's not enough to know just network address and port number to
disambiguate an endpoint, protocol (TCP vs UDP, etc.) should be
known too. Without this patch, there is a confusing output from
e.g. echo_server if both TCP and UDP is enabled.
Jira: ZEP-1086
Change-Id: I247a2dfc87df634ceac3b8733d7349b1d6aca80c
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Current finalize api's takes buf as input parameter and returns
the finalized buf. But if there are any issue while finalizing,
it failed to throw an error.
Change-Id: I6db54b7453eec41a8051fab50d5c0dc937debd54
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
When IPv6 header contains extra header (e.g. HBH), extra header length
was not part of app data length calculation. Result applications get
invalid total length. Also simplified set_appdata_values().
Change-Id: I07438d62dfd0f9abc1452484deb8b5eacdc37cf1
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
If a UDP context had net_context_recv() called before
net_context_bind(), then it will have a stale connection handle
associated with initial (random) port number, while will be "bound"
to a new port as specified in net_context_bind(). So, it silently
won't behave as a user expects. net_context_bind() should really
update (or destroy/recreate) conn_handle in this case, but until
it's implemented, apply stopgap measure of at lease reporting error
back to user in this case.
Jira: ZEP-1644
Change-Id: I22ad55f94eaac487a4d5091ccbb24f973ec71553
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Do not shortcut the sending side for TCP as we need to use
net_tcp_send_data() to send TCP data in order not to have
double unref in Bluetooth or IEEE 802.15.4 technologies which
has a special TCP packet sending logic.
Change-Id: I077db336c6335ccdbbafa4600f98388ecf33955f
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
User can configure its own pools for data that needs to
be transmitted out (TX). This helps to avoid deadlocking
the system if user space application uses all the buffers
in the system, and the core IP stack tries to get buffer
that needs to be sent out.
By default the net_buf pool support in net_context is turned
off as application developer needs to create the pools and
tie them to desired contexts.
Change-Id: Ida4a1771d34d6c250974e56fba4f0e0b2592cb29
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This function is used only within net_context.c, make the symbol static
then.
Change-Id: Ib2c00a21c25e8c6a1404d6345d4b8ae05b779525
Signed-off-by: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
Since we try to match with POSIX behavior as much as possible, let's
not bother the user unless they need to be bothered. The recv(2) POSIX
syscall won't return 0 on stream sockets unless the connection has been
closed by the peer; however, that was happening with the callback set
by net_context_recv().
Change it so that the callback is never called if operating on a stream
socket and appdatalen is set to 0.
This is similar to a previous patch sent by Michael Scott in [1], but
not relying on the actual TCP flags: only on the appdatalen and the
socket type.
[1] https://gerrit.zephyrproject.org/r/#/c/9949/
Jira: ZEP-1632
Change-Id: Ib0c214fc9269d305a03e8d85eb606f106c45b038
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Due to commit fece856959 ("net: tcp: Clean up FIN handling") the
tcp_established() callback now handles TCP connections which are
in various ending/closing states other than TCP_ESTABLISHED.
Currently, these states are generating the following error and not
being processed:
Context 0x123456778 in wrong state 6.
(Shown when TCP is in LAST_ACK state).
This commit also fixes a memory leak issue discribed in
Jira: ZEP-1658
Analysis of the memory leak issue is here:
When TCP connection is established, tcp context is in
NET_TCP_ESTABLISHED state. Once it receives FIN message from client
it goes to NET_TCP_CLOSE_WAIT and then it turns to NET_TCP_LAST_ACK
after connection closing request from server. Now server gets final
ack from client, but tcp_established() will reject it because current
state is not in NET_TCP_ESTABLISHED. Even if server receives proper
ack, it is not handled by server. Hence 'sent_list' is not freed.
Change-Id: I41c8af2e6851809f87a02c271a4290cf3d823ebb
Signed-off-by: Michael Scott <michael.scott@linaro.org>
NET_ASSERT(net_nbuf_iface(buf)) should be called before setting
it on context [net_context_set_iface(context, net_nbuf_iface(buf))].
Change-Id: I9a1da1214857e96e03784bc98a9aae5cf59ef0fc
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
Because of the change in next commit "net: if: Change
the iface param in net_if_ipv6_maddr_lookup",
we must initialize the network interface to NULL.
Without this the multicast address lookup will fail.
Change-Id: I113b44ce23c5f2ecbbf1698972078f102995e891
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If a net context is not connected or listening, we can go ahead and
call net_context_unref() to free it up instead of waiting for
FIN_ACK which will never happen.
Change-Id: Ice06f572df64f2edb5918c10c92087ce0b7b254a
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Several error messages are currently being logged as NET_DBG which
requires the user to have CONFIG_SYS_LOG_NET_LEVEL=4.
Let's show these as errors so they are more visible.
Change-Id: I28c9a1aedb78787ef098a9bf565472a437373933
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Prior to commit df201a0e4b ("net: context: Assign a random port
number when context is created"), TCP clients were assigned a random
port number when the incoming sockaddr parameter's port value was 0.
After the above commit, this is now broken as it will bind to port 0.
If left this way, every TCP client would need to add a line of code
copying the context->local sockaddr_ptr's port value into the
src_sockaddr port prior to calling net_context_bin().
Instead, we can reinstate this behavior in net_context_bind(), by
making sure we only overwrite the randomly assigned port in the
context->local sockaddr if the incoming sockaddr parameter has a
port which is != 0.
Change-Id: I0f27f031f743d50c351ecf9ab55b5282a20ff292
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Doing it only in net_context, prevented to do it once NS succesfully
finished. This generated an error in 15.4, where pending data had wrong
ll reserve size.
Change-Id: I0f917fb76171457e5dff2c29e44edb8f00662150
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Current behaviour has an issue when UDP context is created with local
port number 0, net_conn_input() happens to treat zero port as
a wildcard ("receive packets for all ports"). net_context_bind()
for a UDP context doesn't affect its existing connection in any way.
Proposed solution is, context should be created with a random free
port assigned and bind() updates connection information from context.
Jira: ZEP-1644
Change-Id: Idb3592b58c831d986763312077b0dcdd95850bc9
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
The port numbers in the range from 0 to 1023 are the well-known ports
or system ports. Do not allocate them for users.
Change-Id: I4d7b4e1314759e4d8b260669946b9880282642c0
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
Previous commit: 6e6281af96
"net: tcp: Only return -ETIMEDOUT if timeout>0 in connect"
missed that K_FOREVER needs a semaphore taken, but has a
value of -1.
Change the logic here to timeout!=0 to handle this case.
Change-Id: Iae6a784443810130a7de267226483426fbd4f0d4
Signed-off-by: Michael Scott <michael.scott@linaro.org>
The context may live for a while after the user closes it (c.f. TCP),
and of course the documentation specifies that the user must not use
it after calling net_context_put(). Don't confuse them by invoking
their callbacks on the "closed" connection; it's likely that the user
has destroyed her own tracking data and the user_data pointers would
be garbage.
Change-Id: Iba9cc7025c6ea4a94cc4796903966f8d1b831996
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The connection close paths were a little tangle. The use of separate
callbacks for "active" and "passive" close obscured the fundamentally
symmetric operation of those modes and made it hard to check sequence
numbers for validation (they didn't). Similarly the use of the
official TCP states missed some details we need, like the distinction
between having "queued" a FIN packet for transmission and the state
reached when it's actually transmitted.
Remove the state-specific callbacks (which actually had very little to
do) and just rely on the existing packet queuing and generic sequence
number handling in tcp_established(). A few new state bits in the
net_tcp struct help us track current state in a way that doesn't fall
over the asymmetry of the TCP state diagram. We can also junk the
FIN-specific timer and just use the same retransmit timer we do for
data packets (though long term we should investigate choosing
different timeouts by state).
Change-Id: I09951b848c63fefefce33962ee6cff6a09b4ca50
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
A FIN packet generated by a net_context_put() must go into the normal
transmit queue and not be sent synchronously. Previously sent data is
expected to be delivered and acknowledged before the connection is
terminated.
An advantage we get with this change is unified timeout and retry
handling for FIN packets.
Note that there remains a misfeature here where the queing of the FIN
results in a synchronous switching of the connection callback to
tcp_active_close(), which will prevent any further data received from
being provided to the user.
Change-Id: I2d41316549da9fee383b4f32af5e8b3adf4cb122
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The death of a network context was sort of a mess. There was one
function, net_context_put(), which was used both by the user as a way
to "close" the connection and by the internals to delete it and to
"clean up" a TCP connection at the end of its life.
This has led to repeated gotchas where contexts die before you are
ready for them (one example: when a user callback decides the
transation is complete and calls net_context_put() underneath the
receive callback for the EOF, which then returns and tries to inspect
the now-freed memory inside the TCP internals). I've now stepped into
this mess four times now, and it's time to fix the architecture:
Swap the solitary put() call for a more conventional reference
counting implementation. The put() call now is a pure user API (and
maybe should be renamed "close" or "shutdown"). For compatibility,
it still calls unref() where appropriate (i.e. when the context can be
synchronously deleted) and the FIN processing will still do an unref()
when the FIN packets have been both transmitted and acked. The
context will start with a refcount of 1, and all TCP callbacks made on
it will increment the refcount around the callback to prevent
premature deletion.
Note that this gives the user a "destroy" mechanism for an in-progress
connection that doesn't require a network round trip. That might be
useful in some circumstances.
Change-Id: I44cb355e42941605913b2f84eb14d4eb3c134570
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
If the user supplied connect callback uses too much time, then
it is possible that the connect_wait semaphore will timeout
even if the TCP connection was established correctly. This issue
can be avoided if connect_cb is called after we have released
the connect_wait semaphore.
Change-Id: I175e80f2ad48de657d0d99a44340c5ee1a17364c
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
No need to set the status to -ETIMEDOUT in connect callback
if user did not want to have a timeout when doing a TCP connect.
Change-Id: I6d6e565a8d12bcefbcd9de751e789b5e43aad244
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
A connection refused needs to be exposed to the user, otherwise the
connection will be stuck as a zombie forever.
This patch also adds a ENOTCONN check in net_context_recv() to match
the one that was already there in net_context_send().
Change-Id: I4f9ae46dd849f68ed97976add7da5daf1932cf55
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The net_context_connect() callback was being invoked synchronously
with the transmission of the SYN packet. That's not very useful, as
it doesn't tell the user anything they can't already figure out from
the return code. Move it to the receipt of the SYNACK instead, so the
app can know that it's time to start transmitting. This matches the
Unix semantics more closely, where connect(2) is a blocking call that
wakes up only when the connection is live.
Change-Id: I11e3cca8572d51bee215274e82667e0917587a0f
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
TCP states are swaped between "server" context and the new connection
context. But in any case the "server" context should loose the
information that makes it able to accept other new connections.
The swap was badly made, as the "server" context was loosing the
accept_cb (!) and the user data pointer. Instead the new connection
context was unrelevantly inheriting those.
Change-Id: Icc877449e1d4c4e59553dcbfd41718c5006edca0
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
It is useful that the user API can know whether the connection
was established properly or not. So this commit adds status
parameter to connect callback in net_context API.
The call to connect callback needs to be set properly in TCP
code. This commit does not fix the connect callback call which
is not properly done right now in net_context.c.
Change-Id: I284a60ddd658ceef9e65022e96591f467a936a09
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If the parameter "timeout" is set in net_context_connect(), the
assumption by the user is that the function would wait for SYNACK
to be received before returning to the caller.
Currently this is not the case. The timeout parameter is handed
off to net_l2_offload_ip_connect() if CONFIG_NET_L2_OFFLOAD_IP is
defined but never handled in a normal call.
To implement the timeout, let's use a semaphore to wait for
tcp_synack_received() to get a SYNACK before returning from
net_context_connect().
Change-Id: I7565550ed5545e6410b2d99c429367c1fb539970
Signed-off-by: Michael Scott <michael.scott@linaro.org>
net_context is used for more than just TCP contexts. However,
the accept_cb field is only used for TCP. Let's move it from
the generic net_context structure to the TCP specific net_tcp
structure.
Change-Id: If923c7aba1355cf5f91c07a7e7e469d385c7c365
Signed-off-by: Michael Scott <michael.scott@linaro.org>
When SYNACK is received we dont hand off the netbuf to anything
which will call net_nbuf_unref, so let's not mark it NET_OK.
Instead let the code path fall through to mark it NET_DROP.
Change-Id: I1f883e1a13c53c930bf50c07ff701e3db6f02d8a
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Now that the TCP_FIN block is after a potential packet_received()
tcp->send_ack should be appropriately set to the last sequence
processed.
In the case of a TCP_FIN buffer, we should advance it by 1 or else
the destination will continue to retry to send the last block.
Change-Id: I9c97d35a87ad6cc1a50f928b237780bff4cd2877
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Since we default to a return value of NET_DROP, we
can remove the automatic NET_DROP in the TCP_FIN block.
The return value will be set to NET_OK by packet_received()
if appropriate data is found which needs to be sent to
the callback.
Change-Id: Ib2634ba34440ca7053a4e98bf80f12cf6fbbd361
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Buffers marked TCP_FIN may still have data attached to them
which needs to be processed and handed back to the callback.
Let's move the TCP_FIN handling to after the data processing
section now that we have a copy of the TCP flags to do this.
Change-Id: I90f53b10e393024ebffebe1837b8866764b8a7ac
Signed-off-by: Michael Scott <michael.scott@linaro.org>
buffer TCP flags can be cleared during packet_received so let's
save a copy of them for later.
Change-Id: I401e99c1ed2723dac4e86da58635b548a5645c13
Signed-off-by: Michael Scott <michael.scott@linaro.org>
No more than 4 bits are necessary to store the state of a TCP connection,
so better pack it using bitfields so that it uses only 4 bits instead of
32, by sharing space with `retry_timeout_shift` and `flags` fields.
There are 12 (or 14, if you count the 2 unused bits in the `flags`
field) bits remaining in the same dword, but I don't know what to to
stuff there yet.
This also changes all direct field access for the `state` field to
function calls. These functions are provided as `static inline`
functions and they perform only casts, so there's no function call
overhead.
Change-Id: I0197462caa0b71b287c0773ec5cd2dd4101a4766
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This value is never set (always zero), so it's safe to remove it from
the net_tcp struct.
Change-Id: Ie4c1d90204a9834f2223b09828af42ee101bd045
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The net_tcp struct was being cleaned up and destroyed when the
outbound FIN packet is sent on a connection that already received an
inbound FIN. That's not right, per spec we need to wait for the ACK
(though this would be benign cheating). And worse: there were code
paths which were themselves spec-compliant where the net_tcp struct
(now a NULL pointer) would be used after this spot leading to
occasional crazy behavior on socket close.
Don't do it this way. Clean up the TCP struct at the same time we
destroy the net_context. Much saner that way.
Change-Id: I4bc6b97eb0b71a7fa8faea02c1eb4c4d3bd3ae6d
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The TCP stack inherited msot of the user_data management from UDP, but
it doesn't quite work. It's not possible to have a single pointer in
the general case, as e.g. a net_context_send() call may happen
synchronously underneath a recv callback and clobber the pointer, even
though there will be much more data coming later on the active stream.
Put a recv_user_data field into the TCP struct and use that. Long
term, it would be good to revisit this and come up with a unified
solution that works for both. There is yet another "user_data"
pointer in net_connection that seem likely to overlap too.
Change-Id: Id3a8eca64fc680e0e80b74944c4d621d7810a8fe
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Replace the existing Apache 2.0 boilerplate header with an SPDX tag
throughout the zephyr code tree. This patch was generated via a
script run over the master branch.
Also updated doc/porting/application.rst that had a dependency on
line numbers in a literal include.
Manually updated subsys/logging/sys_log.c that had a malformed
header in the original file. Also cleanup several cases that already
had a SPDX tag and we either got a duplicate or missed updating.
Jira: ZEP-1457
Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
net_context_put() forgot to release the conn_handler field causing
subsequent failures in net_conn_register() when they ran out.
Change-Id: I0d306b5035199422fa8788338ac9da8d1900d5f9
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
TCP didn't actually have a way to signal synchronous receipt of a FIN
packet. Extend the recv_cb API to allow a NULL buf argument with
status==0 (by analogy to Unix's zero-length read) to signal EOF.
Update docs too, and also echo_server which wasn't prepared to handle
this situation.
Change-Id: I7dc08f9e262a81dcad9c670c6471898889f0b05d
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The tcp_synack_received() function ends with a call to send_ack().
However, if we don't update the sequence and ACK values, we'll send back
headers with 0 values and the destination will try resending over and
over.
Fix this by saving the seq and ack values when a TCP_SYN is flagged
in the header (which should be the case almost any time this function
is used as a callback).
Change-Id: I57f07ce719f2b6e2fb34c96c867d2e1c37f342ba
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Once SYNACK has been received for a TCP connection, we need to set the
net context state to NET_CONTEXT_CONNECTED or else calls to sendto()
will fail with -ENOTCONN.
Change-Id: Idd78e1dcdd5ac0bca5d3fba40b59ab8fde6b8729
Signed-off-by: Michael Scott <michael.scott@linaro.org>
When calling net_context_connect, the local address family
is never set prior to calling net_tcp_register. This generates
an error:
"Local address family not set." (-EINVAL)
Let's set the local address family prior to this call.
Change-Id: Ic5f2edf684d14f9bb77019c49c95e5524a406417
Signed-off-by: Michael Scott <michael.scott@linaro.org>
When TCP SYNACK is received we register the connection via the
net_tcp_register function. During this call several errors are
generated concerning local and remote address information not
being set.
Let's copy the local and remote address data prior to this call.
Change-Id: I17cd83f7b4b7e65e45fec1810fb38f745653bdc7
Signed-off-by: Michael Scott <michael.scott@linaro.org>
TCP packets need the computed packet length early so they can fill in
a correct sequence number in their generated ACKs. Waiting for
packet_received() is too late. Precompute it before needed, and skip
the evaluation later.
Change-Id: I25547009f88277e0042c74f2005a141819797886
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On accepting a new connection, the stack does an odd "swap" trick
where it updates the struct net_tcp record on the *listening* context
with the values from the new connection, and then swaps it with the
empty one that got allocated for the *new* context.
Unfortunately this swap forgot to swap the net_tcp "context" field
backpointers, so the net_context retrieved at runtime was for the
wrong connection. Surprisingly, this actually almost worked for a
long time, except that the destination address would be wrong in the
newer setup.
Change-Id: I0c1812ddb9f9ff3e7deb60d1fd67cafd9ba96997
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The source address for a TCP SYNACK must (obviously) be the same as
the destination address of the SYN that produced it. But the existing
IP packet creation routines would simply fill in a default address
from the net_context struct, which is correct for *established*
connections, but for the listening socket is generally INADDR_ANY
(i.e. all zeroes) and will result in an arbitrary choice for source
address (e.g. a link-local address on the same interface) which can
easily be wrong.
So we need to pass the correct address all the way down from the SYN
packet handler code through the net_ipv*_create() packet creation
functions. This requires lots of API plumbing, but relatively little
logic change.
Change-Id: Ic368f8cef6689f8a27cbafd5933a4964d5cc457e
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Let's make net stack having its own level of debugging through sys_log.
It replaces NET_DEBUG by NET_LOG_ENABLED, which is then semantically
better: someone wanting to log the errors might want that not only for
debugging.
Along with it, CONFIG_NET_LOG_GLOBAL option is added, in order to enable
all available logging in network stack. It is disabled by default but
might be found useful when warning/errors need to be logged, so it is
then unnecessary to selectively enable by hand all CONFIG_NET_DEBUG_*
options.
It is possible, locally, to override CONFIG_SYS_LOG_NET_LEVEL by setting
the level one want to NET_SYS_LOG_LEVEL. This can be useful on samples
or tests.
Change-Id: I56a8f052340bc3a932229963cc69b39912093b88
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This patch adds the ARG_UNUSED macros to some function arguments
to avoid compiler warnings.
Change-Id: Iae2cd3018c9442ffa9268fdfd33eb9a21f55087c
Signed-off-by: Flavio Santes <flavio.santes@intel.com>
Fix compilation issues that show up if SYS_LOG is mapped to printk
instead of printf. Unlike printf, printk is annotated so that the
compiler catches incorrect format specifiers passed to it.
Change-Id: Iab7cc6da110e9c98720211a6f773dcf055a3a411
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Moved networking code into subsys/net.
* Renamed net/yaip to net/ip at the same time.
* Fixed the tests/net to compile
* Fixed the Makefiles and Kconfig files in subsys/net
to use the new location of the IP stack
Change-Id: Ie45d9e8cb45a93fefdf969b20a81e3b1d3c16355
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
