I'm working on an app that relies heavily on P2P, but I currently don't have any SIM cards with which to experiment so I'm testing on a wifi network.
I'd like to know if iPhones on 3G networks are connectable and whether or not I will need to traverse NAT devices.
You're behind the provider's router and your IP address will be something like 10.x.x.x - so you'd have the tell the router, that a TCP connect from the internet to port 9420 should be forwarded to your device. I doubt that they will do this for you.
Related
A couple questions.
TLDR is sending UDP broadcast packets on a Wifi network to allow for discovery of a IoT device (Raspberry PI) a conventional practice?
Long version: I'm working on an IoT project for a class. Based on other IoT devices I've used (a Christmas carol lighting system and music player), we decided to utilize an already working application (https://github.com/balena-os/wifi-connect). The way it works is it runs on the Raspberry PI and hosts a wifi endpoint through the RPI's network card that the user can connect to. Once a user connects to this Wifi endpoint on his/her Iphone, a Wifi selection and password entry page appears on his/her Iphone. The user enters the Wifi/password that the IoT device (Raspberry PI) should connect to. The entered Wifi will then be connected to by the Raspberry PI. The user can then connect to the entered Wifi as well and now both the user's Iphone and Raspberry PI will be connected to the same Wifi network.
We decided to send UDP packets to the broadcast address of the Wifi network from the IoT device, so that users connected to the Wifi (via their Iphones) can "discover" the IoT devices IP address by listening for UDP packets. Once the user discovers the IoT device's IP address, they can send HTTP RESTful API calls to the IoT device. I was wondering if the described process is conventionally used.
# script we are using to send UDP broadcast packets
import socket
import time
server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
server.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
server.settimeout(0.2)
message = b"message"
while True:
server.sendto(message, ('<broadcast>', 16123))
time.sleep(1)
We tried this setup at a public library, using their free public wifi. However, the UDP broadcast packet discovery process failed. UDP broadcast packets were sent out by the IoT device, but were not received by the Iphone. We're wondering if this has something to do with a firewall. We could successfully send UDP broadcast packets from a Macbook (via a python script) to an IOS emulator residing on the same Macbook, such that the source IP address of the packet was the same as the recipient. Is there a firewall rule such that a broadcast packet sent from IP address [A] can be delivered back to IP address [A] but not to IP address [B].
Also, I didn't mess around with the port number, which might have helped if certain ports were disabled by a firewall. I'm not sure. Help is appreciated. We are both relatively new to this.
DNS-SD (RFC6763) is the a fairly common and standardized way to do network discovery. It actually supports both TCP & UDP services. It was originally invented by Apple under the brand name "Bonjour" for printer discovery.
So yes, it is common to use UDP broadcast packets (via DNS-SD) for IoT device discovery on a Wifi network.
I have local server running in my local network.I want to enable external devices to make request to my local server in this case i am testing with android phone on cellular network.For this I am trying to do UDP hole punching.First I am sending http request from the mobile device to public server to give the public server mobile device's information(IP and Ports) so that i can use them to punch a UDP hole in my local server.But the problem is i am getting NAT public IP & public Port and only local IP of the mobile device but not Local Port.And I just learned that cellular network wont let you use mobile local ports.The question now is how would i accomplish UDP hole punching in this case? If there is anything that i mis-stated please correct me.Thank you in advance
I am developing an app that sends Multicast UDP packets to discover devices running the same app in the same local network, using the address 224.0.0.1 and the port 8875. It worked perfectly until a few days ago I replaced my wireless router and found that with the new one I am unable to receive the multicast traffic. Seems like the router is blocking intentionally that traffic, and while I'm sure I can tweak some options to unblock it, obviously I'd like my software to work out of the box on any wireless network.
I haven't been able to find any documentation about what traffic do exactly wireless routes filter by default (I assume there is not a convention and depends on the manufacuturer), so I was hoping someone could give me any guidelines/clues about what traffic is "safe", and what will be probably get blocked.
I use Linphone(http://www.linphone.org/) open source to make a mVoIP android application using Asterisk Server. It is working nicely when the smartphone is on 3G or 4G(LTE) network. However, it failed to register when it is on Wi-Fi network.
Via and Contact info was wrong for smartphone that is on Wi-Fi network.
A = Smartphone on Wi-Fi network
B = Smartphone on 4G(LTE) network
It delivers sounds to B phone from A phone. However, it failed to deliver sound from B phone to A phone.
I traced SIP logs and noticed that phone A tells wrong private IP address(contact) to Asterisk server. It was why it failed to listen sound on phone A.
So, I turned on Stun server, which I have to connect specific stun server, it hardly finds local IP address through NAT. The problem was that Linphone itself cannot find a private IP address of smartphone A that is on Wi-Fi network.
C = A third smartphone on Wi-Fi network.
Another problem that I faced is that an additional smartphone on same Wi-Fi network is not working even though Stun server solved its NAT problem.
Is there anyone who had same issue? and is there a way to solve this issue? Thank you.
You have
1) enable STUN
2) in asterisk set directrtpsetup=no for BOTH peers.
I'm writing a C# remote control for my media player. It runs on my Android phone.
I have a client app listening for TCP connections on my computer which, one a connection has been established, processes commands (Volume up, volume down, ...). I've tested that part using telnet 127.0.0.1 on my computer, and it works great.
Things are trickier when it comes to connecting from my phone, since it's not on the same network (I don't have Wi-Fi, only wired connections), so I'm not sure how to proceed. Basically I want to connect to a computer that's behind a router.
Should I rather host the TCP server on my phone, and have the PC connect to it? Take IRC as an example: although I'm behind a router, I can connect to servers outside, without port forwarding.
Or if hosting the server on my computer is fine, how do I connect to it?
I don't understand everything to this yet, so feel free to correct me if I got something wrong.
It would be more logical to keep the PC hosting the server, and configure your router to forward connections to your PC. You have two options:
Establish a DMZ: all incoming connections on the router will be forwarded to one PC only. This is easiest when you only have 1 PC on the network that needs to accept connections.
Configure port forwarding: you can instruct the router to forward connections incoming on port X to the IP Y on port Z. This way, multiple PC's can listing for connections (using different ports on the router). It is also a bit more secure.
How to set these up depends on your router, but most routers just accept connections on their port 80 and offer an easy web-interface. If you give your router brand, we can link you to the manual.
Things are trickier when it comes to connecting from my phone, since
it's not on the same network (I don't have Wi-Fi, only wired
connections), so I'm not sure how to proceed. Basically I want to
connect to a computer that's behind a router.
What you want to achieve is possible, but you need to learn about NAT traversal and hole punching.
Most often, devices behind a NAT/Router have a private IP address only valid on the LAN. Remote devices can't guess it. This private address is translated into a public IP address by the NAT when the device wants to communicate with the WAN.
The easy solution is you can give a public IP address to the device behind the NAT. In this case, remote devices on the WAN will easily be able to reach it, because its address is public.