diff mbox

答复: 答复: 答复: Problems about handling duplicate packets when frame retry is enabled

Message ID e3c7061c-75f6-7400-14ec-027078bf7dde@pengutronix.de (mailing list archive)
State Not Applicable
Headers show

Commit Message

Alexander Aring Sept. 5, 2016, 8:53 a.m. UTC 
Hi,

On 09/04/2016 05:06 PM, Xue, Wenqian wrote:
> Hi, Alexander
> Sorry for so late reply, and thank you for your kind attention.
> 
>> -----邮件原件-----
>> 发件人: Alexander Aring [mailto:aar@pengutronix.de]
>> 发送时间: 2016年8月21日 5:37
>> 收件人: Xue, Wenqian/薛 文倩 <xuewenqian@cn.fujitsu.com>
>> 抄送: linux-wpan@vger.kernel.org
>> 主题: Re: 答复: 答复: Problems about handling duplicate packets when frame
>> retry is enabled
>>
>>
>> Hi,
>>
>> On 08/19/2016 03:10 PM, Xue, Wenqian wrote:
>>> Hi, Alexander,
>>>
>>> Sorry for so late reply, as I have some other business at hand.
>>>
>>>> -----邮件原件-----
>>>> 发件人: Alexander Aring [mailto:aar@pengutronix.de]
>>>> 发送时间: 2016年8月13日 0:29
>>>> 收件人: Xue, Wenqian/薛 文倩 <xuewenqian@cn.fujitsu.com>
>>>> 抄送: linux-wpan@vger.kernel.org
>>>> 主题: Re: 答复: Problems about handling duplicate packets when frame
>>>> retry is enabled
>>>>
>>>>
>> ...
>>>>
>>>> Your modification handles in duplicates in a form which is not
>>>> acceptable. It will simple drop duplicates but how frame retries works is the
>> following:
>>>
>>> If your meaning for my modification is that the result will be the same
>> whether retry is enabled or not? Initially, my motivation is to prevent the
>> received retry packet from being transmitted up to the wpan-ping level, then to
>> avoid the error "Sequence number did not match".
>>>
>>
>> I looked deeper for that handling in 802.15.4-2011 (which is the version which
>> is currently free available):
>>
>> 5.1.6.6 Transmission scenarios
>>
>> Your scenario is "Lost acknowledgment frame.", I don't see anything which let
>> me accept your patch to drop multiple received frames with the same sequence
>> number. The receiving node mac802154 stack is "recipient next layer".
>>
>> Or did I miss something?
>>
>>>>
>>>> 1. Node A transmits frame for Node B with ackrequest bit set.
>>>> 2. Node B receive that frame and see's "ackrequest bit is set" and
>>>>   sending an ACK back.
>>>> 3. If Node A received an ack for the sequence number then no
>>>>   retransmission will occur.
>>>> OR
>>>> 3. If Node A doesn't received an ack it will retransmit the frame.
>>>>
>>>>
>>>> On your nodes and if you are really using two at86rf233 transceivers,
>>>> this mechanism is completely done by hardware.
>>>>
>>>> Transmit: ARET
>>>> Receive: AACK
>>>>
>>>> On the receive side it's always imporant that the receiving node
>>>> supports AACK handling if Nodes sending frames with "ackrequest bit"
>>>> set.
>>>>
>>>> ---
>>>>
>>>> First, you should sniff somehow the traffic if it's possible, to see
>>>> what's going on the traffic and you see that Node B sends ACKs back,
>>>> if not -> missing AACK handling.
>>>>
>>>> On linux the openlabs transceiver (at86rf233) supports AACK handling...
>>>> don't know if you break it with your changes.
>>>>
>>>
>>> I get it for your detailed description for frame re-transmission mechanism.
>> And yes, I really use the two at86rf233 transceivers, I also used an ieee802.15.4
>> sniffer to sniff the traffic, ackrequest bit is indeed set, and I could see the
>> captured ack.
>>>
>>> I just did some tests with the kernel v4.7 (without my duplicate modification),
>> I did 3 cases, as below and the attachment:
>>> 1. set the max_frame_retries=3 for nodeA and nodeB, lots of "Sequence
>>> number did not match" errors occur during the test 2. set the
>>> max_frame_retries=0 for nodeA, and set the max_frame_retries=3 for
>>> nodeB, lots of "Sequence number did not match" errors occur during the test
>> 3. set the max_frame_retries=3 for nodeA, and set the max_frame_retries=0 for
>> nodeB, no above error occur In my goal, the retry needs to be enabled for both
>> sides, so I'd like to know the root cause for such case.
>>> I also made a simple description for the test cases to make you clearer for my
>> problem, a few typical captured packets are shown in the attachment.
>>> Hope you could give some suggestions for the problem, thank you very much!
>>>
>>
>> Sure, retransmits can be 3 at both sides. But somehow you have a missing
>> acknowledgment frame. The sniff example shows me this was never send.
>>
>> It could be that you transmit very fast and a force state change aborts the
>> transmitting of ACK frame in RX_AACK_BUSY state.
>>
>> Can you try this:
>>
>> diff --git a/drivers/net/ieee802154/at86rf230.c
>> b/drivers/net/ieee802154/at86rf230.c
>> index 9f10da6..97f75b5 100644
>> --- a/drivers/net/ieee802154/at86rf230.c
>> +++ b/drivers/net/ieee802154/at86rf230.c
>> @@ -64,7 +64,7 @@ struct at86rf2xx_chip_data {
>>  *
>>  * We assume the max_frame_retries (7) value of 802.15.4 here.
>>  */
>> -#define AT86RF2XX_MAX_TX_RETRIES       7
>> +#define AT86RF2XX_MAX_TX_RETRIES       20
>> /* We use the recommended 5 minutes timeout to recalibrate */
>> #define AT86RF2XX_CAL_LOOP_TIMEOUT     (5 * 60 * HZ)
>>
> I tried the test, but the result is still the same, lots of errors "Sequence number did not match" occur.
> Actually, I made some modification for at86rf230.c and wpan-ping.c for our experiment. To figure out the problem, I also tried other tests:
> 1. without any modification for at86rf230.c and wpan-ping.c, and enable the max_frame_retries (3) for both sides, the error "Sequence number did not match" also occurs, but not so frequently, it goes well overall.
> 2. with my modification for at86rf230.c, without the modification for wpan-ping.c, and enable the max_frame_retries (3) for both sides, lots of errors "Sequence number did not match" will occur.
> So, I guess it may be caused by my modification to the at86rf230.c. But I cannot figure out the problem, could you help me? Thank you!
> Below shows my modification, the motivation is to try to get the mac sequence number, rssi and lqi of the received packet, and output the values into a debug file:
> 

Sorry, I have no idea. You modification could insert some additional
operation which makes something slower.

I change not my opinion, I think something will do a FORCE TX_ON
statechange, if this is going while RX_AACK_BUSY (don't know the exact
namens), then it will abort a sending of ack frame, the frame can be
received before.

You can remove the if-branch at [0] which will never make some force
state change, when we receive currently. To be clear, this patch:


---

I currently have no idea what's going on your side and my only one guess
is that FORCE change will abort the transmitting of an ACK frame, but I
also didn't saw some behaviour like that on my side. I also doesn't have
a two RPi2 setup.

- Alex

[0] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L450
--
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 9f10da6..d4c6d72 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -447,8 +447,6 @@  at86rf230_async_state_assert(void *context)
                            ctx->to_state == STATE_TRX_OFF) {
                                u8 state = ctx->to_state;
 
-                               if (lp->tx_retry >= AT86RF2XX_MAX_TX_RETRIES)
-                                       state = STATE_FORCE_TRX_OFF;
                                lp->tx_retry++;
 
                                at86rf230_async_state_change(lp, ctx, state,