Increase the buffer length from 10 to 300 packets. Consider that traffic on
mac802154 devices will often be 6LoWPAN, and a full-length (1280 octet)
IPv6 packet will fragment into 15 6LoWPAN fragments (because the MTU of
IEEE 802.15.4 is 127). A 300-packet queue is really 20 full-length IPv6
packet
Version 2 of this patch series:
Differences from v1:
1. Patches previously numbered 5 and 6 were squashed (to become current
patch #4) at the request of Alexander Smirnov.
2. Current patch #2 had extraneous braces removed.
3. Current patch #1 was changed. It is now a patch to make mac802154 _no
When ops->xmit() fails, drop the packet. Devices which support hardware
ack and retry (which include all devices currently supported by mainline),
will automatically retry sending the packet (in the hardware) up to 3
times, per the 802.15.4 spec. There is no need, and it is incorrect to
try to do
Use netif_stop_queue() and netif_wake_queue() to control the flow of
packets to mac802154 devices. Since many IEEE 802.15.4 devices have no
output buffer, and since the mac802154 xmit() function is designed to
block, netif_stop_queue() is called after each packet.
Signed-off-by: Alan Ott
---
ne
dev_queue_xmit() will return a positive value if the packet could not be
queued, often because the real network device (in our case the mac802154
wpan device) has its queue stopped. lowpan_xmit() should handle the
positive return code (for the debug statement) and return that value to
the higher l
>> I would be happy about any comments :)
>
> This definitely sounds like a very good idea to me.
>
> I'm not sure whether the state change (to RX_ON) that's still
> being commanded in at86rf230_start after transmit completion is
> harmless. I'd consider getting rid of it.
>
> Unless I was horr
Sascha Herrmann wrote:
> I think you are right here, I had the setting of RX_SAFE_MODE removed in
> an earlier version, too. If I understand this right, we only need to set
> RX_SAFE_MODE after reading the frame buffer.
I think we just need to set it once and then never touch it again.
At least th
Hello,
I'm glad to announce the first release of SimpleRPL, a Linux-based
implementation of the Routing Protocol for Low-Power and Lossy Networks
(RPL).
This protocol has been developed at the IETF as an attempt to define a
routing
protocol suitable for lossy and low bandwidth link-layer (such a
On Thu, Apr 04, 2013 at 12:02:30AM +0200, Tony Cheneau wrote:
> I'm glad to announce the first release of SimpleRPL, a Linux-based
> implementation of the Routing Protocol for Low-Power and Lossy
> Networks (RPL).
You do that in ... Python? How does that fit with the fact that a lot of
802.15.4 de
