Detected with:
./scripts/checkpatch.pl --strict -f net/ieee802154/6lowpan_rtnl.c
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan_rtnl.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowp
We have a 6lowpan.c file and 6lowpan.ko file. To avoid confusing we
should move 6lowpan.c to 6lowpan.ko. Then we can support multiple source
files for 6lowpan module.
Signed-off-by: Alexander Aring
---
net/ieee802154/{6lowpan.c => 6lowpan_rtnl.c} | 0
net/ieee802154/Makefile
This patch adds necessary ieee802154 6lowpan namespace to provide the
inet_frag information. This is a initial support for handling 6lowpan
fragmentation with the inet_frag api.
Signed-off-by: Alexander Aring
---
include/net/net_namespace.h| 4
include/net/netns/ieee802154_6low
This patch drops the current way of 6lowpan fragmentation on receiving
side and replace it with a implementation which use the inet_frag api.
The old fragmentation handling has some race conditions and isn't
rfc4944 compatible. Also adding support to match fragments on
destination and source addres
Hi all,
I finally rework the patch serie and I think I could send it to netdev.
So please all test these patches if you like and send me a:
Tested-by: $YOUR_NAME <$YOUR_EMAIL>
just reply to this mail here. Then it's easier for me to bring these patches
mainline.
I uploaded these patches on gith
This patch adds a 6lowpan fragmentation struct into cb of skb which
is necessary to hold fragmentation information.
Signed-off-by: Alexander Aring
---
include/net/ieee802154_netdev.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee8021
This patch fix the fragmentation on sending side according to rfc4944.
Also add improvement to use the full payload of a PDU which calculate
the nearest divided to 8 payload length for the fragmentation datagram
size attribute.
The main issue is that the datagram size of fragmentation header use
Hi Alex,
After a bit a googling it looks like tx_queue_len is the number of skb's
that the transmit queue can hold whilst it is stopped. Is this correct?
I'll try a smaller value and see if it locks up quicker and then try
increasing it. I would have thought 300 would have been ample for a
p
On Fri, Feb 14, 2014 at 09:07:03AM +, Martin Townsend wrote:
> Hi Alex,
>
> After a bit a googling it looks like tx_queue_len is the number of skb's
> that the transmit queue can hold whilst it is stopped. Is this correct?
> I'll try a smaller value and see if it locks up quicker and then try
On Fri, Feb 14, 2014 at 09:31:26AM +0100, Alexander Aring wrote:
> lowpan_give_skb_to_devices(local_skb, NULL);
> -
I fixed this one with ret = lowpan_give_skb_to_devices(local_skb, NULL);
> - kfree_skb(local_skb);
> - kfree_skb(skb);
> + if (ret
Hi Alex,
I found that tx_queue_len is exported to sysfs
/sys/class/net/wpan0/tx_queue_len
So I tried a few values. first a value of 50 and all was well in that
pings still worked. So I tried to ssh from one board to the other
ssh -6 root@fe80::a200:0:0:1%lowpan0 and it locked up. So I reboote
Hi,
I abort my ping6 now, results are:
--- fe80::a8aa:::aabb%lowpan0 ping statistics ---
39931 packets transmitted, 39930 received, 0% packet loss, time 12005152ms
rtt min/avg/max/mdev = 154.164/163.993/175.157/2.782 ms
so these are very very good! I only lost one packet and maybe this o
Since three of the four clear channel assesment modes make use of energy
detection, provide an API to set the energy detection threshold.
Driver support for this is available in at86rf230 for the RF212 chips.
Since for these chips the minimal energy detection threshold depends on
page and channel u
Since the AT86RF2xy chips are mostly compatible, this is only a small
change to the actual driver code. The at86rf230 driver already supports the
RF212 in most places, only three small adjustments are required:
* force the initial state after P_ON to FORCE_TRX_OFF to work around a
documented e
This patch does multiple things:
* add .set_csma_params and .set_frame_retries for the RF212 radio.
This should work fine with RF230, but since I have no RF230 radios to
test with, RF230 does not implement these right now
* enable TX_ARET for frame retransmission limits greater than -1
Si
Hi,
this patch set adds support for the RF212 radio chip to the existing
at86rf230 driver and adds support for numerous features of the RF212
chips to the ieee802154 stack. These features include CSMA parameter
configuration, transmit power control, CCA parameter configuration, and
automatic retra
The standard assigns channel 0 on page 2 to be 100kbps QPSK in the
868.3MHz band. Add support to the at86rf230 driver for this channel and
page, at the moment predicated only for the RF212 chip.
Per the datasheet, configurations for page 0, channels 0 to 10 and page
2, channels 0 to 10 differ only
Replace the current u8 transmit_power in wpan_phy with s8 transmit_power.
The u8 field contained the actual tx power and a tolerance field,
which no physical radio every used. Adjust sysfs entries to keep
compatibility with userspace, give tolerances of +-1dB statically there.
This patch only adds
Listen-before-talk is an alternative to CSMA in uncoordinated networks
and prescribed by european regulations if one wants to have a device
with radio duty cycles above 10% (or less in some bands). Add a phy
property to enable/disable LBT in the phy, including support in the
at86rf230 driver for RF
Introduce new netlink attributes for SET_PHY_ATTRS:
* CSMA minimal backoff exponent
* CSMA maximal backoff exponent
* CSMA retry limit
* frame retransmission limit
The CSMA attributes shall correspond to minBE, maxBE and maxCSMABackoffs of
802.15.4, respectively. The frame retransmission shall
The standard describes four modes of clear channel assesment: "energy
above threshold", "carrier found", and the logical and/or of these two.
Support for CCA mode setting is included in the at86rf230 driver,
predicated for RF212 chips.
Signed-off-by: Phoebe Buckheister
---
drivers/net/ieee802154
A documented erratum of the RF212 chip describes that some versions of
RF212 may not be properly reset by the standard reset procedure. The
described workaround seems to not fully work either; my RF212 chips will
not correctly receive any frames unless they are taken from RX mode to
TRX_OFF and bac
The current IEEE802.15.4 stack assumes that a radio will never deliver
packets with a bad CRC into the stack, as required by the standard.
at86rf230 driven radios violates this assumption because of another
incompatibility: devices are required to send ACKs if requested by a
sender, but RF2xx will
23 matches
Mail list logo
