[Bluez-devel] Report a bug against "l2cap_conf_output()" in "net/bluetooth/l2cap.c"

[Bluez-devel] Report a bug against "l2cap_conf_output()" in "net/bluetooth/l2cap.c"

[GAO LIANG-TAO-W20048]

[-- Attachment #1.1: Type: text/plain, Size: 1276 bytes --]

 

Hi,

 

I want to report a bug against "l2cap_conf_output()" in BlueZ kernel
code "net/bluetooth/l2cap.c":

    if (pi->conf_mtu < pi->omtu) {

       l2cap_add_conf_opt(ptr, L2CAP_CONF_MTU, 2, pi->omtu);

       result = L2CAP_CONF_UNACCEPT;

    } else {

       pi->omtu = pi->conf_mtu;

    }

I think it's wrong to enlarge the outgoing MTU value (by calling
"pi->omtu = pi->conf_mtu") when device B gets the MTU in device A's
configuration request. In fact, Page 1006/1200 of Bluetooth SPEC v1.2 or
Page 1038/1230 of Bluetooth SPEC v2.0 EDR both require a minimum of the
"If the remote device sends a positive configuration response it shall
include the actual MTU to be used on this channel for traffic flowing
into the local device. This is the minimum of the MTU in the
configuration request and the outgoing MTU capability of the device
sending the configuration response." Here I consider the original
"pi->omtu" as the "outgoing MTU capability".

 

I suggest to remove the "else" clause, and to apply l2cap_add_conf_opt()
to both cases:

    l2cap_add_conf_opt(ptr, L2CAP_CONF_MTU, 2, pi->omtu);

    if (pi->conf_mtu < pi->omtu) {

       result = L2CAP_CONF_UNACCEPT;

    }

 

Regards,

Gao Liangtao

 


