The Californium tests expects that all GET responses include the
Content-Format information of the response. In our case, all responses
are of type plain-text.
Change-Id: I08844825f31ed8f4c54020a41b9172cef5da6d70
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
So the sample zoap server application is more conformant, include the
token from the request, if any, in the response.
Change-Id: I5aacc1a3f81ebeaf473d327163c952b829489b01
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
The Californium test suite considers an error responding a NON_CON
request with a ACK response, even if the spec says it is valid, so add
support for using the correct type of response according to the
request.
Change-Id: I211c8a135b8db83af442a1d645b7ea0826dbbdec
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
In some situations, for example, when the remote side sends a RESET
message indicating that it is no longer interested in observing a
resource, it is helpful to have a way to obtain the obverser
representation.
Change-Id: Ifbf627f9170be844fd525c557dda8cb722ac7aff
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
When retrieving options that represent an integer, the order of the
bytes being considered was inverted, resulting in invalid values being
returned.
Change-Id: I8ba84f77e3402066632c0ba650939266c87a8ea2
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
For example, when a RESET packet is passed to zoap_handle_request(),
there's nothing it can do, and it's not an error, so it returns
success silently.
Change-Id: I025bb44733521d6132999c219aaa292a3de302d7
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
This allows to verify that the CoAP server is able to handle a
blockwise PUT request.
Change-Id: I801e353a27b10a5266748591d023bcb607db6bb4
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
This status is used when a blockwise transfer should continue with the
next block.
Change-Id: If68c32aea8c0b63efcd929cdff57f0ff235b2792
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
This adds support for TD_COAP_BLOCK_01 and TD_COAP_BLOCK_02 tests,
which test that the CoAP server is able to handle GET requests with
blockwise tranfers.
Change-Id: Id0d1703adcf5d4e76dd1bc489c8bcc94a3fd90bc
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
This resource is used to verify that the CoAP server is able to send
responses in two steps: 1. only acknowledge that the request was
received and is going to be handled; 2. The actual response, with the
payload.
Change-Id: Ia77cc0ee9805e6cc120c57f4598c68ad364882a0
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
When parser encouter DHCPV4_OPTIONS_END, it immediately returns NET_OK.
No need to maintain end variable here.
Coverity-CID: 157584
Change-Id: I4c8b91f37ae882845c280dab1a8204966aaac00a
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
Pointer udp will be NULL when (!(CIPHC[0] & NET_6LO_IPHC_NH_1))
condition is true.
Coverity-CID: 157588
Change-Id: I8aa1eb2e4d4aee8039631d76ad0ecc345247d6b5
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
When contex information provided and DAC bit is not set and vice versa
are invalid cases.
Coverity-CID: 157569
Change-Id: I1b798703cbbb6155a7bdf734d0fcde9ce48c409c
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
In net_nbuf_get(), check that context pointer value is not
null before accessing data via it.
Coverity-CID: 157600
Change-Id: I7e7ea19a85f6fbef129e9ce699ea740d3be84cb8
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If the prefix length % 8 is not 0, then the remaining
bit length was calculated incorrectly and the prefixes
were claimed to match even though they might not be the
same.
Adding a test cases for testing this properly.
Coverity-CID: 157591
Change-Id: I9cb5a73d5cc211ec183176400fa5e2dfd209e2da
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If neighbor is not found, then ignore the timeout.
Coverity-CID: 157583
Change-Id: Ia2199970bd862e43901f5717025271c11c74af5e
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
We need to allocate separate fragment to store the IP
protocol headers.
Coverity-CID: 157582
Change-Id: Ib0dd5d28cd6876a0cf2de3b063c030ef64da998c
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Callback cannot be null so no need to check its value.
Coverity-CID: 157572
Change-Id: I26e4b24c41d30aa9007b78895975035e6bf8807f
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The context parameter might be NULL so we need to check
its value before accessing its content.
Coverity-CID: 157571
Change-Id: I7f75323d9d261a77421688f37a40bb44ff3ca2bd
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The link layer dereferences a buffer right after it is transmitted.
If this extra reference is not held, the second time a buffer is
retransmitted, the reference that TCP holds when keeping the buffer in
the `sent_list` will be taken, and retransmission won't happen reliably
anymore.
As soon as the TCP fragment is acknowledged by the peer, the
`sent_list` reference is taken, and the buffer is freed.
Change-Id: Ie50f9acf02c1dff74248a5dfbec3785a91ff90f7
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
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 frees up some more memory as well, by computing the maximum segment
size whenever needed. A flag is set in the TCP context to signal if
the value has been already computed.
Change-Id: Idb228d4682540f92b269e3878fcee45cbc28038a
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>
Rename the variable to `retry_timeout_shift`, and shift-right the value
each time there's a timeout. This saves some memory in that structure
by using the holes left due to alignment.
Change-Id: I18f45d00ecc434a588758a8d331921db902f4419
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Cancel all delayed work timers: FIN, ACK, and retry timers. Also, do
that unconditionally regardless of which state the machine is in, as
that's a no-op if the timer has not been started yet.
Change-Id: Ia36b97c6823943976447fbd6389ae04862c19ff9
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The rationale for removing fragments while sending them is to free the
memory they're using as soon as possible. This worked fine because
most protocols implemented initially did not require any
retransmission, so the upper layers were never holding an extra
reference to the buffer (& their fragments).
This is not the case anymore, as the TCP layer holds a reference to
a buffer (& fragments) while confirmation from the peer has not been
received, allowing retransmission.
With this change, the fragments of a buffer are not removed when being
sent by the SLIP layer; however, the buffer is still deferenced when the
transmission is complete. If nothing else holds a reference, all the
fragments are returned to their respective pools, like before.
Change-Id: I74966d72f6970b66f526ea0b765101077c843de2
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
DHCPv4 sample was running on main stack. Updated to run on its own
thread. Update config options (removed unnecessary ones and separated
few options for easy readability).
Change-Id: I3be38ca4cd4bcfa62e2613b90b104679cff2517e
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
This patch removes legacy configuation variables found at the
prj_arduino_101.conf file of the DNS sample application.
Change-Id: I74e370a7be177f809d805525cc18f594a59e38c0
Signed-off-by: Flavio Santes <flavio.santes@intel.com>
All sample applicatons in Zephyr, using the ENC28J60 driver, set
the ETH_ENC28J60_0_GPIO_PIN Kconfig variable to 19.
However, in the Kconfig.enc28j60 file this variable is set to 24.
That default value, 24, was used only during the first iterations
of this driver and never used again.
In this patch, we set the Kconfig variable to 19 and simplify
project configuration files by removing one line.
Change-Id: I3d5fd9da04a3f10845d2a409de56f5b9c235e995
Signed-off-by: Flavio Santes <flavio.santes@intel.com>
Remove CONFIG_GPIO=y for the Arduino 101 board. This configuration
is now set by default in the board configuration file.
See commit 8f96628064.
Change-Id: I6fa73a5785d78c51f03a0af48fc2aa8cc7636c7d
Signed-off-by: Flavio Santes <flavio.santes@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>
Let's drop the lladdr variable and get the link address and
length from the net_linkaddr_storage variable instead.
Change-Id: I75a5d08527cda7df102db897ade9015d39f10caf
Signed-off-by: Michael Scott <michael.scott@linaro.org>
lladdr.addr doesn't point to any storage value when it's
handed off to the net_nbuf_read function. This results
in a write to an undefined area of memory.
Fix this by pointing lladdr.addr to a net_linkaddr_storage
structure's byte storage array which can handle the maximum
specified length.
Change-Id: I05e0a0420b262ba1e5ac95cebe1f0d91f54878ce
Signed-off-by: Michael Scott <michael.scott@linaro.org>
The net_linkaddr_storage structure contains an array of bytes used
to store the link address. This array can be different sizes
depending on the CONFIG options used when building. To facilitate
consistency and error checking let's introduce a new helper function
to copy the addr and len values to this structure.
Also move all uses of memcpy related to net_link_storage structures to
the new helper function.
Change-Id: Ic547d86b07e62e5ac3bc330d4eaeb4508a143200
Signed-off-by: Michael Scott <michael.scott@linaro.org>
- Introduce NET_LINK_ADDR_MAX_LENGTH which is either 6 or 8
depending on whether CONFIG_NET_L2_IEEE802154 is used
- Instead of being a placeholder single index array of uint8_t,
let's use NET_LINK_ADDR_MAX_LENGTH to assign the size of the
"addr" array field in the net_linkaddr_storage structure.
- Now that the "addr" field of net_linkaddr_storage contains the
true size of the link address, we can remove "storage" field
which was hard coded to 8 bytes (2 uint32_t's).
- Fix 2 references to the "storage" field of the net_linkaddr_storage
structure.
Change-Id: I2ea12058280b289f65085964eb7d503d4fd260c2
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Add kernel pipe test cases which cover basic pipe apis usage
across thread and isr
Change-Id: I11899411b305535297f2e25056678d5b7df8fb95
Signed-off-by: jing wang <jing.j.wang@intel.com>
Add fifo/fifo test cases with unified kernel, which cover
basic apis across differnt contexts - thread and isr
Change-Id: Icb61d3dcd564167b0bd70419c652e0b000869959
Signed-off-by: jing wang <jing.j.wang@intel.com>
TestPurpose: verify memory pool concepts.
All TESTPOINTs extracted from kernel documentation.
https://www.zephyrproject.org/doc/kernel/memory/pools.html#concepts
ZEP-1210
Change-Id: I6250e4c26ddf361e74a76c23082cfdb376705560
Signed-off-by: Sharron LIU <sharron.liu@intel.com>
TestPurpose: verify memory pool APIs.
All TESTPOINTs extracted from kernel-doc comments in <kernel.h>
ZEP-1210
Change-Id: I7dcc0638e7b9c4d6b5ffe282e4fe41ca520d003f
Signed-off-by: Sharron LIU <sharron.liu@intel.com>
TestPurpose: verify API thread safe in multi-threads environment.
Thread safe test is explained with more details here:
https://gerrit.zephyrproject.org/r/#/c/9464/7/ test_mpool_threadsafe.c
Please comment if you think it necessary as an extensive kernel test.
Jira: ZEP-1209
Change-Id: I52a7ff393d72785622c047289e7d92286e131cc7
Signed-off-by: Sharron LIU <sharron.liu@intel.com>
TestPurpose: verify memory pool concepts.
All TESTPOINTs extracted from kernel documentation.
https://www.zephyrproject.org/doc/kernel/memory/slabs.html#concepts
ZEP-1209
Change-Id: I95c6cd666212218b9928356f9439e67a2fcf9b73
Signed-off-by: Sharron LIU <sharron.liu@intel.com>
TestPurpose: verify memory slab APIs.
All TESTPOINTs extracted from kernel-doc comments in <kernel.h>
ZEP-1209
Change-Id: I80bc85e96110e7106b3fc5883b982d71c6a7e50b
Signed-off-by: Sharron LIU <sharron.liu@intel.com>
tests/kernel/mem_slab --> tests/kernel/mem_slab/test_mslab
For the purpose to hold other mslab test apps.
Jira: ZEP-1209
Change-Id: I4a72b02a0a5095bb7cfbf73396b6d003ea63f92e
Signed-off-by: Sharron LIU <sharron.liu@intel.com>