diff mbox

Resend : Reading corrupt IEEE 802.15.4 packages with the AT-REB233 and the BeagleBone Black with IWPAN

Message ID CAB_54W5+pnKoL2LzfwfqsOOXVj0BG6dNRstJMFkrX1fG9mm=kA@mail.gmail.com (mailing list archive)
State Not Applicable
Headers show

Commit Message

Alexander Aring Aug. 2, 2017, 9:55 p.m. UTC
Hi,

2017-08-02 14:59 GMT-04:00 Alexander Aring <aring@mojatatu.com>:
> Hi,
>
> On Wed, Aug 2, 2017 at 1:03 PM, Balz <s.balz@hm.edu> wrote:
>> Hi Alex,
>>
>> I've changed the Kernel module so that i read the Framebuffer as SRAM and
>> not as FrameBuffer.
>> I've write a 0x00n followed by 0x00 to determine a SRAM read from the addr
>> 0.
>>
>> But the Kernel Module can not identity the frame length any more.
>>
>> The Sniffed packages (all Packages have 143 byte length) do not show the
>> behaviour any more.
>>
>> Maybe the SRAM read access is protected and the Frame-buffer Read not...?
>>
>
> I think frame buffer read access only.
>
> "Dynamic Frame Buffer Protection is released on the rising edge of pin 23 (/SEL)
>  during a Frame Buffer read access, or on the radio transceiver’s
> state change from
>  RX_ON or RX_AACK_ON to another state.", see [0].

Please try this patch:


I think I know what could be going on...

It's "... to another state."... Maybe when a RX irq occurs during the
spi async handling there could be some "xmit" callbacks... This will
change the transceiver into another state... (not directly, but so far
I know it queues for state change). So when it will automatically go
into RX_AACK_ON then it will change the state to something else and
allows framebuffer overwrite.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Alexander Aring Aug. 2, 2017, 10:16 p.m. UTC | #1
Hi,

switched back to my new mail addres... sorry.

On Wed, Aug 2, 2017 at 5:55 PM, Alexander Aring <alex.aring@gmail.com> wrote:
> Hi,
>
> 2017-08-02 14:59 GMT-04:00 Alexander Aring <aring@mojatatu.com>:
>> Hi,
>>
>> On Wed, Aug 2, 2017 at 1:03 PM, Balz <s.balz@hm.edu> wrote:
>>> Hi Alex,
>>>
>>> I've changed the Kernel module so that i read the Framebuffer as SRAM and
>>> not as FrameBuffer.
>>> I've write a 0x00n followed by 0x00 to determine a SRAM read from the addr
>>> 0.
>>>
>>> But the Kernel Module can not identity the frame length any more.
>>>
>>> The Sniffed packages (all Packages have 143 byte length) do not show the
>>> behaviour any more.
>>>
>>> Maybe the SRAM read access is protected and the Frame-buffer Read not...?
>>>
>>
>> I think frame buffer read access only.
>>
>> "Dynamic Frame Buffer Protection is released on the rising edge of pin 23 (/SEL)
>>  during a Frame Buffer read access, or on the radio transceiver’s
>> state change from
>>  RX_ON or RX_AACK_ON to another state.", see [0].
>
> Please try this patch:
>
> diff --git a/drivers/net/ieee802154/at86rf230.c
> b/drivers/net/ieee802154/at86rf230.c
> index 548d9d026a85..a54f0a0d3fef 100644
> --- a/drivers/net/ieee802154/at86rf230.c
> +++ b/drivers/net/ieee802154/at86rf230.c
> @@ -709,6 +709,8 @@ at86rf230_rx_read_frame_complete(void *context)
>         struct sk_buff *skb;
>         u8 len, lqi;
>
> +       ieee802154_start_queue(lp->hw);
> +
>         len = buf[1];
>         if (!ieee802154_is_valid_psdu_len(len)) {
>                 dev_vdbg(&lp->spi->dev, "corrupted frame received\n");
> @@ -824,6 +826,9 @@ static irqreturn_t at86rf230_isr(int irq, void *data)
>
>         disable_irq_nosync(irq);
>
> +       if (!lp->is_tx)
> +               ieee802154_stop_queue(lp->hw);
> +
>         ctx = kzalloc(sizeof(*ctx), GFP_ATOMIC);
>         if (!ctx) {
>                 enable_irq(irq);
>
> I think I know what could be going on...
>
> It's "... to another state."... Maybe when a RX irq occurs during the
> spi async handling there could be some "xmit" callbacks... This will
> change the transceiver into another state... (not directly, but so far
> I know it queues for state change). So when it will automatically go
> into RX_AACK_ON then it will change the state to something else and
> allows framebuffer overwrite.

it could be that there exists a race when stop queue is running and
currently a xmit is going on...
I currently have no idea how to solve it and need to have more details
what happens when the transceiver is in BUSY_RX and we do another
state change? Will it be queued or not (so after BUSY_RX it will
change to RX_ON and then another state)?

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Alexander Aring Aug. 3, 2017, 11:27 a.m. UTC | #2
Hi,

On Wed, Aug 2, 2017 at 6:16 PM, Alexander Aring <aring@mojatatu.com> wrote:
> Hi,
>
...
>>
>> It's "... to another state."... Maybe when a RX irq occurs during the
>> spi async handling there could be some "xmit" callbacks... This will
>> change the transceiver into another state... (not directly, but so far
>> I know it queues for state change). So when it will automatically go
>> into RX_AACK_ON then it will change the state to something else and
>> allows framebuffer overwrite.
>
> it could be that there exists a race when stop queue is running and
> currently a xmit is going on...
> I currently have no idea how to solve it and need to have more details
> what happens when the transceiver is in BUSY_RX and we do another
> state change? Will it be queued or not (so after BUSY_RX it will
> change to RX_ON and then another state)?
>

Sorry, I remember... you told you don't send anything? Then this can't
be the issue. :-(
... but maybe we should stop transmit queue while receiving.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/net/ieee802154/at86rf230.c
b/drivers/net/ieee802154/at86rf230.c
index 548d9d026a85..a54f0a0d3fef 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -709,6 +709,8 @@  at86rf230_rx_read_frame_complete(void *context)
        struct sk_buff *skb;
        u8 len, lqi;

+       ieee802154_start_queue(lp->hw);
+
        len = buf[1];
        if (!ieee802154_is_valid_psdu_len(len)) {
                dev_vdbg(&lp->spi->dev, "corrupted frame received\n");
@@ -824,6 +826,9 @@  static irqreturn_t at86rf230_isr(int irq, void *data)

        disable_irq_nosync(irq);

+       if (!lp->is_tx)
+               ieee802154_stop_queue(lp->hw);
+
        ctx = kzalloc(sizeof(*ctx), GFP_ATOMIC);
        if (!ctx) {
                enable_irq(irq);