I am trying to connect to Apple's Push Notification servers and push some notifications. All connections attempts are timing out. Tried pinging the server gateway.sandbox.push.apple.com and gateway.push.apple.com and they are not reachable. Are these servers alive and reachable? Can any body validate that they are reachable? Is it a regional problem?
I posted this question on the Apple forums but did not get any response. But, I figured it out myself after lot of experiments. Any requests to APNS, whether ping or connection requests, that are routed through proxies are filtered out in the transit and will never reach the APNS. This is probably done due to security concerns by the Apple guys. This means that any requests from your machines at your work locations will never go through as they are always routed through a proxy server. Any requests that sent through a direct internet connection without any intermediate proxies make it to APNS.
To test this you can tether your mobile 3G connection and share it with your PC/Laptop and then try connecting or pinging APNS and it should succeed. Your mpobile 3G connection is a direct internet connection. To get it working at your work locations ask your IT for a direct connection.
Update: It happened to be a firewall issue. Resolved after configuring the firewalls to allow connections to APNS range of IPs.
Related
I have a setup which involves devices connecting to a server via web sockets. I'm experiencing a strange problem where they can connect to one test server without issues, but cannot connect to a different server (hosted on Azure).
I've installed Wireshark on both of them, and can watch both the successful connection and the unsuccessful connection. It appears that the unsuccessful one attempts to initiate an SSL handshake.
Here is the successful connection:
Here is the unsuccessful connection:
It seems like the client in the successful connection is simply setting up an HTTP web socket, but in the unsuccessful setup it's try to set up a secure connection.
Why would the client be setting up different connections depending upon the server address?
The client code to create the websocket is just javascript, invoking new Websocket(address), and in both cases the address begins with the 'ws' prefix.
I have done some further investigation and found another weird behavior. As it happens, there are two domain names pointing to the same server.
If I used the domain name with the top level domain "com" (XXXX.australiaeast.cloudapp.azure.com), then the connection works.
If I used the domain name with the top level domain "dev" (comutername.mydomainname.dev) then the connection fails, with the weird TLSV1 packet.
Both works fine if I run the same client code on the Microsoft Edge browser.
This appears to be a defect in Chrome's implementation of The WebScoket API
I have posted a defect here, let's see how it goes. https://bugs.chromium.org/p/chromium/issues/detail?id=1067076
The issue in play here is HTTP Strict Transport Security (HSTS)
A browser can be configured so that certain domains have an HSTS policy attached, meaning any insecure link will automatically be converted to a secure link.
This policy will be applied if a request returns a Strict-Transport-Security header. But, and here's the significant bit, the Chrome and Firefox browsers automatically apply the policy to all dev domains.
It appears that up until recently, the Chrome browser and Chrome OS was not observing the policy with regard to WebSocket connections. This has changed, and now WebSockets will observe the HSTS policy.
The upshot is, if you have a websocket using the ws protocol and not the wss protocol, and it's on a .dev domain, your Chrome and Firefox browser will not be able to connect to it.
In short we have two separate servers for our web app. The first one is the main server that uses Websockets for handling "chat rooms", and the second server only handles WebRTC audio chat rooms via Websocket. Both servers use Express to create a HTTPS server, use secure Websocket and the port 443.
I recently encountered a problem where a corporate client's firewall blocked the wss-connection to only the WebRTC server. The error logged in the user's browser was "ERR_CONNECTION_TIMED_OUT", which means the user never connects via Websocket. This has not happened with any other clients.
The Websocket connection works normally between the user and the main server, and no rules have been added to their firewall to use our app.
Has anyone encountered something similar? What kind of a firewall setting might cause this? Could this be a cors problem, since the servers are on their own sub-domains?
The main server could be restricting the type of data sent on port 443, which will use SSL to secure that transmitted data.
Refer to this page for information on the "Well-know port numbers".
The WebRTC audio data may need to be transmitted on its own dedicated port number that has been configured on the main server for this.
The problem was that the main server WebSocket used TCP and the WebRTC server used UDP, and UDP was blocked by corporate firewall on default.
WebRTC should use TCP as a backup, but I'm assuming UDP is still needed for the handshake.
I know already about the web-sockets, and they are great, the problem with them is that they have to keep the connection open in order to be able to communicate.
I have a small system where from time to time the server has to update the status and notify the clients about that, and keeping the connection open from every client is not so optimal. At same time is very important that the update on the client side to be made just in time.
So my question is, if the server has a unique address does the client have a public temporary address where the server can send request? So when the client will connect to the server it will provide it's unique address and the server will cache it, and when there will be an update the server will send the request to that address?
I understand that there many problems as the address will constantly change, but this is already other question.
If client does not have a dedicated IP-address then it is not available from WAN unless it has an open connection with any node in it.
When client from local network sends request to a server it's (client's) router remembers client's local IP-address and port and translates it using NAT protocol to one of router's free ports and then sends data further with router's own 'IP-address of the sender' in IP protocol header and 'Sender's port' in TCP header. When router get's server's response it uses NAT table from it's memory to translate addresses back and deliver data to the client. Addresses are normally kept in NAT table while connection between server and client is open. So if there are no opened connections between server and local network client then server will not be able to connect with client because server does not know how to reach it.
You say you have a small system. Why then do you think that you will not have enough free ports at your server to work with websockets? If you just want to get updates from the server (not to both send and get data through a persistently opened connection) you'll probably find long polling or SSE more suitable. It is definitely easier to implement than websockets.
We are using tomcat websocket implementation in our web application. Messages are pushed from server to client through websockets. Web socket messages are not pushed when intermittant connection drop or network is switch over but still web application is connected.
Let say for example i am connected to LAN and logged in app, now i connecting through wifi after wifi successfully connected i am disconnecting LAN with in fraction of second network is switched from LAN to wifi But after this messages are not pushed from server to client through websockets.
After network switch if i check the state of the websocket(readyState) which says 1 which means websocket connection is open but actually its not.
Can anyone faced this issue earlier and provide your suggestions.
Thanks
You must create a connection drop detection mechanism. The WebSocket protocol has ping/pong frames, but I don't know if Tomcat has that functionality. In some Webscoket frameworks you can define a timeout interval, and the server will ping the client regularly, if the client miss some pongs is disconnected.
If that functionality is not provided by Tomcat, you can still create your own. Just define a special type of message and repeat it to the server from the client. If you do not get any of those messages for a while, disconnect.
I have a freeswitch based PBX that has been working fine. I was using Skype connect as a SIP provider and I have had no difficulty making and receiving calls using this. Also, no difficulty with internal local-local calls.
I have just changed my sip trunk provider to voip-unlimited (based in the UK) and updated my sip profile accordingly. I can receive calls fine with the new provider, but when I make a call, the other party can hear me, but I cannot hear them. I do not get a ringing tone when I dial out (the remote party's phone rings, he answers the call, he hears me, but I cannot hear him).
I have ports 5060 and 5080 open to both UDP and TCP traffic and the router also supports PnP. I am uncertain if it is a firewall issue but certainly no problems were experienced with Skype connect previously.
the best thing would be to run a packet sniffer (tcpdump or wireshark) and see what's going on when the call is set up.
It might be:
codec negotiation problem
firewall settings problem
NAT traversal problem
Ok, got it sorted.
I set the PBX back to using Skype Connect. I ran wireshark and could see the connection getting established over TCP and the RTP packets flowing to and from the PBX using UDP.
I then switched over to the new SIP trunk provider. I again ran wireshark, could see the connection getting established over TCP, but this time incoming RTP packets were not present.
I checked the router's firewall and all seemed fine. Nothing in the log files etc. I still suspected the router however. Upon googling for my router model (a Netgear WNR2200) I came across a setting to disable the SIP ALG (Application Level Gateway). I did this (disabled) it and problem solved. By the looks of things, the SIP ALG feature of the router was interfering with and breaking SIP. It is supposed to solve some NAT problems, but in this case its use was undesirable.