I'm from germany and my provider is Deutsche Telekom. I'm using ubiquiti edgerouter x with an pppoe connection to Telekom. Internet works well but I can't get VoIP working. My Phone is a Siemens Gigaset C430A GO. Only configuration I did there is following the wizard, entering my phone number and selecting predefined Telekom settings. Those settings should be correct according to Telekom support.
On the edgerouter I've whitelisted and forwarded almost every port to my phone (10.1.0.4).
Please have a look on the tcpdump I took while doing a call from my mobile to my configured landline: https://justpaste.it/4i8n9
The issue is that it is ringing, I pick up, but can't hear anything. After 10 seconds the connection gets closed. In the opposite direction I also can't hear anything but the connection stays open. But: When I hang up on one side, the other side get's notified.
I find this very weird. It does not really look like a problem of a closed port or something else with the firewall. Unfortunately I have no experience with SIP so far so from the log I can't really tell if everything is correct there.
I've change the phone numbers in the log.
111122223333 is the landline I was calling.
444455556666 is my mobile number I was calling from.
777788889999 is also in the log which is another configured landline. I have no idea why this is in the log.
100.200.100.200 is my external IP.
10.1.0.4 is my internal IP for the phone.
Does anybody have an idea what could be wrong?
You should check your router's NAT or ALG settings as well as the STUN settings of the phone.
Here is the rationale behind it: the capture you posted shows the remote party expecting media on port 33880 whereas your phone expects it on port 5012. The issue is that while your phone successfully sends out its audio, it is not receiving any in return. Moreover, about a second into the call, your phone is sending a reinvite, this time using its local IP address rather than a publicly routable address:
...
o=- 5012 14 IN IP4 10.1.0.4
s=Mapping
c=IN IP4 10.1.0.4
...
The reinvite is rejected by the other party on the account of the SDP being bogus (rightfully so), and during the course of the capture, this series of events repeats several times.
If your router supports ALG and it is enabled, you should attempt reversing this setting as it effectively tampers with the SIP flow through your router; its purpose has been obsoleted by NAT and these days it does more damage than help;
If your router's NAT settings mandate symmetric NAT, disable it; it's behaviour is consistent with the issue you described (though there can be other reasons for it);
Check your phone's STUN setting (page 106 of the user manual) and enable it; STUN works great behind NAT when it comes down to traversing your local network by informing the remote party on sending its audio to an working port.
Hey thanks for the information. I figured out that the edgerouter indeed has an SIP ALG. I've deactivated that one. Then I've changed the standard SIP and RTP ports to something custom just to make sure nothing is trying to do some SIP magic still. It still didn't work until I tried disabling STUN. Now it works. But why not. I'm forwarding now only the ports that are really needed and my phone don't need to do STUN for no reason. Firewall rules allow packages from the Telekom SIP range to my phone. Everything is fine now.
Related
First I want to define my question:
1, I am talking about computer program doing the IM, not mobile app. The program should be working in every home, or office environment.
2, Right now all (or most) home computers are behind a router, protected by ISP's security policy. It is not like 20 years ago, when a computer connects to an adapter, it gets a universal IP, as good as Microsoft.com and whitehouse.gov. 10 years ago, you can advise user to do port forwarding, or use UPnP to stealthily perform the port forwarding task. But now in the name of security, ISP is taking port forwarding out from the ISP-managed router (xfinity is doing that, as far as I know).
I know how to do IM in LAN setting, or the universal IP setting, that you get the IP of the friend, establish connection using TCP or UDP, then transfer information. Now when all computers are behind the routers, what is the feasible way / popular way / right way to do IM again? Using a central server to transfer information, by establishing connections of UserA-Server and UserB-Server? I know it would work, but not very "instant", in my humble opinion.
Please advise, thanks.
Upnp and NAT-PMP can still work, it will map a external port like punchhole. The problem is that our external IP may not be sure. So if you want to send IM, there are two choices, DHT or Central Controller.
I suggest you to use DHT and a central server using ICE structure, if DHT can work then it is ok, or we can use the central server to do the UDP/TCP traversal. In some circumstances like symmetric NAT, the server need to do relay, but in others, it just start the connection and then it is a p2p connection without server.
I am trying to set up a wireless 'test' box to use on a private club (11,000 acres). The initial tests won't need anything fancy, it will just be checking the visibility of a hotspot from a high-point in the middle of the property. But if it proves to have good visibility, later tests will be (hopefully) promoted by the club and made aware to members. I would like to set up a captive portal to redirect them to a comments page where they can post a quick message if they were able to connect and hopefully say what they think about the idea.
This is going to be going on a raspberry pi running debian wheezy. So the less overhead the better.
Most of the examples I see online of captive portal are based on having an internet connection and/or a NAT scheme set up. I just need a hotspot and a single web-page for these promotional tests. If possible, I would like to trigger any devices capable to suggest or otherwise open a browser to go to the promotional landing page. It would also be nice if some kind of dns masquerading or other mechanism was in place to redirect all browser traffic in the event their device doesn't support a pop-up.
Any help is appreciated.
EDIT 2022/06/05: With further testing and packet sniffing, it turned out that the android versions in question hard code the ip of the google server used for the 'online check' (8.8.8.8). When on an arbitrary IP, it's not looking for requests to 8.8.8.8 and thus it doesn't grab the online-check and won't redirect. If you set the AP to use this address (when not internet connected), the pop-up will usually trigger.
However, this solution is not ideal. Hacking the IP stack to specifically grab that request to 8.8.8.8 is outside my wheelhouse of knowledge. If anyone knows how to do this or has another potential solution, I would be interested in hearing it.
Since I'm not happy with the functionality of an iPhone App that operates my Actioncam, I would like to write an app that improves on that functionality.
In order to do that, by lack of proper documentation, I need to reverse engineer the communication between the App and the Device.
What I know, is that the Device only responds on ports 21, 554 and 15740.
I managed to create a setup including an iPhone, the Device and two Macs, and traffic analyzing software called Charles (but likely I could also use Wireshark), that shows me all HTTP(S) traffic.
This is where my knowledge ends. What I hoped to see, was that Charles would report something like
rtsp://[my device ip, which is known to me]:554/[unknown to me path]
Potentially it would even involve a login and password in that URL.
Could any of you give me a hint on how to proceed? Aforementioned software seems to be limited to HTTP traffic.
What excatly do you want to reverse engineer? The video feed or control logic? From what you mentioned it seems that 21 could be used for FTP, 554 for RTSP and 15740 for some custom TCP protocol. If you have no idea about the format of the data that is sent over to the port 15740 it will be quite hard to reverse engineer (except if it is some kind of plain text ascii protocol).
For the video feed - I'd suggest setting up Wireshark to monitor the port 554 and then you should be able to see the url of the video location from the DESCRIBE command.
I developed (in VB6) a small app that send an UDP broadcast message (address 255.255.255.255) and then listen to the answer from the electronic devices we produce (this is to know the IP address of the devices for further messagging).
This was about 6-7 years ago, and all worked well till 1 month ago.
Now the UDP messages does not exit from my PC. With wireshark i can see the UDP messages sent from other PCs, and the answers from the connected devices, but not the messages i send from my PC.
Also, i use Comodo firewall, and even it can't see the message coming out (i deleted the related rules to let Comodo ask permission for my program, but the request pops out only when it sends TCP messages). Even didabling Comodo did not solve the problem.
WinXP firewall is disabled and untouched from years.
So my guess is that a recent Windows update changed something.... but what should i look?
What's blocking UDP calls BEFORE it reaches Comodo Firewall, or how to discover it?
I have no antivirus, and just in case i disinstalled Windows Live Protection ... so really i don't know what to look. I'm an experieced Windows programmer but my API knowledge is mostly about graphics, and i'm not a network expert either (we work with microprocessor, and use TCP/UDP sockets for basic communication).
Thanks
Well, reinstalled VB6 (sigh) and discovered that, as usual, when the problems are inesplicable the cause is often a trivial mistake.
The UDP socked was using a predefined port, and now that port is already in use. The error trapping was hiding the generated error, so i did'nt know it.
Changed the local port to 0 allows the system to pick one random port, which is fine for my purposes.
I've read tons of questions about this all over the web, and can't seem to find a solid answer. If I have an iPhone that's running on cellular data and another iOS device on wifi (in two separate locations), is it possible for them to send data to each other directly without sending it first to a web server, then retrieving it? Are the only options sending and receiving from a server/Apple's iCloud? What if I knew the devices' ip addresses? Note that the iPhone has WiFi disabled.
I'm not looking to put this in the app store, it is for personal use. I know NSNotificationCenter isn't an option.
Using the gamekit framework you can send data between two iOS devices. It is easy to implement. Other than that I don't think there is any other way to send data between two iOS devices.
Actually, it IS possible. You may want to google for something called "UDP hole punching" or "TCP hole punching".
The main approach in short: Assuming you got something like a relay server, that is some server in the internet that is publicly addressable from every private LAN that is connected to the www. No you have your two clients A and B in (different) private LANs, with some Network address translation (NAT) going on, that want to establish a peer to peer connection.
First of all both will tell the server their IP address and the port they have in their own LAN. In the UDP or TCP packet, the server will find the public address and port of the device (or the NAT (router)). So the server knows the private and the public IP address as well as the ports.
If now A wants to communicate with B, it asks the server for help. The server will send a message to B that A wants to communicate with her telling her A's public and private IP and port. A gets back B's public and private information and port.
Now here is where the magic happens. Both clients now send packets out to establish a connection simultaneously to the private and public addresses of the other party and thus punching a whole in their NATs such that incoming connections will not be blocked. Even if one party's connection establishing packets will arrive before this whole is created, the other's packets will get through to such that a connection can be created.
Beware of some NATs that scan the data for IP addresses and translate them as well, but if you encrypt your data or change the appearance of the address (complement, ...) you will be fine.
Now the master question, how can the server communicate with one of the clients without an active connection. Well in this case you can use "connection reversal" and apple's "push notifications". Use the "push notifications" (pn) to tell a client behind a NAT that there is something of interest going on and that it should contact the server. Once it has done that the connection is active and can be used in the previous described fashion.
I hope this helps some people that get to this problem although the post is quite old!
You can only use direct IP address communications if the IP address are publicly reachable IP addresses accessible over the internet, and they are static (enough) so that they are not changing on you regularly as devices get assigned to addresses dynamically. In many (most) cases, that won't be true because your devices will be assigned their IP address dynamically and those addresses are frequently going to be self-assigned IP addresses that aren't publicly addressable.
As others have commented, using Apple-provided mechanisms like iCloud are probably the easiest options. If that's not something you'd like to entertain, there are probably ways to make use of a dynamic DNS service like DynDNS to manage the actual IP addresses of your devices. With something like that you might be able to use a direct IP connection between devices based on a named DNS lookup. You'd probably have to jump through some hoops to make that happen though and I'm not sure you'd want to go to that extent.
I think that Bluetooth would be a good option for you