Re: [RFC bluetooth-next 00/20] bluetooth: rework 6lowpan implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 07/12/2016 04:51 PM, Luiz Augusto von Dentz wrote:
...
>>
>> HOW TO REPRODUCE:
>>
>> It's simple, do some high payloads which makes lot tx/rcv traffic on both sides:
>>
>> Node A:
>>
>>  ping6 $IP_NODEB%6lo0 -s 60000
>>
>> Node B:
>>
>>  ping6 ff02::1%6lo0
> 
> Im not sure I understand what you are trying to do with a packet of
> 60Kb, the l2cap_chan can most likely only do 1280 bytes and even with

60Kb is just some incredible high value to produce on both sides tx/rx
data. The other side will normally send some "defragmentation failure"
icmp messages.

This value is just to produce the high traffic, not practice payload.

> fragmentation this will consume the credits quicker than we can
> receive more so it will eventually starting buffering until it gets
> stuck. Note that it is probably still receiving credits but we

This is exactly what I like to do. Produce a lot of data to kill L3
layer, but this should not kill the L2 layer. Killing the L2 layer is
what's happend here.

If I do a lot of data on e.g. tcp traffic and the tcp connection will be
closed -> that's fine for me but afterwards starting a new L3 connection
should be still working. This is not the case here, I can kill L2 layer
and nothing works anymore, because L2 running into deadlock.

> probably have so much data buffered that all the credits are consumed
> almost immediately after receiving, or you don't see -EAGAIN more than
> once?
> 

My example shows that we transmit some data on both nodes, that is
important to check the l2cap_chan_send return type.

When I do that above and running into the deadlock the IPv6 connection
runs "NS" messages only, because it still can send on L3 layer but the
L2 layer is killed -> I get -EAGAIN in l2cap_chan_send always on both
nodes because tx_credits are on both nodes zero and will not be
incremented again.

So far I know these tx_credits will be incremented only if somebody
sends something again, right? This will never be the case again and I am
stucked in a deadlock which should not be there.

to your question:

"or you don't see -EAGAIN more than once"

I see -EAGAIN always at calling l2cap_chan_send on both nodes. I think I
can wait forever, after an year I still see "-EAGAIN" when calling
l2cap_chan_send.

Nevertheless, I will try to hit the deadlock (-EAGAIN) on both nodes so
nobody transmits anything anymore. Then waiting six hours and look if
still -EAGAIN is there on both nodes. I will report again here, after
that time it should working again, but I don't believe that.

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



[Index of Archives]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux