Date: Fri, 07 Jan 2005 11:56:08 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Jes <jjess@freebsd.polarhome.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: Motorola E1000 and obexapp 1.4.4 in server mode Message-ID: <41DEE958.70403@savvis.net> In-Reply-To: <20050107195406.0c76f42e@zurich.homeunix.com> References: <20050107163705.616cbe5f@zurich.homeunix.com> <41DECEA3.5080500@savvis.net> <20050107195406.0c76f42e@zurich.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jes,
thanks for the dump.
here is what i have found:
1) l2cap channel was successfully created between the phone and pc. both
sides have configured mtu's:
here phone tells it can accept up to 2053 bytes in single l2cap packet
and pc confirms it
1105123527.375250 > ACL data: handle 0x0029 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0049 flags 0x0000 clen 4
MTU 2053
1105123527.375371 < ACL data: handle 0x0029 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x0000 result 0 clen 0
here pc tells phone that we can accept up to 132 bytes in single packet
and phone confirms it
1105123527.375379 < ACL data: handle 0x0029 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x0000 clen 4
MTU 132
1105123527.390290 > ACL data: handle 0x0029 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0049 flags 0x0000 result 0 clen 4
MTU 132
it is my understanding that after this the phone should send all l2cap
data on this channel in 132 (or less) bytes chunks.
now move to rfcomm channel (which uses l2cap channel as transport)
1105123527.425223 > ACL data: handle 0x0029 flags 0x02 dlen 18
L2CAP(d): cid 0x0049 len 14 [psm 3]
RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
dlci 2 frame_type 0 credit_flow 15 pri 0 ack_timer 0
frame_size 667 max_retrans 0 credits 0
1105123527.425341 < ACL data: handle 0x0029 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
dlci 2 frame_type 0 credit_flow 14 pri 0 ack_timer 0
frame_size 667 max_retrans 0 credits 7
here we see the phone telling that it wants to use rfcomm frames of 667
bytes in size (frame_size 667). and the pc confirms that its fine.
now, first notice that rfcomm frame_size of 667 bytes is bigger then
l2cap mtu of 132 bytes. so, it is *my* understanding of the spec that,
in this case, each rfcomm frame of 667 bytes should be transmitted as
series of l2cap packets and each l2cap packet should not exceed 132
bytes in size. rfcomm layer must re-assemble entire 667 bytes (or less)
frame out of 132 bytes chunks and then process it.
what happens next is you are trying to push 'img01pop.jpg' file which is
65486 bytes in size, we i see
1105123530.107822 > ACL data: handle 0x0029 flags 0x02 dlen 339
1105123530.112517 > ACL data: handle 0x0029 flags 0x01 dlen 336
L2CAP(d): cid 0x0049 len 671 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 2 pf 0 ilen 666 fcs 0x9a
OBEX: Put cmd(c): len 1024 (continue)
Body (0x48) = Sequence length 1018
[ .... ]
first we see two l2cap chunks of 339 and 336 bytes in size respectively
(they were segmented at baseband level). the weird thing is that
original l2cap packet was 671 bytes in size! remember we previously
configured l2cap channel to *not* accept l2cap packets bigger then 132
bytes and phone has accepted it.
at this point i'm not sure who is at fault here. after reading the spec
i was not sure if *entire* rfcomm frame must fit into l2cap mtu, or
segmentation is allowed. i need to re-read the spec and look at more
dumps from different bluetooth devices. it seems to me that if l2cap
channel was configured to use 132 bytes mtu then device should not send
larger packets, so my first impression is that the phone has a bug.
as workaround you might want to try this:
1) edit /sys/netgraph/bluetooth/include/ng_btsocket_rfcomm.h file and
change RFCOMM_DEFAULT_MTU from 127 to 667.
2) re-compile ng_btsocket module, i.e.
# cd /sys/modules/netgraph/bluetooth/socket/
# make depend
# make
# make install
3) reboot and try again
thanks,
max
Jes wrote:
> Thanks for replying so fast :)
>
> hcidump.bin attached.
>
> Bye
>
> Jes
>
>
> On Fri, 07 Jan 2005 10:02:11 -0800
> Maksim Yevmenkin <maksim.yevmenkin@savvis.net> wrote:
>
>
>>Jes,
>>
>>
>>>I've just found motorola e1000 suited for vodafone maybe can send
>
> files
>
>>>via bluetooth (sort of more or less hidden menu option). Ok, obexapp
>
> in
>
>>>client mode works fine (1.4.4) but in server mode i get errors
>>>(/var/log/messages).
>>>
>>>I launch obexapp in server mode :
>>>
>>>
>>>>obexapp -d -s -C 10
>>>
>>>then I send the file from phone, my phone finds my computer and try
>
> to
>
>>>send ... and remains trying until I cancel. In /var/log/messages two
>>>entries :
>>>
>>>Jan 7 16:34:10 zurich kernel: ng_l2cap_l2ca_receive: ubt0l2cap -
>>>invalid L2CAP data packet. Packet too big, length=671, imtu=132,
>
> cid=77
>
>>>Jan 7 16:34:10 zurich kernel: ng_l2cap_l2ca_receive: ubt0l2cap -
>>>invalid L2CAP data packet. Packet too big, length=363, imtu=132,
>
> cid=77
>
>>hmmm... strange. it appears that phone sends over sized l2cap packets.
>
>
>>rfcomm layer sets default mtu of 132 bytes, but remote side (phone)
>>keeps sending much bigger packets, so the stack drops them.
>>
>>
>>>I can't find information about this... any idea ?
>>
>>as usual, i need binary hcidump (produced with -w option). without it
>
> i
>
>>can not tell what is going on. just by looking at two error messages
>>below i'd guess that both sides (phone and pc) seems to disagree on
>
> mtu.
>
>>max
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41DEE958.70403>