Motorola E1000 and obexapp 1.4.4 in server mode

[Maksim Yevmenkin]

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 at 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
> 
> 
>