Small fix for L2CAP MTU

Small fix for L2CAP MTU

[Stephen Crane]

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

Hi Marcel,
I've attached a small change to the L2CAP layer which causes it to
better adhere to a sender's choice of MTU.

The background is that we have a test here where the client asks for an
omtu of 50 and tries to send more than this to the server, which in turn
checks that only 50 bytes were sent.

With the current kernel code, the omtu is always returned as the default
MTU (672) which causes our test to fail.

I've attached a patch against 2.6.11.10 (proposed by my colleague Jim
O'Leary) which assigns omtu from that proposed by the peer, iff we don't
care about the omtu.

Thanks,
Steve
-- 
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
steve.crane@rococosoft.com +353-1-6601315 (ext 209)

[-- Attachment #1.2: l2cap.patch --]
[-- Type: text/x-patch, Size: 513 bytes --]

1359,1364c1359,1365
< 	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;
< 	}
---
> 	if (pi->omtu == 0) {
> 		/* If we don't care about the MTU, use peer's proposal */
>                 pi->omtu = pi->conf_mtu;
> 	} else if (pi->conf_mtu < pi->omtu) {
>                 l2cap_add_conf_opt(ptr, L2CAP_CONF_MTU, 2, pi->omtu);
>                 result = L2CAP_CONF_UNACCEPT;
>         }

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[Bluez-devel] Re: Small fix for L2CAP MTU

[Marcel Holtmann]

Hi Steve,

> I've attached a small change to the L2CAP layer which causes it to
> better adhere to a sender's choice of MTU.
> 
> The background is that we have a test here where the client asks for an
> omtu of 50 and tries to send more than this to the server, which in turn
> checks that only 50 bytes were sent.
> 
> With the current kernel code, the omtu is always returned as the default
> MTU (672) which causes our test to fail.
> 
> I've attached a patch against 2.6.11.10 (proposed by my colleague Jim
> O'Leary) which assigns omtu from that proposed by the peer, iff we don't
> care about the omtu.

please use unified diff. I am unable to read context diffs.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Small fix for L2CAP MTU

[Stephen Crane]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

(Oops, mea culpa. diff -Naur attached.)

On Wed, 2005-05-25 at 16:46 +0200, Marcel Holtmann wrote:
> Hi Steve,
> 
> > I've attached a small change to the L2CAP layer which causes it to
> > better adhere to a sender's choice of MTU.
> > 
> > The background is that we have a test here where the client asks for an
> > omtu of 50 and tries to send more than this to the server, which in turn
> > checks that only 50 bytes were sent.
> > 
> > With the current kernel code, the omtu is always returned as the default
> > MTU (672) which causes our test to fail.
> > 
> > I've attached a patch against 2.6.11.10 (proposed by my colleague Jim
> > O'Leary) which assigns omtu from that proposed by the peer, iff we don't
> > care about the omtu.
> 
> please use unified diff. I am unable to read context diffs.
> 
> Regards
> 
> Marcel
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
> online with coworkers and clients while avoiding the high cost of travel and
> communications. There is no equipment to buy and you can meet as often as
> you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-- 
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
steve.crane@rococosoft.com +353-1-6601315 (ext 209)

[-- Attachment #2: l2cap.patch --]
[-- Type: text/x-patch, Size: 764 bytes --]

--- net/bluetooth/l2cap.c-	2005-05-25 15:35:10.000000000 +0100
+++ net/bluetooth/l2cap.c	2005-05-25 15:37:45.000000000 +0100
@@ -1356,12 +1356,13 @@
 
 	/* Configure output options and let the other side know
 	 * which ones we don't like. */
-	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;
-	}
+	if (pi->omtu == 0) {
+		/* If we don't care about the MTU, use peer's proposal */
+                pi->omtu = pi->conf_mtu;
+	} else if (pi->conf_mtu < pi->omtu) {
+                l2cap_add_conf_opt(ptr, L2CAP_CONF_MTU, 2, pi->omtu);
+                result = L2CAP_CONF_UNACCEPT;
+        }
 
 	BT_DBG("sk %p result %d", sk, result);
 	return result;

[Bluez-devel] Re: Small fix for L2CAP MTU

[Marcel Holtmann]

Hi Steve,

