Background: I have created a hybrid app in angular using the capacitor library. Everything is working well for the browser and the android mobile app and the iOS mobile app. On the backend, we are using hardware that is acting as a server. The hardware and our mobile are connected to the same router and we are accessing the hardware using an IP address. Also, we have added a self-signed certificate on the hardware and are using HTTPS while communicating with the hardware.
Bug: The only issue we are facing right now with the iOS app is its slowness. I did some digging around the frontend using Wireshark and came to a point where the iOS app is sending the acknowledgment packet followed by an encrypted alert packet when it receives a response from the server. This is happening for every request. After further debugging on the server end I came to know that once it receives an encrypted alert it is closing the socket. Then again it is performing session handshake, opening the socket again and then processing the request. So, basically, the below process is repeated every time:
Performing session handshake
Opening Socket
Processing request
Sending response
Closing the Socket
On the contrary, on an android device, this process is only happening the first time it sends the request and then data transmission is taking place without closing the socket.
Below are the screenshots of Wireshark for Android and iOS:
iOS Screenshot:
Android Screenshot:
Related
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.
Apologizing in advance, I am no 802.11 expert and this is a long winded question...
I am working on an iOS voip client, we use the Cocoaasyncsocket library for our TCP/UDP connections. The app/iDevice is allowed to roam in/out of wifi coverage (for the purposes of this discussion we will assume the app is using wifi only... no cellular connection). We have the appropriate plist settings for backgroundmode (voip, audio) as well as requiring persistent wifi.
We are having a problem that seems particular to Cisco AP's. With the client app in the foreground and roaming out and in of wifi range, we noticed that eventually the iOS device will eventually not automatically rejoin the network. After a great deal of debug the failure to rejoin was noted to have nothing to do with the app. The failure to re-join can ultimately be reproduced by forcing the AP (via config) to deauthenticate the iDevice three times. After the 1st and 2nd deauthentications, the iDevice readily automatically re-joins. But after the 3rd time, iOS does not automatically rejoin the network.
The network will be rejoined if, for example, the iOS email app is put in the foreground.
We were curious if any other VOIP type apps suffered this problem, and ran an experiment with running FaceTime and Skype on the iOS device.
Skype behaved much like our voip app, after the 3rd deauth the connection was lost. Trying to initiate another call resulted in a message to the effect of "must have an internet connection to make a call".
FaceTime did disconnect on the 3rd deauth and failed to automatically rejoin... however, we were able to re-initiate another FaceTime call which caused iOS to rejoin the network and make the call.
We would like to emulate the FaceTime behavior, but so far do not understand what we should be doing differently. To the best of our knowledge, we are properly closing the open sockets when we get disconnected. Is anyone familiar with this issue and have some insight to offer?
I have a voip app for ios, based on webrtc. I also have a signaling server made with nodejs. I can connect to the server and make calls without a problem. But tracking presence (online/offline) accurately is a problem.
Just for the record, here is a list of everything I did to ensure a stable connection:
Set the background mode "Voice over IP"
Flag the inputstream as a voip stream with "[inputStream setProperty:NSStreamNetworkServiceTypeVoIP
forKey:NSStreamNetworkServiceType];"
Turned on persistent wifi by setting "UIRequiresPersistentWiFi" to YES in the plist file
I implemented "setKeepAliveTimeout:handler:" and I use it to send a ping to the server (unnecessary, but you never know...)
I created a small test app that does nothing more than connect to the server and respond to "ping" with the message "pong". This app sends "ping" to the server when the keep alive timeout handler fires and the server replies with "pong". I also created a simple test server that does nothing more than let clients connect, send "ping" to a client when I send "send_ping" to it via telnet and responds to "ping" with the message "pong".
Here is my client code
What I expect is the following:
Starting the app and signing in should create a persistent connection to the server (works)
Telnetting into the server and typing send_ping makes the server send "ping" to the client and the client should send "pong" back (works)
Putting the device in standby should have no effect on the above ping-pong mechanism (doesn't work)
Putting the device in standby and unlocking it after a few hours, then sending a ping to it should make the client send a pong back (works)
Turning off wifi on the client (without cellular enabled) should be detected on the server-side and kill the socket (doesn't work)
I log all messages from the server in a textview on the client with a timestamp, and sometimes when I put the device in standby the pings I send from the server just don't arrive at all. Sometimes it takes over a minute for the app to receive the ping message, sometimes it responds immediately. I don't understand why it is so random. Sometimes this undesired behaviour starts after mere minutes in standby mode, sometimes it goes alright for a while but breaks after 20+ minutes, sometimes all messages from the server arrive at once as soon as I unlock the device.
Push notifications and voip push notifications could be a solution, but they are also slightly unreliable. There should be a way to make this work 100% of the time.
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.
Am using open fire server and iOS xmpp client with Robbie Hanson's framework. My clients runs fine in background, as i have set the voip flag and everything. But after few hours around 15-20, it automatically gets disconnected. Am not sure why it's happening and why it is taking such long duration. I am not sending any messages or receiving any. The ping interval is 360 secs to which my client responds with an error, which is acceptable form of response to remain connected to the server. Anyone got the same issue ?
Openfire server: 3.8.1
iOS version: 6.1.2
Did you try using the setting "Do Not disconnect clients that are idle" available in Server Settings> Client Connections in Openfire server?