We are testing WebRTC at 3 places A, B and C.
A and C is ADSL, one at home one in office building. B is a company static IP direct line with company firewall and some port filter rules.
The result is: A can connect with both, but B and C can only connect with A.
So we checked their browser console output. A and C can get both internal and public IPv4 candidates (192.168.1.xxx and 123.34.xxx.xxx). B can find 4 ICE Candidate, 2 internal IPv4 candidate (10.0.xxx.xxx) and 2 IPv6 candidate (not sure if the IPv6 address is internal or public).
So the questions are:
What is stopping B from getting public IP candidate from STUN server? Is it some port that is blocked by company firewall?
B can never get public IP candidate, how did A connect with him? A and B can use WebRTC all the time.
Why is C cannot connect with B? Or what is different between A and C? Both of them is using ADSL, fiber modem to TPLINK router (PPPOE dial + default DHCP) to computers, exactly the same.
Thanks.
After further research, C is not using ADSL. It's actually an office building provided network with firewall. That's why C cannot connect with B but A can.
Sorry for the mistake, the client "thought" they know their network details.
And thanks to Taylor, you are correct. Only one open network is needed to make WebRTC work.
After hours of research, I figured out the only solution is TURN server. So I think this question can close now.
Related
I newly wrote a simple chat application, but I didn't really understand the background of ICE Candidates.
When the peer create a connection they get ICE Candidates and they exchange them and set
them finally to the peerconnection.
So my question is, where do the ICE Candidates come from and how are they used and are they all really used ?
I have noticed that my colleague got less candidates when he executes the application on his machine, what could be the reason for different amount of Candidates ?
the answer from #Ichigo is correct, but it is a litte bit bigger. Every ICE contains 'a node' of your network, until it has reached the outside. By this you send these ICE's to the other peer, so they know through what connection points they can reach you.
See it as a large building: one is in the building, and needs to tell the other (who is not familiar) how to walk through it. Same here, if I have a lot of network devices, the incoming connection somehow needs to find the right way to my computer.
By providing all nodes, the RTC connection finds the shortest route itself. So when you would connect to the computer next to you, which is connected to the same router/switch/whatever, it uses all ICE's and determine the shortest, and that is directly through that point. That your collegue got less ICE candidates has to do with the ammount of devices it has to go through.
Please note that every network adapter inside your computer which has an IP adress (I have a vEthernet switch from hyper-v) it also creates an ICE for it.
ICE stands for Interactive Connectivity Establishment , its a techniques used in NAT( network address translator ) for establishing communication for VOIP, peer-peer, instant-messaging, and other kind of interactive media.
Typically ice candidate provides the information about the ipaddress and port from where the data is going to be exchanged.
It's format is something like follows
a=candidate:1 1 UDP 2130706431 192.168.1.102 1816 typ host
here UDP specifies the protocol to be used, the typ host specifies which type of ice candidates it is, host means the candidates is generated within the firewall.
If you use wireshark to monitor the traffic then you can see the ports that are used for data transfer are same as the one present in ice-candidates.
Another type is relay , which denotes this candidates can be used when communication is to be done outside the firewall.
It may contain more information depending on browser you are using.
Many time i have seen 8-12 ice-candidates are generated by browser.
Ichigo has a good answer, but doesn't emphasise how each candidate is used. I think MarijnS95's answer is plain wrong:
Every ICE contains 'a node' of your network, until it has reached the outside
By providing all nodes, the RTC connection finds the shortest route itself.
First, he means ICE candidate, but that part is fine. Maybe I'm misinterpreting him, but by saying 'until it has reached the outside', he makes it seem like a client (the initiating peer) is the inner most layer of an onion, and suggests the ICE candidate helps you peel the layers until you get to the 'internet', where can get to the responding peer, perhaps peeling another onion to get to it. This is just not true. If an initiating peer fails to reach a responding peer through the transport address, it discards this candidate and will try a different candidate. It does not store any nodes anywhere in the candidate. The ICE candidates are generated before any communication with the responding peer. An ice candidate does not help you peel the proverbial NAT onion. Also regarding the second quote I made from his answer, he makes it seem like ICE is used in a shortest path algorithm, where 'shortest' does not show up in the ICE RFC at all.
From RFC8445 terminology list:
ICE allows the agents to discover enough information
about their topologies to potentially find one or more paths by which
they can establish a data session.
The purpose of ICE is to discover which pairs of addresses will work. The way that ICE does this is to systematically try all possible pairs (in a carefully sorted order) until it finds one or more that work.
Candidate, Candidate Information: A transport address that is a
potential point of contact for receipt of data. Candidates also
have properties -- their type (server reflexive, relayed, or
host), priority, foundation, and base.
Transport Address: The combination of an IP address and the
transport protocol (such as UDP or TCP) port.
So there you have it, (ICE) Candidate was defined (an IP address and port that could potentially be an address that receives data, which might not work), and the selection process was explained (the first transport address pair that works). Note, it is not a list of nodes or onion peels.
Different users may have different ice candidates because of the process of "gathering candidates". There are different types of candidates, and some are obtained from the local interface. If you have an extra virtual interface on your device, then an extra ICE will be generated (I did not test this!). If you want to know how ICE candidates are 'gathered', read the 2.1. Gathering Candidates
I have a weird problem. I have a successfully working C++ (boost asio) P2P application which works on most of the NAT. The problem is when I give the initial start port number as 1000 it checks if 1000 is free else increment by one and chooses a port and starts handshaking. But when I have 10000, 20000, or any other huge port number the hole punching doesn't work on port restricted cone NAT.
How is that possible? I am pretty sure it nothing to do with the code. and recently it doesn't work on one of my friends' full cone NAT as well, but it has worked in many other full cone NATs. What could be the reason? Is there something I am missing about how a NAT behaves?
In many NAT implementations, there are protection rules in place which prevent one host from tying up a large percentage of ports on the WAN interface, e.g. like described here.
Depending on the router, the NAT table entries have different lifetimes, and there are always limits on how many ports can be allocated to a single client (I've seen numbers from 128 to 4096).
So I think when you get to the point where you need to use high ports, the NAT table for your source IP address is already full (or almost full) with entries from old connections, or connections from other apps, so the router either decides to decline or can't fit the new NAT entry for your port.
However, to be sure, I would try to repeat that on a controlled environment collecting Wireshark dumps on both sides of the NAT and analyze the packets. If possible, it would also be helpful to enable router logs and peek into them.
I understand this is not a "magic bullet", but hope it somehow helps you.
Don't try to choose the port number yourself. The operating system can do this faster and better than your code can.
Bind your socket to port 0 and let the OS choose an available port number for you. You didn't specify what programming language, but it usually involves a call to getsockname() after the bind() call is made to discover what local port is going to be used. Java and .NET have equivalent APIs for doing the same thing.
Then follow all the other steps here:
https://stackoverflow.com/a/8524609/104458
Not sure if this'll help but have you tried having one instance of the client application starting at 1001 and the other starting at 1000, then both increment by 1.
While the 1000 will fail on client B, client A has already tried 1001 and so punched that hole, so hopefully it'll work, right? In theory, it sounds OK in my head.
I want to configure my Xbees in such a way that both of them can receive and also transmit data ?
I have two Xbee S1 modules. One is currently configured as receiver and the other as transmitter. At certain times, I want the receiver module to transmit data as well.
Could anyone give a link to a tutorial which shows how this can be done ?
Thanks in advance.
Yes, it's possible to do that. If you have them configured with "AT mode" software, you just need to set the DH and DL parameters on XBee A to the SH and SL values from XBee B, and vice-versa (B.DH = A.SH, B.DL = A.SL).
Now any characters going in the serial port on A will come out the serial port on B, and any that come in on B will go out on A.
Can I receive data from network by some processes simultaneously?
For instance, I have two computes in the LAN. One computer send udp packet to other computer on port 5200. In computer number two I want to receive this packet by two processes. Can I create two sockets on same ip and port?
I forget to say that Process A I can't modify. In other words, I want to create application that receive same data as Process A. (Proccess A and Proccess B locate on the computer number two that receive data)
Yes! You can. Open the socket and set setsockopt with REUSE_PORT and REUSE_ADDRESS.
How about you create process A to act as middleware between the two processes B and C. And then add extra data to the packets sent to process A which will be used to determine the final destination of the data - process B or process C.
EDIT:
To answer your question exactly "no", for TCP/IP
"You can only have one application listening on a single port at one time."
Actually you question has been asked by someone else before, and I have only just cited the answer. The full answer can be found -> here.
I would like to understand how udp hole punching works when two hosts each behind the port restricted cone NAT establish connection.
As I understood, it happens in several stages and involves three hosts.
Host A and host B are behind the port restricted cone NAT.
Host C is a server that can receive packets from the hosts A and B.
A sends a packet to C.
C receives packet from A and determines A's external address:port pair
B sends a packet to C.
C receives packet from B and determines B's external address:port pair
C sends the external address:port of B to A
C sends the external address:port of A to B
A sends packet_1 to B's external address
B sends packet_2 to A's external address
The questions are:
How can A behind the restricted cone NAT receive a packet from B which is also behind the
restricted cone NAT?
The port restricted cone NAT do not allow packets, in which the source address:port pair does not match the destination address:port pair of packets sent by it, to be received. Why do other packets sent between A and B arrive to A and to B?
Is it because the port restricted cone NAT considers packet_2 as the response from B?
So packet_1 will be lost but packet_2 arrives to B. Am I right?
Thank you in advance.
FYI, here's a paper that addresses your questions and provides a detailed overview of NAT. A pdf version is available here.
First, restricted cone nat means if A talks to C, B cannot use the hole punched between A and C to communicate with A assuming B is not behind the nat. Meaning, nat traversal does not work in this case.
How can A behind the resctricted cone NAT receive a packet from B
which is also behind the restricted cone NAT?
In this case, it is a different situation, called hairpin condition. In other words, can B behind the nat use A's translated address from behind the nat? Some nats handle this case properly, others don't.
In your case, even if your nat handles hairpin conditions properly, B's packets won't be forwarded because of 'restricted cone'. So, the result is the same.
Why do other packets sendeded between A and B arrive to A and to B?
They won't in your case.
A sends packet_1 to B's external address
B sends packet_2 to A's external address
How can A behind the restricted cone NAT receive a packet from B which is also behind the restricted cone NAT?
Is it because the port restricted cone NAT considers packet_2 as the response from B?
So packet_1 will be lost but packet_2 arrives to B. Am I right?
You're absolutely right, please read about how skype works, it's what you looking for
I've written one: PyPunchP2P. See if someone can make use of it.