cwa-app-ios
cwa-app-ios copied to clipboard
Twitter Report: Error 13 followed by NoExposureWindows
Avoid duplicates
- [X] Bug is not mentioned in the FAQ
- [X] Bug is specific for iOS only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository
- [X] Bug is not already reported in another issue
Technical details
- Device name: Can be requested
- iOS version: Should be in the error log
- App version: Should be in the error log
Describe the bug
A Twitter user is reporting that he experiences Error 13 followed by the error code NoExposureWindows, then again error 13 and so on.
Steps to reproduce the issue
Not entirely clear.
Expected behaviour
No errors.
Additional context
Please investigate the following error report: ID 59F2DC1731B868040633 @thomasaugsten ref https://github.com/corona-warn-app/cwa-app-ios/issues/2602#issuecomment-1101779280.
JIRA https://jira-ibs.wbs.net.sap/browse/EXPOSUREAPP-12878
No network connection
ErrorLocalizedDescription: Es besteht anscheinend keine Verbindung zum Internet.
Error: Error Domain=NSURLErrorDomain Code=-1009 "Es besteht anscheinend keine Verbindung zum Internet."
UserInfo={NSErrorFailingURLStringKey=https://svc90.main.px.t-online.de/version/v1/diagnosis-keys/country/EUR/date/2022-04-19/hour, _kCFStreamErrorDomainKey=1, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <0BEE4106-734B-4157-B67C-DCB182607AF2>.<1>, NSURLErrorNetworkUnavailableReasonKey=1,
_NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <0BEE4106-734B-4157-B67C-DCB182607AF2>.<1>"
), NSLocalizedDescription=Es besteht anscheinend keine Verbindung zum Internet.,
NSErrorFailingURLKey=https://svc90.main.px.t-online.de/version/v1/diagnosis-keys/country/EUR/date/2022-04-19/hour,
NSUnderlyingError=0x281d6f6f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)"
UserInfo={NSURLErrorNetworkUnavailableReasonKey=1, _kCFStreamErrorDomainKey=1, _kCFStreamErrorCodeKey=50,
_NSURLErrorNWPathKey=unsatisfied (Expensive path prohibited), interface: pdp_ip0, ipv6, dns, expensive, constrained}}, _kCFStreamErrorCodeKey=50}
It looks like a network issue wich disturb the connection or/and the https handshake Maybe switch to mobile data or wifi
@thomasaugsten
Thanks, I relayed this to the user.
@thomasaugsten
The user is able to access coronawarn.app without problems via wifi. So there seems to be no problem with the connection in general. I asked him to try it via wifi, but as he now sees Error 13 again, the result might take until tomorrow.
BTW, I think this is the clearest indication that Apple actually counts unsuccessful risk checks agains the rate limit.
More important are https://svc90.main.px.t-online.de/version/v1/diagnosis-keys/country/EUR/date
To retest this he has to wait 24h Yes unfortunately there is no plan to change the counting
@thomasaugsten So should he try to access this URL, would this help in any way?
To retest this he has to wait 24h
Yep, he said he started logging again and will try tomorrow with LTE
Yes unfortunately there is no plan to change the counting
Ok, thanks for the information, appreciate it!
@thomasaugsten New Error Report of a risk check carried out via LTE: ID 7EF1FF70C66E6963AD51
Same error for https://svc90.main.px.t-online.de/version/v1/diagnosis-keys/country/EUR/date/2022-04-21/hour
Error 2022-04-21T05:14:58Z
[ENA/URLSession+Convenience.swift:62] [response(for:isFake:extraHeaders:completion:)]
No network connection
ErrorLocalizedDescription: Es besteht anscheinend keine Verbindung zum Internet.
Error: Error Domain=NSURLErrorDomain Code=-1009 "Es besteht anscheinend keine Verbindung zum Internet." UserInfo={NSErrorFailingURLStringKey=https://svc90.main.px.t-online.de/version/v1/diagnosis-keys/country/EUR/date/2022-04-21/hour, _kCFStreamErrorDomainKey=1, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <989F0A7A-2B98-4144-8D90-BAA53C12D56B>.<1>, NSURLErrorNetworkUnavailableReasonKey=1, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <989F0A7A-2B98-4144-8D90-BAA53C12D56B>.<1>"
), NSLocalizedDescription=Es besteht anscheinend keine Verbindung zum Internet., NSErrorFailingURLKey=https://svc90.main.px.t-online.de/version/v1/diagnosis-keys/country/EUR/date/2022-04-21/hour, NSUnderlyingError=0x2836c25e0 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={NSURLErrorNetworkUnavailableReasonKey=1, _kCFStreamErrorDomainKey=1, _kCFStreamErrorCodeKey=50, _NSURLErrorNWPathKey=unsatisfied (Expensive path prohibited), interface: pdp_ip0, ipv6, dns, expensive, constrained}}, _kCFStreamErrorCodeKey=50}
Which leads to an unparsable protobuf
ExposureDetection: End prematurely.
ErrorLocalizedDescription: Während der Risiko-Ermittlung ist ein Fehler aufgetreten. Code: NoExposureWindows
Error: noExposureWindows(Error Domain=NSOSStatusErrorDomain Code=-6732 "(null)" UserInfo={cuErrorMsg=Unsupported protobuf type: 4}, date: 2022-04-21 05:14:59 +0000)
@thomasaugsten Okay I asked him to access https://svc90.main.px.t-online.de/version/v1/diagnosis-keys/country/EUR/date manually and let me know if this works.
@thomasaugsten The URL is reachable via WIFI and LTE. Seems like a problem with the CWA.
@thomasaugsten FYI: User reinstalled the CWA and now it works flawlessly again. Another indication that this was not a fault with the connection/internet but with CWA itself.
Hi @Ein-Tim I will forward this to the internal ticket, thanks for the feedback.
BTW, I think this is the clearest indication that Apple actually counts unsuccessful risk checks agains the rate limit.
@Ein-Tim To be more precise: this indicates that there are some error codes that count against the rate limit. Unfortunately, no Apple documentation is available with more details.
For this reason, any assumptions how this rate limit is implemented exactly inside the ENF would be guesswork only. Even if we observe this for a specific error code: Apple could implement that differently in their next iOS version; and even in the current / observed versions, there could be extra conditions / a logic with an if - else that we don't understand...
With all this, I think the current handling of ENF error codes in cwa is the best we can get: Just try and let Apple / the ENF handle the errors. Suppression of an error message for error 13 is needed with this philosophy as we have seen; but else it works quite well.
User reinstalled the CWA and now it works flawlessly again.
@Ein-Tim do you happen to know
- if the user tried to swipe cwa out of memory before that?
- if the user tried to reboot the device before that?
Just a few suggestions that have worked for me in some cases, and are less "destructive" than a complete reinstallation.
@ndegendogo
I asked the same questions the user and he said he has already done both.
@thomasaugsten Maybe a related issue: If there is a problem with the network encryption, the risk check also fails without any helpful error message. I recorded such a problem in the error log with the ID: 073ECE605FE6D8CAB6AE
User reinstalled the CWA and now it works flawlessly again.
@Ein-Tim do you happen to know
- if the user tried to swipe cwa out of memory before that?
- if the user tried to reboot the device before that?
Just a few suggestions that have worked for me in some cases, and are less "destructive" than a complete reinstallation.
Yes, I tried both two times without success.
Effort is ok, the app is pretty good (just export the certificate before and import again afterwards). 5min and the warnapp was working again 👍.
@maximilianG1 maybe your collected exposures got lost when you reinstalled cwa
@ndegendogo yes they were deleted. but collecting it with an app which doesn’t work makes also no sense 😂
Looks like not many people have the same issue, so I think installing it again is an acceptable workaround.
@maximilianG1 Did you try to reset the app over the settings?
@maximilianG1 Did you try to reset the app over the settings?
no, I didn‘t tried that.
@maximilianG1 @Ein-Tim thanks for reporting the issue!
The error message Unsupported protobuf type: 4
seems to hint at the Protocol Buffer type sint32
. In ENF, this is only used for the attribute days_since_onset_of_symptoms
(see docs).
Unfortunately, it's unclear from the logs why ENF raises this error.
There are other suspicious entries in the logs, such as that the quota of the rate limit (i.e. 6 exposure detections per UTC day) did not seem to be reset after midnight UTC.
Overall, it looks like ENF somehow got into a rogue state but there's not enough information in the log to trace back how/why and we haven't managed to reproduce it.
I'm afraid that with just a single occurrence of this particular error and unclear root cause, we cannot fix this.
Closing as not enough information for a fix is available.
@maximilianG1 @Ein-Tim thanks for reporting the issue!
The error message
Unsupported protobuf type: 4
seems to hint at the Protocol Buffer typesint32
. In ENF, this is only used for the attributedays_since_onset_of_symptoms
(see docs).Unfortunately, it's unclear from the logs why ENF raises this error.
There are other suspicious entries in the logs, such as that the quota of the rate limit (i.e. 6 exposure detections per UTC day) did not seem to be reset after midnight UTC.
Overall, it looks like ENF somehow got into a rogue state but there's not enough information in the log to trace back how/why and we haven't managed to reproduce it.
I'm afraid that with just a single occurrence of this particular error and unclear root cause, we cannot fix this.
see https://github.com/corona-warn-app/cwa-app-ios/issues/4676#issuecomment-1188750849 for follow-up analysis
the quota of the rate limit (i.e. 6 exposure detections per UTC day) did not seem to be reset after midnight UTC.
@mlenkeit does Apple really specify midnight UTC? It could as well be a "rolling" 24-hour interval ...
the quota of the rate limit (i.e. 6 exposure detections per UTC day) did not seem to be reset after midnight UTC.
@mlenkeit does Apple really specify midnight UTC? It could as well be a "rolling" 24-hour interval ...
@ndegendogo it's indeed rolling according to the docs.
As the CWA project went into ramp-down mode, I don't expect any more new findings on the root cause of this issue. I'm therefore closing this issue.