> I've attached a small change to the L2CAP layer which causes it to
> better adhere to a sender's choice of MTU.
> 
> The background is that we have a test here where the client asks for an
> omtu of 50 and tries to send more than this to the server, which in turn
> checks that only 50 bytes were sent.
> 
> With the current kernel code, the omtu is always returned as the default
> MTU (672) which causes our test to fail.

I don't get it. Please show me the "hcidump -X -V" for both cases. With
and without the patch.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Small fix for L2CAP MTU

[Stephen Crane]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

Hi Marcel,
I've attached the two dump files. Let me know if you need any more info.

Thanks,
Steve

On Wed, 2005-05-25 at 17:59 +0200, Marcel Holtmann wrote:
> Hi Steve,
> 
> > I've attached a small change to the L2CAP layer which causes it to
> > better adhere to a sender's choice of MTU.
> > 
> > The background is that we have a test here where the client asks for an
> > omtu of 50 and tries to send more than this to the server, which in turn
> > checks that only 50 bytes were sent.
> > 
> > With the current kernel code, the omtu is always returned as the default
> > MTU (672) which causes our test to fail.
> 
> I don't get it. Please show me the "hcidump -X -V" for both cases. With
> and without the patch.
> 
> Regards
> 
> Marcel
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
> online with coworkers and clients while avoiding the high cost of travel and
> communications. There is no equipment to buy and you can meet as often as
> you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-- 
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
steve.crane@rococosoft.com +353-1-6601315 (ext 209)

[-- Attachment #2: unpatched --]
[-- Type: application/octet-stream, Size: 2633 bytes --]

[-- Attachment #3: patched --]
[-- Type: application/octet-stream, Size: 3399 bytes --]

Re: [Bluez-devel] Re: Small fix for L2CAP MTU

[Marcel Holtmann]

Hi Steve,

> I've attached the two dump files. Let me know if you need any more info.

I don't see it. No side is asking for a MTU with the size 50 in the
configuration process of the L2CAP connection setup.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Output power

[Pieter De Mil]

Hello,

Is it possible to know the output power a Bluetooth-dongle is using?

Because the link quality of a connection raises if we go further away, I 
wanted to know if you can read the used output power.

regards,
Pieter 




-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Output power

[Marcel Holtmann]

Hi Pieter,

> Is it possible to know the output power a Bluetooth-dongle is using?
> 
> Because the link quality of a connection raises if we go further away, I 
> wanted to know if you can read the used output power.

you can read the transmit power level with hcitool.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Output power

[Pieter De Mil]

Hello Marcel,

I measured the transmit power level of a Bluetooth-dongle, but it stays 0 in 
a range of 10m.
I'm sure that the link quality raises (from 212 tot 255 on a distance of 
2m), so I thought it was because the transmit power level is stronger.

Do you have experience with the transmit power level indication?

Regards,
Pieter



----- Original Message ----- 
From: "Marcel Holtmann" <marcel@holtmann.org>
To: <bluez-devel@lists.sourceforge.net>
Sent: Thursday, May 26, 2005 12:48 PM
Subject: Re: [Bluez-devel] Output power


> Hi Pieter,
>
>> Is it possible to know the output power a Bluetooth-dongle is using?
>>
>> Because the link quality of a connection raises if we go further away, I
>> wanted to know if you can read the used output power.
>
> you can read the transmit power level with hcitool.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
> online with coworkers and clients while avoiding the high cost of travel 
> and
> communications. There is no equipment to buy and you can meet as often as
> you want. Try it 
> free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
> 




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Output power

[Marcel Holtmann]

Hi Pieter,

> I measured the transmit power level of a Bluetooth-dongle, but it stays 0 in 
> a range of 10m.
> I'm sure that the link quality raises (from 212 tot 255 on a distance of 
> 2m), so I thought it was because the transmit power level is stronger.
> 
> Do you have experience with the transmit power level indication?

send in "hciconfig -a", because some dongles don't really support the
transmit power level. They always return 0.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: Small fix for L2CAP MTU

[Stephen Crane]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

Hi Marcel,

On Thu, 2005-05-26 at 12:31 +0200, Marcel Holtmann wrote:
> Hi Steve,
> 
> > I've attached the two dump files. Let me know if you need any more info.
> 
> I don't see it. No side is asking for a MTU with the size 50 in the
> configuration process of the L2CAP connection setup.

Sorry if I was unclear. The fix causes the omtu to be set to the peer's
value, only if we don't care about the omtu. No further negotiation is
performed.

