Max, Marcel,
In order to pass TP/COS/CED/BV-08 we're supposed to be able to indicate tha=
t
there was a timeout waiting for an L2CAP disconnect confirm from the remote
device. I'm waiting for clarification that this is indeed necessary.
The test works like this:
1. We send a disconnect request
2. The tester ignores it.
3. optionally - we resend the disconnect request following a timeout patter=
n
where each retransmission happens after a delay equal to twice the previous
delay.
4. After 60 seconds the channel must be closed - we indicated to the app
that the channel is indeed closed (even though we didn't get a confirmation
from the remote side) and indicate that a timeout ocurred.
I think there's a standard way of doing that sort of thing by setting a
socket option which causes close() to block until things are closed. Not
sure though.
Can we do this with BlueZ?
-Daryl.
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 03:44 PM 5/13/2003, Marcel Holtmann wrote:
>Hi Max,
>
>> What we need is SO_LINGER option support. Application doesn't care so much about
>> the disconnect itself but it does care if all the data that it had written to a
>> socket has been sent.
>> i.e.
>> connect(sk);
>> send(sk, stuff, sizeof(stuff));
>> close(sk);
>>
>> Some apps want close() to sleep until all data has been sent and connection was
>> successfully closed.
>
>I never have tought about it before, but SO_LINGER support seems useful.
>And with this passing the test will be easy. Did using shutdown() for
>disabling sending and receiving works?
shutdown() == disconnect in L2CAP because we can't shutdown only on direction.
And yes it does work.
Max
Hi Max,
> What we need is SO_LINGER option support. Application doesn't care so much about
> the disconnect itself but it does care if all the data that it had written to a
> socket has been sent.
> i.e.
> connect(sk);
> send(sk, stuff, sizeof(stuff));
> close(sk);
>
> Some apps want close() to sleep until all data has been sent and connection was
> successfully closed.
I never have tought about it before, but SO_LINGER support seems useful.
And with this passing the test will be easy. Did using shutdown() for
disabling sending and receiving works?
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 05:11 PM 5/12/2003, Daryl Van Vorst wrote:
>Marcel,
>
>The behaviour you list below makes sense to me. I think there's supposed to
>be a 60 second timeout instead of 5 seconds, but that seems a bit excessive
>to me. Does it matter? If we close L2CAP and then the remote side sends an
>L2CAP_DISCONN_RSP, does the fact that we've already closed the channel cause
>any different packets to be exchanged?
No. If they don't send rsp within 5 second we simply kill this channel.
And if we receive rsp for already closed channel we ignore it.
>The only advantage that I see in the capability of a blocking close is
>completeness. I can't think of a scenario where it really matters, but you
>never know what someone will cook up.
>
>I don't believe the application actually needs to know that the
>disconnection was normal, just that it has definitely been disconnected. I'm
>a little fuzzy on the definition of "disconnected". Telling the app that
>there was a timeout is optional.
What we need is SO_LINGER option support. Application doesn't care so much about
the disconnect itself but it does care if all the data that it had written to a
socket has been sent.
i.e.
connect(sk);
send(sk, stuff, sizeof(stuff));
close(sk);
Some apps want close() to sleep until all data has been sent and connection was
successfully closed.
>If the stack closing the L2CAP connection and then receiving an
>L2CAP_DISCONN_RSP afterwards does not cause any different traffic to occurr
>(ie: the remote side can't tell the difference), then we're probably ok. Is
>this true?
Yes, remote side cannot tell whether a local app is sleeping on close() or not.
>Then the only difference between what we do and what the spec
>says is _when_ the "L2CA_DisconnectCfm" gets sent to the app. In our case,
>it would be immediately (i.e.: close() returned success). In the test case,
>it is 60 seconds after sending the disconnect request.
Yes. But SO_LINGER support is still useful for real life apps. I'll look in to it.
Max
Marcel,
The behaviour you list below makes sense to me. I think there's supposed to
be a 60 second timeout instead of 5 seconds, but that seems a bit excessive
to me. Does it matter? If we close L2CAP and then the remote side sends an
L2CAP_DISCONN_RSP, does the fact that we've already closed the channel caus=
e
any different packets to be exchanged?
The only advantage that I see in the capability of a blocking close is
completeness. I can't think of a scenario where it really matters, but you
never know what someone will cook up.
I don't believe the application actually needs to know that the
disconnection was normal, just that it has definitely been disconnected. I'=
m
a little fuzzy on the definition of "disconnected". Telling the app that
there was a timeout is optional.
If the stack closing the L2CAP connection and then receiving an
L2CAP_DISCONN_RSP afterwards does not cause any different traffic to occurr
(ie: the remote side can't tell the difference), then we're probably ok. Is
this true? Then the only difference between what we do and what the spec
says is _when_ the "L2CA_DisconnectCfm" gets sent to the app. In our case,
it would be immediately (i.e.: close() returned success). In the test case,
it is 60 seconds after sending the disconnect request.
-Daryl.
> -----Original Message-----
> From: Marcel Holtmann [mailto:[email protected]]=20
> Sent: May 12, 2003 4:49 PM
> To: Daryl Van Vorst
> Cc: 'BlueZ Mailing List'; 'MaxKrasnyansky'
> Subject: RE: [Bluez-devel] Qualification - L2CA_DisconnectCfm
>=20
>=20
> Hi Daryl,
>=20
> > What happens when you close an L2CAP connection?
>=20
> if you close() the L2CAP connection, we send a=20
> L2CAP_DISCONN_REQ and set a timeout of 5 seconds. In the case=20
> of L2CAP_DISCONN_RSP or the timeout, we close the L2CAP channel.
>=20
> Max, please correct me if this is wrong, because I am not 100% sure.
>=20
> > There is a test (see below) where the IUT sends an L2CAP disconnect=20
> > request but the tester ignores it (doesn't send a disconnect=20
> > response). To pass the test we must at least show an=20
> > "L2CAP_DisconnectCfm" to the application. Indicating that a timeout=20
> > ocurred is optional.
>=20
> I don't understand why the application needs to now if the=20
> L2CAP channel is correctly disconnected? We close the L2CAP=20
> socket and the rest has to be done by the kernel. If the link=20
> is dead and the other side didn't response, waiting 60=20
> seconds won't help. Or did you see any advantage of a=20
> blocking close()?
>=20
> Regards
>=20
> Marcel
>=20
>=20
>=20
Hi Daryl,
> What happens when you close an L2CAP connection?
if you close() the L2CAP connection, we send a L2CAP_DISCONN_REQ and set
a timeout of 5 seconds. In the case of L2CAP_DISCONN_RSP or the timeout,
we close the L2CAP channel.
Max, please correct me if this is wrong, because I am not 100% sure.
> There is a test (see below) where the IUT sends an L2CAP disconnect request
> but the tester ignores it (doesn't send a disconnect response). To pass the
> test we must at least show an "L2CAP_DisconnectCfm" to the application.
> Indicating that a timeout ocurred is optional.
I don't understand why the application needs to now if the L2CAP channel
is correctly disconnected? We close the L2CAP socket and the rest has to
be done by the kernel. If the link is dead and the other side didn't
response, waiting 60 seconds won't help. Or did you see any advantage of
a blocking close()?
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Max, Marcel,
What happens when you close an L2CAP connection?
There is a test (see below) where the IUT sends an L2CAP disconnect request
but the tester ignores it (doesn't send a disconnect response). To pass the
test we must at least show an "L2CAP_DisconnectCfm" to the application.
Indicating that a timeout ocurred is optional.
What happens if the remote side doesn't respond with a disconnect confirm?
Will the stack wait 60 seconds and then close the link anyway? Or will it
close it immediately and not even look for a diconnect confirm? Will close(=
)
return success?
Thanks,
-Daryl.
> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of=20
> Daryl Van Vorst
> Sent: May 9, 2003 5:05 PM
> To: BlueZ Mailing List
> Subject: [Bluez-devel] Qualification - L2CA_DisconnectCfm
>=20
>=20
> Max, Marcel,
>=20
> In order to pass TP/COS/CED/BV-08 we're supposed to be able=20
> to indicate that there was a timeout waiting for an L2CAP=20
> disconnect confirm from the remote device. I'm waiting for=20
> clarification that this is indeed necessary.
>=20
> The test works like this:
>=20
> 1. We send a disconnect request
> 2. The tester ignores it.
> 3. optionally - we resend the disconnect request following a=20
> timeout pattern where each retransmission happens after a=20
> delay equal to twice the previous delay. 4. After 60 seconds=20
> the channel must be closed - we indicated to the app that the=20
> channel is indeed closed (even though we didn't get a=20
> confirmation from the remote side) and indicate that a=20
> timeout ocurred.
>=20
> I think there's a standard way of doing that sort of thing by=20
> setting a socket option which causes close() to block until=20
> things are closed. Not sure though.
>=20
> Can we do this with BlueZ?
>=20
> -Daryl.
>=20
>=20
>=20
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003,=20
> Santa Clara The only event dedicated to issues related to=20
> Linux enterprise solutions http://www.enterpriselinuxforum.com
>=20
> _______________________________________________
> Bluez-devel mailing list
> [email protected]=20
> https://lists.sourceforge.net/lists/listinfo/b> luez-devel
>=20