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
[email protected] +353-1-6601315 (ext 209)
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
[email protected] +353-1-6601315 (ext 209)
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
(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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel