btpand problem

Maksim Yevmenkin maksim.yevmenkin at gmail.com
Fri Oct 12 23:53:34 UTC 2012


On Fri, Oct 12, 2012 at 3:21 PM, Iain Hibbert <plunky at rya-online.net> wrote:
> On Fri, 12 Oct 2012, Andreas Longwitz wrote:
>
>> > Is this more than one connection, can you show the entire dump? (the first
>> > one is a rsp from the other side, then it sends a req later..?)
>>
>> I have only one connection: the dump gives the output of the command
>>   btpand -a panserver -d me -s NAP -i tap1. Full dump:
>
> yes, there are two L2CAP connections :)
>
> the first is to do the SDP query, then it sets up the BNEP link. And, it
> seems that the BNEP link has been set up with a MTU/MRU of 1691 as
> it should have..
>
>> 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

thanks,
max


More information about the freebsd-bluetooth mailing list