btpand problem

[Andreas Longwitz]

Hi,

>>> Yes, I used the code fragment
>>>
>>> {
>>>          uint16_t mtu;
>>>          socklen_t len = sizeof(mtu);
>>>          getsockopt(chan->fd, SOL_L2CAP, SO_L2CAP_OMTU,&mtu,&len);
>>>          log_err("writev: %m (mtu %d)\n", mtu);
>>> }
>>>
>>> and found mtu=1691 in all cases (ok or failed), same for SO_L2CAP_IMTU.
>>
>> I see, so it seems that the kernel is returning EMSGSIZE when trying to
>> send a packet that is greater than L2CAP_MTU_DEFAULT..
>>
>> you could build the bluetooth netgraph code with debugging turned on, and
>> see if that kicked anything out about where the error is returned from..
>> The most obvious place to look at could be ng_btsocket_l2cap_send(), if
>> that is the one, is pcb->omtu the correct value?
>
> there should be sysctl knobs to increase debug level for sockets and
> ng messages for ng nodes.
>
> so, yes, please try to increase debug level for l2cap nodes and
> sockets and see if anything pops up

After increasing debug_level for net.bluetooth.l2cap from 3 --> 4 and 
adding a statement NG_BTSOCKET_L2CAP_INFO(..) in ng_btsocket_l2cap_send 
it was clear to me that in the case of the failed writev none of the 
debug statements triggers. This information pointed me to the possible 
solution of the problem. The reason for the EMSGSIZE error is the size 
of the send space reserved with soreserve() in ng_btsocket_l2cap_attach. 
After changing (in ng_btsocket_l2cap.h) the line
   #define NG_BTSOCKET_L2CAP_SENDSPACE   NG_L2CAP_MTU_DEFAULT /* (64 * 
1024) */
to
   #define NG_BTSOCKET_L2CAP_SENDSPACE  (64 * 1024)
the error is gone.
Please verify if this correction is suitable.

Andreas Longwitz