Got exception: OSError: [WinError -2147483629] The object has been closed #1280
Comments
dlech
added
bug
As described in #1280, it is possible for a session to be closed then activated again while getting services. This will cause an OSError because the closed event triggers the disconnect cleanup code, then trying to use the session after that fails because it has been closed. This works around the problem by disabling the disconnect cleanup code until the connect method has returned successfully. If the connect method raises an exception, it handles cleanup already so the cleanup code in the session status event handler never gets called in this case.
|
Could you please try #1281 and see if it make a difference on the "good" board? For the "bad" board, try logging Bluetooth packets to see what is the difference between a successful attempt and not successful attempt. Similar reports: |
|
Hi David,
I will! Thanks for the quick response 🙏
…On Fri, Apr 14, 2023, 18:46 David Lechner ***@***.***> wrote:
Could you please try #1281 <#1281> and
see if it make a difference on the "good" board?
For the "bad" board, try logging Bluetooth packets to see what is the
difference between a successful attempt and not successful attempt.
Similar reports:
- #1245 <#1245>
- #1198 <#1198>
—
Reply to this email directly, view it on GitHub
<#1280 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKXZUDHVZGWHM3YVISXRFLXBF5NDANCNFSM6AAAAAAW6PNFNM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
David, 1281 did it for the good board! Thanks. (Reproduced the error with the old code, changed to new code, ran 400 connections without problems, went back again to old code, and reproduced the error again [within 130 connect-attempts], upgraded to new code again, and verified ~800 successfull connections...) |
|
(Reopened, for the "bad"-board) First of all, it seems that applying #1281 changed the error from "OSError" to "Timeout (but more on than further down): BEFORE 1281:AFTER 1281:Also note that there is this additional line (every time I try with 1281): But I reckon that comes with the "fact" that 1281 actually makes "bleak-winrt" reestablish the connection/retry connecting after the initial failure (after 10s). Regardless, I think the focus should be on the first 10 seconds of the failing connect-attempt (and not on the last 10s where #1281 makes a slight difference). WIRESHARKFrom the Wireshark captures, it seems that this BAD board does not reply to the "Sent Exchange MTU Request" (when failing). BAD Board - failed connect (resulting in OSError): [timeout_on_bad_board_1281_around_20s_02.pcapng] ...compared to a capture of a successful connect (still on the BAD board): [timeout_on_bad_board_1281_around_20s_02.pcapng] There exists a small variation of the successful connect - at least according to Wireshark - where the Exchange MTU Request is received BEFORE being sent: [os_error_on_bad_board_after_30s_without_1281_01.pcapng] But nevertheless, why does Windows try to negotiate an MTU of 527 when BLE 5.0 (and others) only allow MTU of 247? From all this, can "we" conclude anything? os_error_on_bad_board_after_30s_without_1281_01.zip |
|
Thanks for testing the PR. I think it might be better to continue the discussion for the timeout error on one of the existing similar issues so that it will be easier for others with the same problem to find it. And this issue will get automatically closed when I merge the PR. Although based on your description and the wireshark capture, it does seem the problem in this case is that the device is simply not responding, so the issue is likely in the device firmware or the adapter firmware. If you have a Bluetooth sniffer, you can use it to see what is actually going over the air to determine if it isn't being sent at all or if it is getting dropped by the adapter. |
|
OK, I will move the thread to one of the other issues.
Do you have any comment on the MTU values of 527?
From where, and why, they origin?
(the strange thing is that the two devices have at least identical
application firmware, but I need to check whether the radio fw is the
same...)
…On Mon, Apr 17, 2023, 18:14 David Lechner ***@***.***> wrote:
Thanks for testing the PR. I think it might be better to continue the
discussion for the timeout error on one of the existing similar issues so
that it will be easier for others with the same problem to find it. And
this issue will get automatically closed when I merge the PR.
Although based on your description and the wireshark capture, it does seem
the problem in this case is that the device is simply not responding, so
the issue is likely in the device firmware or the adapter firmware. If you
have a Bluetooth sniffer, you can use it to see what is actually going over
the air to determine if it isn't being sent at all or if it is getting
dropped by the adapter.
—
Reply to this email directly, view it on GitHub
<#1280 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKXZUBXGGIUVOJNCD4AI6DXBVT7ZANCNFSM6AAAAAAW6PNFNM>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
The number 527 comes from Windows. The max PDU size for BLE in general is 512 bytes and there are 3 bytes of overhead, so in general the max MTU an OS should be requesting is 515 bytes. Not sure why Windows went with 527, but it is in the ballpark. If all of the firmware is the same, maybe there could be some sort of race condition or something going in to low power mode? |
As described in #1280, it is possible for a session to be closed then activated again while getting services. This will cause an OSError because the closed event triggers the disconnect cleanup code, then trying to use the session after that fails because it has been closed. This works around the problem by disabling the disconnect cleanup code until the connect method has returned successfully. If the connect method raises an exception, it handles cleanup already so the cleanup code in the session status event handler never gets called in this case.
As described in #1280, it is possible for a session to be closed then activated again while getting services. This will cause an OSError because the closed event triggers the disconnect cleanup code, then trying to use the session after that fails because it has been closed. This works around the problem by disabling the disconnect cleanup code until the connect method has returned successfully. If the connect method raises an exception, it handles cleanup already so the cleanup code in the session status event handler never gets called in this case.
bluetoothctl -v) in case of Linux:Description
I'm trying to figure out why I have a higher connect-success on one board and not another.
Same software on board, same software on PC.
I have two Silabs EFR32MG24 boards (efr32xg24 Explorer Kit, https://www.silabs.com/development-tools/wireless/efr32xg24-explorer-kit?tab=overview) for which I have difficulties (on both) in obtaining a connection.
For both, I get an OSError-exception when calling BleakClient.connect():
OSError: [WinError -2147483629] The object has been closed
However, for one board, I get much fewer of these exceptions, and for those I get, the verbose output from Bleak is somewhat different.
What I Did
This is my simple application - it tries to connect and disconnect again and again:
Running this against the "good board" (34:25:B4:A0:B8:0F) I get a connect success of ~95%:
15:31:53.950 [22312] __main__: [I] Stats: 119/125 successwhile the same test on the "bad board" (34:25:B4:A0:B1:CB) I get a connect success of ~73%:
15:43:15.176 [12684] __main__: [I] Stats: 33/45 successLogs
On the good board, there is one noticeable difference in the logs - there is always a series of ACTIVE->CLOSED->ACTIVE:
E.g. as here:
Whereas the bad board never exhibits this (the last ACTIVE is omitted):
Any idea on how to deal/proceed from here?
The text was updated successfully, but these errors were encountered: