I am facing critical tunnel failure problem in Blackberry while testing in Blackberry device.
I am appending interface=wifi while i am making request in device,but it shows critical tunnel failure problem.While testing in simulator it not showing any error.
http://maps.google.com/maps/api/geocode/json?address=marine%20parade&sensor=false;interface=wifi
You may be connecting over MDS or even BIS in which case ;interface=wifi is not required.
This is further explained in this video:
http://supportforums.blackberry.com/t5/Java-Development/Networking-Transports-II/ta-p/446742
You may benefit from using the ConnectionFactory class in OS5 to avoid writing this sort of connection logic yourself.
Related
I'm currently developing a react native app in combination with a device. The device and the app communicate via BLE. So far everything works as expected but I'm having issues with the connection stability of the iOS app and the device. What would happen is that the device would connect and I can update some characteristics but it would regularly either disconnect with a CBErrorDomain 7 or the response for a write would timeout. The implementation on the app or device side does not seem to be the problem as Android works stable and the device also disconnects when connecting with the LightBlue app.
I've already updated the BLE connection parameters as suggested here:
https://developer.apple.com/library/archive/qa/qa1931/_index.html.
This has increased the stability but did not resolve the problems completely. I've tried playing around with the values but so far no luck.
The current set of parameters we are using are:
conn_min_interval: 15
conn_max_interval: 15
conn_latency: 0
supervision_timeout: 2000
adv_min_interval: 1285
adv_max_interval: 1285
My question now would be if somebody has an idea what other things I could check or which parameter to tune?
Are you checking the maximumWriteValueLength and making sure your writes are smaller than this? A likely cause of your problems is overwhelming the device and it fails to keep up with sending ACKs. What version of Bluetooth does your device support, and does it implement DLE (Data Length Extension)?
Your conn_min_interval and conn_max_interval are suspicious. Asking for 15ms with no leeway is likely to negotiate to 30ms instead. (See 41.6 Connection Parameters) Is your device comfortable with being re-negotiated to something other than 15ms? Can your device actually keep up with 15ms and no connection latency if it does get that? I'm betting it can't. Try setting your connection interval to 30ms (or even a bit slower), and you might even try setting your connection latency to 1 to make the connection a bit more forgiving (though I'd focus more on slowing the CI than increasing latency; increasing latency would be more of a hack in this case).
All my suspicions are around your peripheral not keeping up with its side of the connection. If you have any synchronous activities in response to the data, you need to make sure that it's not blocking your BLE stack from sending the required responses.
Finally, I've found the answer to my problem. The problem was that the pairing procedure of the BLE server was faulty and thus iOS was unable to have a stable connection. Now that this is fixed the connection is very stable.
I'm still unsure why iOS was able to have any communication at all without the pairing but I hope that this helps some people in the future.
I have an issue regarding Twilio Javascript SDK and stuck in a
situation where the issue directly involve IOS and RTC support. Right
now, i cannot connect the twilio device after device is ready. There
is no error or anything to track/debug.
Constantly, running the connection.status() return back connecting always. I think the signaling system works when there is an incoming call but again, connection.accept() and status remain connecting like forever.
Application Overview
Cordova/Phonegap app
https://media.twiliocdn.com/sdk/js/client/releases/1.6.9/twilio.min.js
shim:https://webrtc.github.io/adapter/adapter-1.0.2.js
https://github.com/BasqueVoIPMafia/cordova-plugin-iosrtc
Possible reasons: Can this be directly CSP issue? or I have you setup configuration using STUN/TURN?
Let me know if you need any information. It's not going to resolve because there is no error just "connecting" status.
I have a PC and an iOS device. the iOS device is using alljoyn 15.04 and the PC is using alljoyn 15.09. Both implement the same secure interface. We have secure signals as a part of this.
Our strategy includes joining a peer's session as soon as we discover them, then forcing authentication by calling a method on the remote device - using auth mechamism: ALLJOYN_ECDHE_PSK
This all works great!
Now, I can send a secure signal just fine from one ios device from another.
I can also send a secure signal from the iOS device to the PC just fine.
The PC can send a secure signal to another PC, but it cannot send a secure signal to the iOS client
We've compared everything - session options, interface names/options, bus connection options, etc. and everything is the same. Then I found this error in the alljoyn log on the iOS side:
145.449 ****** ERROR ALLJOYN iodisp2_2 .../src/Message_Parse.cc:1078 | Failed to read message on :wYxt8HAP.73: ER_OS_ERROR
I have no idea what to do about this. Can someone help?
I was hoping to not run into any lower level bugs like this with alljoyn. Dang.
Thanks for any help!
This error can occur if you are trying to send a secure signal out on session 0 (sessionless) instead of a valid hosted session. This is because the other end cannot decrypt the signal with your group key for the session. If you are hosting the session then try sending the signal out on ajn::SESSION_ID_ALL_HOSTED and see if that works.
I have an issue with a single (at least for now) iPhone not being able to connect to websockets. Unfortunately I don't have access to the device and I can't run more tests on it at the moment, so no proper network dumps or anything else deeper level debugging available. Can't test on other network connections either at the moment.
Everything works perfectly with Chrome 45, Firefox 40, Chrome 45 on Android (many devices), Safari on iOS9 (device A), Safari on iOS8 (device B) etc. No errors, no cutoffs, nothing. Just works.
My websocket server runs on IIS 8.5 / ASP.NET, created as an API controller with the typical way (PullHandler is an async Task whileing until connection closes)
if (HttpContext.Current.IsWebSocketRequest)
{
HttpContext.Current.AcceptWebSocketRequest(PullHandler);
return Request.CreateResponse(HttpStatusCode.SwitchingProtocols);
}
else
return Request.CreateErrorResponse(HttpStatusCode.BadRequest, "Bad request");
This should not cause any issues, especially this one. The client side JavaScript is also the simple
new WebSocket("ws://" + window.location.host + "/api/Some/Endpoint);
I am using plain HTTP, no SSL/TLS.
When trying on iPhone device X with iOS9 (13A344, not entirely sure of which model) it just can't get the connection. I am also using SignalR which automatically goes into longPolling transport on this device. With others it's nicely on webSockets transport.
Quick testing on UK Orange 3G connection showed on my HTTP logs that for some reason the request for my endpoint has gone to the else branch, like something had stripped the upgrade headers away.
GET /api/Some/Endpoint 80 - Mozilla/5.0+(iPhone;+CPU+iPhone+OS+9_0+like+Mac+OS+X)+AppleWebKit/601.1.46+(KHTML,+like+Gecko)+Version/9.0+Mobile/13A344+Safari/601.1 - 400
Status 400 is clearly showing the bad request that my code is sending if the request is not a proper websocket request. I don't know if there could be some transparent proxy, that could explain this. The 400 response was received without any delays.
But this was a problem also through wifi on the same device. Again, a laptop with OS X and Safari had no issues on the same wifi to connect to SignalR and my websocket server. Only the iPhone had issues. On wifi I didn't get any attempts to connect on the logs and SignalR also immediately went into longPolling transport. The wifi apparently used Virgin Media's network based on IP address.
On wifi there is first an open event. Then after some time there is a close event with status 1006, which is abnormal termination without a close packet. My code tries to connect again and the same happens. Strangely there is no log entry at the web server, but it might just be Safari's way to post the open event even though an actual connection was not established and after a timeout it sends the close event.
The device should not have any proxies set up and other browsing works without issues. Unfortunately I couldn't get any information about any other site that would use websockets working or not on that device.
Has anyone run into this kind of situation? I do understand that the 3G might just be a misbehaving proxy, but the wifi issue cannot be explained with that.
Just want to expand the universe for this issue.
I Have an app that runs great in simulator. App has both http Jason IO and web socket IO.
Now that I can target my iPhone and not the simulator. App on iPhone successfully does the http Json stuff but not the web socket stuff.
While I am not using safari and js my symptoms are very similar to yours. I am using Xcode 7 to generate code that targets to iPhone 5 using iOS 9.0.
Calling
Connector.open("http://MySpecifiedURL.com;deviceside=true;apn=rim.net.gprs");
Throws IOException: "peer refused the connection".
This happens only with few specifies URLs, that used for web services and only on BlackBerry OS 6, on other OS versions (5.0 and 4.*) and with other URLs everything works correctly. Can somebody help me with understanding why this happens?
A "peer refused the connection" error occurs when the server doesn't like something about the connection, i.e. you didn't supply the right userid/password to the APN, or there's nothing listening at that port. My first try would be to drop the apn= part of the connection string.
But if I were you, I would switch to using Versatile Monkey's networking helper class which will find the best TCP connection path for the device, regardless of OS version. It will let you handle the cases where devices are paired with a BES or not, if Wi-Fi is available, etc. It's really easy to use and solves a lot of connectivity problems that BB developers face given the mix of devices out there with BES, BIS, Wi-Fi, etc.
The definitive answer to this subject I found it in "Apress Begining Blackberry Development Nov.2009".
From page 186 to 190 more or less... they throw out a perfectly written code for this... you invoke this Method they define and it will return the extra parameters needed to make a proper request depending on the network availability.
I cannot paste the code here since that would be illegal.
Cheers!.