[-- Attachment #1.2: Type: text/html, Size: 7074 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Report a bug against "l2cap_conf_output()" in "net/bluetooth/l2cap.c"

[Marcel Holtmann]

SGksCgo+IAo+IEkgd2FudCB0byByZXBvcnQgYSBidWcgYWdhaW5zdCDigJxsMmNhcF9jb25mX291
dHB1dCgp4oCdIGluIEJsdWVaIGtlcm5lbAo+IGNvZGUg4oCcbmV0L2JsdWV0b290aC9sMmNhcC5j
4oCdOgo+IAo+ICAgICBpZiAocGktPmNvbmZfbXR1IDwgcGktPm9tdHUpIHsKPiAKPiAgICAgICAg
bDJjYXBfYWRkX2NvbmZfb3B0KHB0ciwgTDJDQVBfQ09ORl9NVFUsIDIsIHBpLT5vbXR1KTsKPiAK
PiAgICAgICAgcmVzdWx0ID0gTDJDQVBfQ09ORl9VTkFDQ0VQVDsKPiAKPiAgICAgfSBlbHNlIHsK
PiAKPiAgICAgICAgcGktPm9tdHUgPSBwaS0+Y29uZl9tdHU7Cj4gCj4gICAgIH0KPiAKPiBJIHRo
aW5rIGl04oCZcyB3cm9uZyB0byBlbmxhcmdlIHRoZSBvdXRnb2luZyBNVFUgdmFsdWUgKGJ5IGNh
bGxpbmcKPiDigJxwaS0+b210dSA9IHBpLT5jb25mX210deKAnSkgd2hlbiBkZXZpY2UgQiBnZXRz
IHRoZSBNVFUgaW4gZGV2aWNlIEHigJlzCj4gY29uZmlndXJhdGlvbiByZXF1ZXN0LiBJbiBmYWN0
LCBQYWdlIDEwMDYvMTIwMCBvZiBCbHVldG9vdGggU1BFQyB2MS4yCj4gb3IgUGFnZSAxMDM4LzEy
MzAgb2YgQmx1ZXRvb3RoIFNQRUMgdjIuMCBFRFIgYm90aCByZXF1aXJlIGEgbWluaW11bSBvZgo+
IHRoZSAg4oCcSWYgdGhlIHJlbW90ZSBkZXZpY2Ugc2VuZHMgYSBwb3NpdGl2ZSBjb25maWd1cmF0
aW9uIHJlc3BvbnNlIGl0Cj4gc2hhbGwgaW5jbHVkZSB0aGUgYWN0dWFsIE1UVSB0byBiZSB1c2Vk
IG9uIHRoaXMgY2hhbm5lbCBmb3IgdHJhZmZpYwo+IGZsb3dpbmcgaW50byB0aGUgbG9jYWwgZGV2
aWNlLiBUaGlzIGlzIHRoZSBtaW5pbXVtIG9mIHRoZSBNVFUgaW4gdGhlCj4gY29uZmlndXJhdGlv
biByZXF1ZXN0IGFuZCB0aGUgb3V0Z29pbmcgTVRVIGNhcGFiaWxpdHkgb2YgdGhlIGRldmljZQo+
IHNlbmRpbmcgdGhlIGNvbmZpZ3VyYXRpb24gcmVzcG9uc2Uu4oCdIEhlcmUgSSBjb25zaWRlciB0
aGUgb3JpZ2luYWwKPiDigJxwaS0+b210deKAnSBhcyB0aGUg4oCcb3V0Z29pbmcgTVRVIGNhcGFi
aWxpdHnigJ0uCgpJIG5lZWQgbW9yZSBkZXRhaWxzIGZyb20geW91LCBiZWNhdXNlIEkgZG9uJ3Qg
c2VlIHRoZSBpc3N1ZSBoZXJlLiBUaGUKTVRVcyAob3V0cHV0ICsgaW5wdXQpIGZvciBMMkNBUCBh
cmUgbmVnb3RpYXRlZCBpbiBib3RoIGRpcmVjdGlvbnMuCgpSZWdhcmRzCgpNYXJjZWwKCgoKLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQpUaGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnkgREIyIEV4cHJl
c3MKRG93bmxvYWQgREIyIEV4cHJlc3MgQyAtIHRoZSBGUkVFIHZlcnNpb24gb2YgREIyIGV4cHJl
c3MgYW5kIHRha2UKY29udHJvbCBvZiB5b3VyIFhNTC4gTm8gbGltaXRzLiBKdXN0IGRhdGEuIENs
aWNrIHRvIGdldCBpdCBub3cuCmh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcG93ZXJiYXIvZGIyLwpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpCbHVlei1kZXZl
bCBtYWlsaW5nIGxpc3QKQmx1ZXotZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0Cmh0dHBzOi8v
bGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2JsdWV6LWRldmVsCg==

Re: [Bluez-devel] Report a bug against "l2cap_conf_output()" in"net/bluetooth/l2cap.c"

[GAO LIANG-TAO-W20048]

Hi Marcel,

Sorry for getting back late.

I think you omitted the local outgoing MTU. The original code will
enlarge the outgoing MTU value, but the Bluetooth SPEC expects a minimum
of the MTU in the config request and the local outgoing MTU.

For example, if Device B starts an L2CAP service with incoming MTU 512,
and an L2CAP client on Device A claiming an outgoing MTU 53 tries to
connect to the service; the service on B sends configuration request to
the BlueZ stack on A with MTU 512, then A shall sends back a positive
response to B with the MTU 53 (not 512 as BlueZ actually does). In fact
this example is from a JSR82 MTU test case.

Here's the whole paragraph in page 1038 (of the total 1230) in Bluetooth
SPEC Core_v2.0_EDR.pdf:
"If the remote device sends a positive configuration response it shall
include the actual MTU to be used on this channel for traffic flowing
into the local device. This is the minimum of the MTU in the
configuration request and the outgoing MTU capability of the device
sending the configuration response. The new agreed value (the default
value in a future re-configuration) is the value specified in the
request."

My understanding is that the MTU can be increased in no cases. Please
let me know your consideration of this paragraph.

Thanks
Gao Liangtao


-----Original Message-----
From: Marcel Holtmann [mailto:marcel@holtmann.org] 
Sent: Friday, May 04, 2007 1:56 AM
To: BlueZ development
Cc: Singer Catherine-CSINGER1; Jin Hong-Lei-W19971; Saeed Faisal-EFS015
Subject: Re: [Bluez-devel] Report a bug against "l2cap_conf_output()"
in"net/bluetooth/l2cap.c"

Hi,

> 
> I want to report a bug against "l2cap_conf_output()" in BlueZ kernel 
> code "net/bluetooth/l2cap.c":
> 
>     if (pi->conf_mtu < pi->omtu) {
> 
>        l2cap_add_conf_opt(ptr, L2CAP_CONF_MTU, 2, pi->omtu);
> 
>        result = L2CAP_CONF_UNACCEPT;
> 
>     } else {
> 
>        pi->omtu = pi->conf_mtu;
> 
>     }
> 
> I think it's wrong to enlarge the outgoing MTU value (by calling 
> "pi->omtu = pi->conf_mtu") when device B gets the MTU in device A's 
> configuration request. In fact, Page 1006/1200 of Bluetooth SPEC v1.2 
> or Page 1038/1230 of Bluetooth SPEC v2.0 EDR both require a minimum of

