What network services, port numbers, outgoing incoming or both, need to be open on a network for an ipod touch to receive Apple Push Notifications?
I know the outgoing port number to set when sending the apns. The only thing is, in my school practically every outgoing (and incoming) port is blocked and as a result APNs do not work. I am sure that if I talked to my network administrator and told him which port to unblock, he would do so. So my question is: What network services, port numbers, outgoing incoming or both, need to be open on a network for an ipod touch to receive Apple Push Notifications?
According to Apple's docs: port 5223.
If the device is connected over Wi-Fi
and is still unable to receive
notifications, the Wi-Fi network
you're using might have a firewall
that is blocking port 5223. This port
must be open to TCP traffic for
notifications to work.
For APNS to work from within your network you must be able to communicate to 17.0.0.0/8:5223. The TCP connection is made from iOS device out to *.push.apple.com. There is no inbound TCP connections required.
Related
if when i try to connect with webRTC from outside the local network, it uses a STUN server to exchange info like ip address, port..., and then once the two clients know each other they will directly connect, but the thing is, if any router by default blocks any port that's opened exept for 80, then how do the two clients connect, on what port?
WebRTC is an open framework and does not dictate how the connections are established between the communicating peers. Establishing the connection itself involves the following.
1-The peer discovery is made via Signaling for doing SDP exchanges and exchanging remote host identities. The Signaling can be done over any transport – UDP/TCP, any protocol and via any standard (SIP/XMPP) or custom application level protocol over HTTP/WebSockets etc. The choice of Ports for signalling traffic is left open to the application developer.
2-Once the peer discovery is complete, and the PeerConnections are established at each endpoints, the media data can be sent. Depending on the network topology of the Peers (whether they are in the same host network, or they are in different network (behind Nated IP address), they can choose to connect such that the media traffic is sent over UDP or over TCP. For a more protected environment, the peers may even need a TURN server to relay the media traffic on Peers behalf. Here again, the choice of Media Ports is left open and can be decided via the end application.
I found this on web I hope its helpful
I am able to access to my IOT device if I assign it a static IP with a service like dydns. But I would like to be able to reach it without relying on something.
I was thinking that my IOT device could ,on every start, write in a database its IP adress so my script on the server knows its ip.
The problem is that the IP will correspond to my hotspot IP. I am missing the connection part "hotspot -->IOT device".
For example I would like to be able to connect my IOT device to my mobile phone in hotspot mode.
One way to do this would be to re-design your system: if when it comes online the IoT device always connects (and stays connected) to a server component (which has a well-known/unchanging hostname/IP address), then the server can always send the IoT device a command over that TCP connection without knowing the hostname/IP address of the IoT device, and without it having to be contactable from the internet, i.e. this approach is firewall-friendly at the device end.
This is how the IoT is architected when using e.g. MQTT: devices connect inwards to the MQTT broker (i.e. server). MQTT also removes the need for the server application itself to need to connect to the clients. MQTT uses a concept called publish/subscribe with pre-agreed 'topics' - the client will subscribe to a 'command' topic, the server app publishes commands to that topic and the broker handles forwarding the command to the device. Incoming data from the device is published to another topic and the server application subscribes to that topic, the broker forwards the published data. You can try pub/sub example (using a browser, but real devices can also connect to the same server) using e.g. http://m2m.demos.ibm.com/utilities.html
According to the documentation, these are the ports to be opened on a firewall to send notifications from a server, but it is unclear whether to allow the inbound and outbound connections in the firewall or only outbound connections:
For push notification to be sent, the following servers must be accessible from a MobileFirst Server instance:
iOS
Sandbox servers:
gateway.sandbox.push.apple.com:2195
feedback.sandbox.push.apple.com:2196
Production servers:
gateway.push.apple.com:2195
Feedback.push.apple.com:2196
1-courier.push.apple.com 5223
Android
The ports to open are: 443, 5228, 5229, and 5230. GCM typically uses only 5228, but it sometimes uses 5229 and 5230.
GCM does not provide specific IP addresses, so you must allow your firewall to accept outgoing connections to all IP addresses that are contained in the IP blocks listed in Google ASN of 15169.
Windows Phone 8
No specific port needs to be open in your server configuration.
MPNS uses regular http or https requests.
Both incoming and outgoing...
As an example, which will apply to all vendors, see Apple's support document: https://support.apple.com/en-ap/HT203609
If you have iOS devices inside your network, then for the devices to receive the notification you must have the following available for incoming connections:
For APNs traffic to get past your firewall, you'll need to open these
ports:
TCP port 5223 (used by devices to communicate to the APNs
servers)
TCP port 2195 (used to send notifications to the APNs)
TCP port 2196 (used by the APNs feedback service)
TCP Port 443 (used as a fallback on Wi-fi only, when devices are unable to communicate to APNs on port 5223)
The APNs servers use load balancing. Your devices will
not always connect to the same public IP address for notifications.
The entire 17.0.0.0/8 address block is assigned to Apple, so it's best
to allow this range in your firewall settings.
And since apple's servers have a specific range and ports, you need them open for outgoing connections as well...
I am new to network programming and try to understand managing traffic via TUN/TAP interface.
Since I have almost nonexistent system programming skills, and feel confident on Java; I use OpenVPN tun/tap driver and ready made Java binding for it. It works on TAP mode.
As an example application I am trying to imitiate no encryption, no authentication client server VPN application.
I can catch Ethernet Frame packets, but for the routing part, I failed miserably. (I can modify route/arp tables.)
Do anybody know how OpenVPN send packets from client to server, and from server to target. Opening sockets from Java looks like an alternative; but I was hoping that modifying packets(change IPs and/or MAC addresses) and writing back to the virtual tap interface would be enough. Is it so?
Can I inject packets to send other locations, or by default received packet moves towards application layer?
-- Edit:
Scneario
Client Tap0 _____ Server Tap0 ______ Target
Eth0 Eth0
Target: Ping from client, move through tap interfaces, target see only server ip (anonymization)
What I achived so far.
Catch traffic at client tap0 interface.
I coulnt forward traffic at server Tap so to fasten things I used Java socket programming between client-server.
Now I read packets from socket at server, and try to OpenVPN Tap driver's write method to move forward but I am not sure where do I fail. I see packets with tcpdump at server tap0, but they do not pass to server eth0.
My most important question is if I modify packet(ip, mac address) and call write method, is it possible that packet moves forward. (Or does it move to application layer whatever you change??)
Any help would be appreciated.
1. Routing is a Layer 3 (IP) problem and handled by the OS. As for the Ethernet frames on Layer 2, you have multiple options. In any case, you'll have to parse the incoming packets' headers and extract the MAC address, and decide based on the MAC where to pass the packet: To a specific client, all clients (broadcasts) or the local tap interface.
Option 1: On each client, use a tun device, and let the server use a tap device. Assign pseudo MAC addresses to each client, respond accordingly to ARP requests from the server's OS and let the OS on the server take care of the rest. Applicationwise, you'll only have to forward all incoming packets to the tap device and all outgoing packets to the client to which you assigned this MAC.
Option 2: Let the clients choose their own MAC address and forward ARP-requests through the network. The server application has to decide for incoming packets from a client whether to forward the packet to a client, or send it to the local tap device if the address matches the local device's MAC.
In both cases, clients pass all packets from their local tun/tap device to the server and vice versa.
2. You can do almost anything. A packet is only "received" when you decide to write it to the tap device, and you can of course temper with any packets, or inject new ones, ...
As a final comment, I've found that toying with tun devices is conceptually simpler, because they work on Layer 3. You'll have to open a tun device on the server for each client, but within your application you'll have to do nothing but to forward anything coming from the device to the single client, and vice versa.
I am trying to send data using the AsyncUDPSocket class. And I can send data using the iPhone simulator over the wire to another machine that is running a simple C-coded listening server. I can also receive data over the wire using a client connected to the simulator(server). However, when I tried the same over Wifi, using the simulator, I could only send data but not receive any data.
I read on another post, that unicast data makes this possible. How can I acheive this using AsyncUDPSocket?
Thanks,
Angelo.
Ok, I figured this out. A newbie kind of thing, really.
When I set my Mac network preferences to Ethernet, I get an IP for me to communicate. However, when I turn Airport(Wi-Fi for more newbies) ON, and ethernet cable disconnected, I checked my network preferences, and sure enough my IP address was a different one.
Spoke to a friend (an ace in networking) and the thing clicked immediately: On WiFi networks a DHCP server allocates an IP address. This IP address has to be reserved, at the very least, at the DHCP server. Since my IP was not reserved, I had to change the IP address, in my udp_client.c file, recompile and run the client to connect.
BTW, I can now communicate between my iPhone and my PC using my local WiFi (office) network.
For any who might face the same problem, do not be assured that the IP address of your mchine is the same, when you switch from LAN to Wifi, and use the device mostly for WiFi reated testing. :)