NET_APP settings was missing the device name and enabling the net shell
is nice to verify runtime configuration as well.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
If NET_L2_IEEE802154 and NET_IPV6 are enabled:
- NET_6LO is enabled
- NET_L2_IEEE802154_FRAGMENT is enabled
Thus removing setting this config options to yes where applicable.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This app now depends on net_app API, so it must be enabled for all
project configs we have.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
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>
In order to simplify when 802.15.4 is selected on these samples, let's
setup the device through a common code.
For this to work, RFD is now the default.
Change-Id: I46590864442f77d83f681cc0e854c94344648856
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
s/SAMPLES/APP for name shortening. Applying the change where relevant.
Not only IP addresse will be available as samples settings there but
also IEEE 802.15.4 channel, pan_id, and more for instance.
Change-Id: I05dd24989bd0c804d9588092d67044a3e063bc88
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
If we receive lot of packets, it might happen that we exhaust
all the DATA buffers in the system. This would prevent from
us sending anything to the network.
Change this by splitting the DATA buffer pool into RX and TX
parts. This way RX flooding cannot consume all DATA buffers
that needs to be sent.
Change-Id: I8e8934c6d5fdd47b579ffa6268721b5eb3d64b6d
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This commit changes Kconfig prefix for ieee802154 drivers to
IEEE802154_*. This is done for consistency with config prefixes
used in other subsystems.
Change-Id: Ibbb4d96d2b748f4f13135bde85304ec34c5a90a6
Signed-off-by: Wojciech Bober <wojciech.bober@nordicsemi.no>
Add common log level for all IEEE802154 drivers.
Change-Id: If92c96b14e630d4482aadf9cacb25662d6663399
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
This will help to track only what's wanted (ipv6, tpc, udp, else...) if
needed to.
Change-Id: I5c2e5e582db629b5d0e1cd98004f693c50f532a4
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
When zephyr receives a 15.4 frames it allocates 1 RX buf (nbuf) and 1
DATA (buf), and it gets queued on net stack for post processing.
Problem: receiving a lot of frames is just completely nominal and very
fast (timing is critical in radio, and the rx thread of the radio driver
has a high priority, much higher than net stack's rx post processing).
So guess what happens when CONFIG_NET_NBUF_RX_COUNT=10 though let's say
12 packets are coming in?
The RX buffer pools gets empty and soon the system hangs on getting a
newly allocated one.
This proper CONFIG_NET_NBUF_RX_COUNT tweak fixes the issue, however some
future work will reduce the need of so many RX meta buf:
- l2's recv could be called right away at net_recv_data, before queuing
the buffer for post-processing, but this could affects reception
timing on radio side, which is critical.
- An l2 pre-processing (in the middle of what current l2 recv does)
could be implemented, it would be technology depenedent (aka: not
mandatory on all l2) and could quickly decide what to do and at best
drop the whole, or at least drop the RX meta buf (frag would still be
kept). Let's see.
Jira: ZEP-1427
Change-Id: Ic75b02efa36e35b450c02b3e6439a8d73f03f839
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
As the native IP stack is now the default, there is no need
for corresponding Kconfig option.
Change-Id: I08e4992f540f928a2b7378e8803e634e38725348
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Tomasz Bursztyka