If the neighbor cache already contains neighbor with the same
link layer address, then just increase ref count instead of
creating a new entry.
Change-Id: I00d9b6febc126973f658051d7aaa6036d37e9fdd
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Printing now the neighbor lladdr index when applicable.
Change-Id: I9d6bd0557636fe09d7ef894cc08c793bce9ccf06
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This net_route_del_by_nexthop_data() variant will also match
routing protocol specific data.
Change-Id: I608b27ede3a95c7048b16278209072f0b21a260d
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Added net_ipv6_get_nbr_by_index(uint8_t idx) function which
will return IPv6 neighbor entry according to given link
layer index.
Change-Id: I36d61730815d9077ae74d282d686397db1d7cc6b
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If the L2 layer discards the network packet, we call context
send callback. If the L2 accepts the packet, then this callback
should not be called yet. After the packet is really sent by
the network driver, we inform the final status to network
context handler.
Change-Id: I63c734b8506aae198b62616e8f6f0dbb430f6bcd
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The other part of the stack can register a handler that is
called after the network packet has been sent. This callback
is used by RPL routing code.
Change-Id: I6b76c5f01d1f6706b0c0a56980ad50e1b85fc427
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The IPv6 neighbor information is needed in RPL so we need to
make the neighbor struct public in order to access is from
RPL code.
Change-Id: I71c7144af912209405de2b4457f3be63ab9aea68
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The neighbor add function is needed in RPL.
Change-Id: Id20a6650b838d1ac4b0c1f3572f232eff4c2f18b
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
We need a way to get neighbor entry (nbr) from routing entry.
Change-Id: I8438e61c7e63db26056b046bd05401beca9731e0
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This can be used to store routing protocol specific data
into neighbor entry. By default no extra data is allocated.
Change-Id: Iabff0a1df676398a47b86adbc398c4f566dcc40a
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Some of the DEBUG config options had _DEBUG string at the
end of the config option. This is inconsistent with the
rest of the networking stack debug options where the _DEBUG
is located in the middle of the option like this
CONFIG_NET_DEBUG_....
Change-Id: I8542079f9a88631e98b417fd6c62d2db48aa9bdf
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Parse and validate the sequence number and send the ACK synchronously
in the tcp_established() callback. No attempt is made to unify the
packet with any queued data (which isn't queued yet, but might be
someday).
Note that this requires that an accepted context clone over the
sequence numbers from the listening context (which received them
during the SYN).
(Note also that this exposes a bug in the current SYN handling:
there's only space for one set of sequence numbers on that listening
context, so if we get two SYNs before the round trip ACK arrives we'll
"accept" the wrong connection with garbage sequence numbers and both
connections will fail).
Change-Id: I129e2a4cd926385511a1d22eea6d4f19ff185501
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
My previous race cleanup missed the fact that the memset would end up
clearing the IN_USE flag! So we were always allocating the same
struct net_tcp (which, because the typical use is to listen on one
socket and then transfer on an accepted socket, almost kinda worked
for a lot of stuff, making this hard to find).
Change-Id: I8ca0c7f835ebd72271df10d03004f38f8b8efbd5
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The register being set before checking the count of the remaining
packets is incorrect, so this code fixes it by setting the proper
register bank before access
Jira: ZEP-1138
Change-Id: Id49ee8439665ff69786f22e13e0d94a2148e4ae7
Signed-off-by: Sergio Rodriguez <sergio.sf.rodriguez@intel.com>
The ENC28J60 hardware module does not support concurrent
transmission and reception.
This fix adds a control semaphore to exclude the execution
of both processes.
Applies the equivalent changes to the legacy driver.
Jira: ZEP-1097
Change-Id: I9602195d5a97f8d4bf652753c284d61f192357fe
Signed-off-by: Juan Manuel Cruz <juan.m.cruz.alcaraz@intel.com>
Tranmission: Consider that fragments are no adjacent.
Reception: Consider receiving data in more than one fragment.
SPI routines: Align SPI fragment size with default buffer fragment
size (128 bytes) for better performance.
Change-Id: I51fc25d8540c36f3719e617a6f33cdea3f63032c
Signed-off-by: Juan Manuel Cruz <juan.m.cruz.alcaraz@intel.com>
Everytime the devices receives a frame with odd length it will
add an extra byte of padding to the reception buffer.
This was causing and issue when receiving frames above 64 bytes
length and with odd length.
This commit pops the extra padding byte everytime the received
frame has an odd length.
The equivalent fix is applied to the legacy driver.
Jira: ZEP-1098
Change-Id: Ib93cbcdcf11f3812961b6702f1b7fa621590aab2
Signed-off-by: Juan Manuel Cruz <juan.m.cruz.alcaraz@intel.com>
When the driver receives or transmits a frames with a length
that is multiple of MAX_BUFFER_LENGTH the last block would be
read/sent twice to spi because a missed calculation on
num_remaining.
The issue is fixed by controling when the remaining bytes are
written/read into the spi device and by setting the spi command
on each spi write/read attempt.
The fix is applied to the legacy driver as well.
Jira: ZEP-1098
Change-Id: Icb2195d74e34dcbcf0c70531da9886ca315bd78b
Signed-off-by: Juan Manuel Cruz <juan.m.cruz.alcaraz@intel.com>
The MAX_BUFFER_LENGTH symbols is now declared in the
eth_ecn28j60_priv.h file.
The legacy driver does not need this declaration here anymore.
Change-Id: I396fe92dbf5679c64183e25fa8b8d342c7f30dae
Signed-off-by: Juan Manuel Cruz <juan.m.cruz.alcaraz@intel.com>
When we have received a network packet, we transform the MAC
address to big endian format as that is expected by the
upper IP stack.
When we are about to send a network packet, we do the reverse
and convert the link layer MAC address to little endian format.
Change-Id: I69cf7ec404763e2f0c9c542b45dbab812a98374b
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
It is the responsibility of the callback to release the buffer.
Change-Id: Id80f5f9ca190868a7c173994bb7ec7ee7f6251b7
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
When retrieving the address of a peer from the net_buf, care should be
taken so it happens before the 'data' pointer of the buffer is modified,
which causes the macros to retrieve the address from invalid positions.
Change-Id: I466fb989119ab5f7d0ac3899979670675bdaa946
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
The last argument to net_tcp_register takes a pointer to a void* for
the return value.
(This API has some pretty bad typesaftey problems -- void* will assign
to void** just fine. We should probably define a net_conn_handle_t or
something to prevent this kind of bug.)
Change-Id: I3f173c26c6b3995ddb8f679467431aed220a21cc
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The upper IP stack uses the MAC address to construct the IPv6
address in SLAAC. Because of this the MAC needs to be stored
in big-endian format so that it can be used directly as is.
Change-Id: Ib31da56307017b4284031328772d4cb51d84fa23
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The start of the fragment was calculated incorrectly.
The calculation used net_nbuf_ll() to get the start of fragment
but this does not work if the packet is created using multiple
fragments. The reason is that the net_nbuf_ll() will always
point to the first fragment instead of the fragment that we
are checking here.
Change-Id: Icae729f6fe0caea2fe9e04d297a2312e3e85162f
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The remote port number wasn't being correctly filled in the network
context, and was thus not registered in the network connection, and
would thus not match incoming packets correctly.
The local port was being set to a random/ephemeral port number on
accepted TCP connections, which was just wrong. Only outbound
connections get ephemeral ports. This too was preventing connections
from being matched correctly. This required removing an incorrect
test form find_available_port(), which assumed that no two contexts
could have the same local port (they can!).
Finally, the matching logic had a subtle bug: the network connection
array contains both the listening socket AND any existing connections,
all of which have the same local port number. The match would simply
choose whichever of those occurred last, but that's wrong: once a
connection is accepted we want to hand packets to that particular
net_connection callback, and not the listening socket. Add an
override at the end of the matching tests to capture that requirement.
(There's also a typo fix in this patch: a #endif was commented as
ending an IPV6 block instead of the IPV4 block it actually
terminates.)
Change-Id: Ie3030477c48186852a5e9712d836c7580873e1ea
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The receive window was always being filled as zero, and the
implementation of get_recv_wnd is awfully confusing as to what was
intended.
But this logic is needless anyway, the current architecture hands off
each received packet to a receive callback synchronously. There is no
queueing inside the stack, so the window size never needs to change.
The only complexity is that there appear to be two existing tunables
that affect it, we have to pick a (compile time) minimum.
Note this also removes the recv_wnd from struct net_tcp, as it no
longer needs to be tracked.
Change-Id: I58c7b2753f4714f4751d64630ca7f09823b5a6a8
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This doc goes through how to request something, or listen to a network
event. As well as it describes how to create a request handler and how
to throw a network event.
Change-Id: I07cc6d22a14e7f1a0f239f97982c984fd13379d6
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Microkernel test for 6lo was giving error because the
prj.mdef file was refering to wrong function name.
Change-Id: I4197c509fb266a908eb03cc0bda34e39c66b229c
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
We must use the data fragment to remove the lqi value.
The old code used the head of the buffer chain (RX buf) to
remove the lqi value, which caused the length value to go
from 0 -> 0xffff. This then caused then weird errors if
net_buf_frags_len() was used to calculate the length of all
the fragments.
Change-Id: I07ac42051e6773528b770b94a69c5bc76ae069af
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The helper, depending ot the MAC Command Information Field (CIF), will:
- allocate the buffer and the data fragment
- create the MHR part of the header
- set ll reserve and buffer length, in order to ease the later fill-in
of the MAC command itself (a tiny helper ieee802154_mac_command() is
provided).
Change-Id: I594196892906cd65e9d21e37d5757d289e6f9b3f
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Accept and validate MAC command frames.
Change-Id: I5acff998d1d0d1f53c9d6188f6c2fb0bc82697af
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
These descriptors will be used to parse and create IEEE 8022.15.4 MAC
Command frames.
Change-Id: Ic9eb17fe50ae1a9e8460ca62a05cea02cfb14f8a
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This is meant if only one needs reliability when sending non-TCP packets
(as TCP would make is redundant).
Change-Id: I7dc605094b422a750424c3498d18f32d809d23a8
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This level will support the basic features any 15.4 device needs to
have. Unlike ORFD, RFD is spec compliant.
(This choice is introduced now for clearer history)
Change-Id: I70cdd9fcd9cdf224207478f7a76f75ee8da8a31b
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Indentation in Kconfig is as follows:
- 1 tab for config attributes but for help content
- 1 tab + 2 spaces for help content
Change-Id: I026adb56fd8046d6bb8767857fcc7224a6248a97
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
fragment is only about testing 15.4 6lo fragmentation, so let's put it
in dedicated tests/net/ieee802154/ directory.
Change-Id: Ib838600e571753ab976c74dac78ee774f628c2ab
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
So reordering files in order to put more specific tests in it.
Change-Id: I000bc5efb8442d02e9a50e1b85cb45e0bec12789
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Relevantly provide ieee802154_fragment() to the 6lo library.
Change-Id: I77d4ff9e6d37a17ee30354a3026c295f8dfaa25c
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
No reassembly logic is changed besides removing the final reassembled
pointer. Instead of requiring such pointer, let's just use the frag one.
Such changes will ease the usage of ieee802154_reassemble():
the given frag buffer, in case it finally got reassembled and thus
provided a NET_CONTINUE verdict, will directly be handled by net_core.
This makes things consistent as well with verdicts:
- in case of NET_OK, buf has been consumed and thus unrefed
- in case of NET_DROP, buf needs to be unrefed by caller
- in case of NET_CONTINUE, buf is updated with reassembled and
decompressed data packet, up to net_core to handel it accordingly.
Change-Id: Ibd1588debd22a7f4571b36713dd46bf8b1d88329
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
As soon as fragment is put into the cache and as long as it is not
identified to be the last one: let's return NET_OK to notifiy the
fragment has been consumed by ieee802154 L2.
That way, net_core will not try to interpret it - and fail - unnecessary
increasing the drop statistics.
On the contrary, once the buffer is fully reassemble, let's return
NET_CONTINUE in order to let net_core consume the buffer relevantly.
Change-Id: I715b687e451f4643656e122b0d119f114696340b
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Such tag is meant for fragmented buffers only, so let's update it only
when:
- given buffer is valid
- given buffer needs to be fragmented
Change-Id: Ic3f41a9194ea11cd129fb0903bcd242facea7197
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
A buffer can be made of multiple fragments, so let's generate the 15.4
header for all of them.
Change-Id: I41fd8c939964da1ea6cdd3e00f16bb7297da509d
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