I have attached a pair of test programs which highlight this:
* listener sets imtu and omtu to be 512
* connector connects to its first argument, setting omtu to the value of
its second argument.

Without the patch, the output of connector is:
$ ./connector 00:80:98:24:4F:19 50
imtu=672 omtu=512

With the patch, its output is:
$ ./connector 00:80:98:24:4F:19 50
imtu=672 omtu=50

Does this make sense?

Steve
-- 
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
steve.crane@rococosoft.com +353-1-6601315 (ext 209)

[-- Attachment #2: connector.c --]
[-- Type: text/x-csrc, Size: 1302 bytes --]

#include <sys/socket.h>
#include <netinet/in.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>
#include <bluetooth/l2cap.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
	struct sockaddr_l2 addr;
	int s = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP);
	int opt, n;
   struct l2cap_options opts;
   char buf[1024];
   int mtu = atoi(argv[2]);

	if (0 > s) {
		perror("socket");
		return -1;
	}
   opt = sizeof(struct l2cap_options);
   opts.imtu = L2CAP_DEFAULT_MTU;
   opts.omtu = mtu;
   if (0 > setsockopt(s, SOL_L2CAP, L2CAP_OPTIONS, &opts, opt)) {
      perror("setsockopt(l2cap)");
      close(s);
      return -1;
   }
	addr.l2_psm = htobs(0x1001);
	addr.l2_family = AF_BLUETOOTH;
	baswap(&addr.l2_bdaddr, strtoba(argv[1]));
	if (0 > connect(s, (struct sockaddr *)&addr, sizeof(addr))) {
		perror("connect");
		return -1;
	}
   if (0 > getsockopt(s, SOL_L2CAP, L2CAP_OPTIONS, &opts, &opt)) {
      perror("getsockopt");
      return -1;
   }
   printf("imtu=%d omtu=%d\n", opts.imtu, opts.omtu);
   n = sizeof(buf);
   if (mtu == 0)
      n = opts.omtu;
   else if (n > mtu)
      n = mtu;
   n = write(s, buf, n);
   if (0 > n) {
      perror("write");
      return -1;
   }
   printf("wrote %d bytes\n", n);
   close(s);
	return 0;
}

[-- Attachment #3: listener.c --]
[-- Type: text/x-csrc, Size: 1615 bytes --]

#include <unistd.h>
#include <malloc.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>
#include <bluetooth/l2cap.h>

int main(int argc, char *argv[])
{
	int l = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP);
	struct sockaddr_l2 addr;
	int opt = 0;
	int s, addr_len, n;
   struct l2cap_options opts;
   char buf[1024];

	if (0 > l) {
		perror("socket");
		return -1;
	}
	memset(&addr, 0, sizeof(addr));
	addr.l2_family = AF_BLUETOOTH;
	addr.l2_psm = htobs(0x1001);
	bacpy(&addr.l2_bdaddr, BDADDR_ANY); 
	if (0 > bind(l, (struct sockaddr *)&addr, sizeof(addr))) { 
		perror("bind");
		return -1;
	}
   opts.imtu = 512;
   opts.omtu = 512;
   if (0 > setsockopt(l, SOL_L2CAP, L2CAP_OPTIONS, &opts, sizeof(opts))) {
      perror("setsockopt(l2cap)");
      close(s);
      return -1;
   }
	if (0 > listen(l, 10)) {
		perror("listen");
		return -1;
	}
	s = accept(l, (struct sockaddr *)&addr, &addr_len);
	if (0 > s) {
		perror("accept");
		return -1;
	}
	if (0 > getpeername(s, (struct sockaddr *)&addr, &addr_len)) {
		perror("getpeername");
		return -1;
	}
	printf("got connection from %s\n", batostr(&addr.l2_bdaddr));
   opt = sizeof(struct l2cap_options);
   if (0 > getsockopt(s, SOL_L2CAP, L2CAP_OPTIONS, &opts, &opt)) {
      perror("getsockopt");
      return -1;
   }
   printf("imtu=%d omtu=%d\n", opts.imtu, opts.omtu);
   n = read(s, buf, sizeof(buf));
   if (0 > n) {
      perror("read");
      return -1;
   }
   printf("read %d bytes\n", n);
   close(s);
   close(l);
	return 0;
}