From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 Date: Mon, 30 Apr 2007 15:02:36 +0800 Message-ID: <36BC62FC45C4E949B13C20DEFA8617D504F42BFB@zmy16exm62.ds.mot.com> From: "GAO LIANG-TAO-W20048" To: Cc: Singer Catherine-CSINGER1 , Jin Hong-Lei-W19971 , Saeed Faisal-EFS015 Subject: [Bluez-devel] Report a bug against "l2cap_conf_output()" in "net/bluetooth/l2cap.c" Reply-To: BlueZ development List-Id: BlueZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0538687606==" Sender: bluez-devel-bounces@lists.sourceforge.net Errors-To: bluez-devel-bounces@lists.sourceforge.net This is a multi-part message in MIME format. --===============0538687606== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78AF5.8962EECE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78AF5.8962EECE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 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 =3D L2CAP_CONF_UNACCEPT; } else { pi->omtu =3D pi->conf_mtu; } I think it's wrong to enlarge the outgoing MTU value (by calling "pi->omtu =3D 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". =20 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 =3D L2CAP_CONF_UNACCEPT; } =20 Regards, Gao Liangtao =20 ------_=_NextPart_001_01C78AF5.8962EECE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 =3D L2CAP_CONF_UNACCEPT;

} else {

= pi->omtu =3D pi->conf_mtu;

}

I think it’s = wrong to enlarge the outgoing MTU value (by calling “pi->omtu =3D = 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 =3D L2CAP_CONF_UNACCEPT;

}

Regards,

Gao = Liangtao

------_=_NextPart_001_01C78AF5.8962EECE-- --===============0538687606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- 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/ --===============0538687606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel --===============0538687606==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Bluez-devel] Report a bug against "l2cap_conf_output()" in"net/bluetooth/l2cap.c" Date: Wed, 16 May 2007 09:40:22 +0800 Message-ID: <36BC62FC45C4E949B13C20DEFA8617D5054D2D29@zmy16exm62.ds.mot.com> References: From: "GAO LIANG-TAO-W20048" Cc: , List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 Date: Tue, 15 May 2007 18:54:34 +0800 Message-ID: <36BC62FC45C4E949B13C20DEFA8617D5054D2C7C@zmy16exm62.ds.mot.com> References: From: "GAO LIANG-TAO-W20048" To: Subject: Re: [Bluez-devel] Report a bug against "l2cap_conf_output()" in"net/bluetooth/l2cap.c" Reply-To: BlueZ development List-Id: BlueZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: bluez-devel-bounces@lists.sourceforge.net Errors-To: bluez-devel-bounces@lists.sourceforge.net 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Marcel Holtmann To: BlueZ development In-Reply-To: <36BC62FC45C4E949B13C20DEFA8617D504F42BFB@zmy16exm62.ds.mot.com> References: <36BC62FC45C4E949B13C20DEFA8617D504F42BFB@zmy16exm62.ds.mot.com> Date: Fri, 04 May 2007 08:55:32 +0200 Message-Id: <1178261732.25425.41.camel@violet> Mime-Version: 1.0 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" Reply-To: BlueZ development List-Id: BlueZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Sender: bluez-devel-bounces@lists.sourceforge.net Errors-To: bluez-devel-bounces@lists.sourceforge.net 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==