Date: Fri, 12 Oct 2012 23:21:52 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Andreas Longwitz <longwitz@incore.de> Cc: freebsd-bluetooth@freebsd.org Subject: Re: btpand problem Message-ID: <alpine.NEB.2.00.1210122254010.965@galant.ukfsn.org> In-Reply-To: <50782E05.5080005@incore.de> References: <507736A8.4050605@incore.de> <BDA3CA14-92C0-414E-9D55-E96EA7A73312@gmail.com> <5077490F.7010901@incore.de> <CAFPOs6pF51wy9PvKLn4-OnrOqo8hU1S=P5PzTFwgUppBjqAtuA@mail.gmail.com> <alpine.NEB.2.00.1210120949170.628@galant.ukfsn.org> <50782E05.5080005@incore.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.NEB.2.00.1210122254010.965>