> the  "If the remote device sends a positive configuration response it 
> shall include the actual MTU to be used on this channel for traffic 
> flowing into the local device. This is the minimum of the MTU in the 
> configuration request and the outgoing MTU capability of the device 
> sending the configuration response." Here I consider the original 
> "pi->omtu" as the "outgoing MTU capability".

I need more details from you, because I don't see the issue here. The
MTUs (output + input) for L2CAP are negotiated in both directions.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

RE: [Bluez-devel] Report a bug against "l2cap_conf_output()" in"net/bluetooth/l2cap.c"

[GAO LIANG-TAO-W20048]

Hi Marcel,

Are you simply ignoring my "bug" report? Dislike my email?

It's not an easy talk with you. I'm afraid my membership will be wrongly
disabled again after this email.

Regards,
Gao

-----Original Message-----
From: GAO LIANG-TAO-W20048=20
Sent: Tuesday, May 15, 2007 6:55 PM
To: bluez-devel@lists.sourceforge.net
Subject: RE: [Bluez-devel] Report a bug against "l2cap_conf_output()"
in"net/bluetooth/l2cap.c"

Hi Marcel,

Sorry for getting back late.

I think you omitted the local outgoing MTU. The original code will
enlarge the outgoing MTU value, but the Bluetooth SPEC expects a minimum
of the MTU in the config request and the local outgoing MTU.

For example, if Device B starts an L2CAP service with incoming MTU 512,
and an L2CAP client on Device A claiming an outgoing MTU 53 tries to
connect to the service; the service on B sends configuration request to
the BlueZ stack on A with MTU 512, then A shall sends back a positive
response to B with the MTU 53 (not 512 as BlueZ actually does). In fact
this example is from a JSR82 MTU test case.

Here's the whole paragraph in page 1038 (of the total 1230) in Bluetooth
SPEC Core_v2.0_EDR.pdf:
"If the remote device sends a positive configuration response it shall
include the actual MTU to be used on this channel for traffic flowing
into the local device. This is the minimum of the MTU in the
configuration request and the outgoing MTU capability of the device
sending the configuration response. The new agreed value (the default
value in a future re-configuration) is the value specified in the
request."

My understanding is that the MTU can be increased in no cases. Please
let me know your consideration of this paragraph.

Thanks
Gao Liangtao


-----Original Message-----
From: Marcel Holtmann [mailto:marcel@holtmann.org]=20
Sent: Friday, May 04, 2007 1:56 AM
To: BlueZ development
Cc: Singer Catherine-CSINGER1; Jin Hong-Lei-W19971; Saeed Faisal-EFS015
Subject: Re: [Bluez-devel] Report a bug against "l2cap_conf_output()"
in"net/bluetooth/l2cap.c"

Hi,

>=20
> I want to report a bug against "l2cap_conf_output()" in BlueZ kernel=20
> code "net/bluetooth/l2cap.c":
>=20
>     if (pi->conf_mtu < pi->omtu) {
>=20
>        l2cap_add_conf_opt(ptr, L2CAP_CONF_MTU, 2, pi->omtu);
>=20
>        result =3D L2CAP_CONF_UNACCEPT;
>=20
>     } else {
>=20
>        pi->omtu =3D pi->conf_mtu;
>=20
>     }
>=20
> I think it's wrong to enlarge the outgoing MTU value (by calling=20
> "pi->omtu =3D pi->conf_mtu") when device B gets the MTU in device A's=20
> configuration request. In fact, Page 1006/1200 of Bluetooth SPEC v1.2=20
> or Page 1038/1230 of Bluetooth SPEC v2.0 EDR both require a minimum of

> the  "If the remote device sends a positive configuration response it=20
> shall include the actual MTU to be used on this channel for traffic=20
> flowing into the local device. This is the minimum of the MTU in the=20
> configuration request and the outgoing MTU capability of the device=20
> sending the configuration response." Here I consider the original=20
> "pi->omtu" as the "outgoing MTU capability".

I need more details from you, because I don't see the issue here. The
MTUs (output + input) for L2CAP are negotiated in both directions.

Regards

Marcel