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

Hi,

On 07/12/2016 04:51 PM, Luiz Augusto von Dentz wrote:
...

quoted

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