I am trying to write code on OSX in c (can use objective-c too if easier) to determine if multicast is enabled on the current machine (router the machine is connected to). To do this I am trying the following steps:
Open a port and send data over multicast.
Listen for responses on all active adapters.
Filter out the 'loopback' adapter.
If no replies, multicast is likely disabled.
Being new to network programming, I don't understand how I would get a response from any active adapters by sending out random data, unless I had software installed on the machines that were listening. Is there a certain multicast IP reserved that will always elicit a response, or is there a better way to go about doing this?
To determine if a machine has IP multicast addresses active (which is what I think you mean by "multicast is enabled"), look at the routing table and see if you find one or more IP v4 addresses in the range 224.0.0.0 to 239.255.255.255.
Multicast is implemented by DHCP, which is not your local computer. DHCP allocates addresses whihc correspond to multiple clients that are connected to that DHCP server. When you craft a multicast message, you send it to this DHCP server, which then takes the packet, finds the clients who are mapped to that multicast address, and then send it in a special packet that routers automatically duplicate (so if you have 2 people part of the group connected to 1 router, and that router is connected to another router (called router 2), router 2 won't send two packets, it will send one, and then router 1 will send two copies to its clients. The purpose of this is to speed up delievery time and not send duplicate data). As far as the clients, the clients aren't "set up" to allow multicast, but rather the router sets them up, and the rest is transparent to the client. The way you would have to find out if a client is connected to a multicast group, is to see if the DHCP server has created a multicast group, and then find the computer names from the IP addresses that are mapped to the multicast group.
By listening to all active adapters, you're not going to get anything but packets, which aren't going to tell you if its part of a multicast network, since they're going to look like every other packet (since the router will change the multicast address to YOUR ip address before you even see the packet). That's the beauty of multicast.
Related
I have been reading a bit about WebRTC, and I'm not getting why we need a Turn Server if only 1 peer is using Symmetric NAT, and the other is using neither Symmetric nor Port Restricted NAT, so let’s say A is using Full Cone NAT, B is using Symmetric NAT:
STUN SERVER will send the correct IP address of B to A, and the correct IP + Port address of A to B.
A tries to connect to B (now A will be able to accept messages from B since it’s in the Dest Address Column).
B tries to connect to A, which will allow requests from A going to B (ofc A needs to update the port to the one received from B instead of the Sdp).
am I missing something, or is this correct (and implemented), or is this too complicated to be implemented?
And if this is correct, then theoretically, if I’m peer A and I'm using Full Cone NAT, any peer B can connect to me (as long as I send the connection request first), without needing a TURN server.
Thanks
If the symmetric NAT environment only changes the port, you would be correct with regarding connectivity to Full Cone NAT. The hole punching step would work.
But many enterprise and mobile environments have complex routing schemes and crazy network environments that are different from a legacy home network router. These environments aren't just a little router box that hooks up to a cable modem. It's a complex array of routers and load balancers using a bank of IP addresses. And each outbound connection might get an IP address different from a previous connection. So it's technically "symmetric NAT".
And so after a node within this environment obtains an external IP/port pair from a STUN server, subsequent sends to a peer address might change both both the port and the IP address as well.
As such, the NATs see completely different IP addresses than expected when the UDP packets arrive during the hole punching step. Hence, a relay address (TURN) is needed here.
This question is a little easier if you think in terms of Mapping/Filtering. The other NAT terms don't do a good job of describing how things actually work. My answer comes from RFC 4787 and WebRTC for the Curious: Connecting
Mapping is when your NAT allocates a IP/Port for an outbound packet. A remote peer can the send traffic to this mapping. Filtering are the rules around who can use these mappings.
Filtering and Mappings can then be address dependent and independent. If a mapping is address dependent it means a new mapping is created for each time you contact a new IP/Port. If a mapping is address independent it means it is re-used no matter where you send traffic. These same rules apply to filtering.
If one peer is address + filtering independent I don't believe a TURN server would provide a benefit.
If you want TCP connectivity deploying a TURN server is a good idea. Some WebRTC servers support TCP, but I don't believe any browsers generate passive TCP candidates.
I have a program that broadcast UDP to my local network, and one host device would read this message and function upon it perfectly.
Now I want to do this job remotely, knowing that where is the reciever host I have a public static IP provided by the ISP, and for example I'm out side this network and I want to broadcast this UDP traffic to it through the Internet, is there any possible routing configuration that would allow this trafic to reach the local network and just explode there ?
And if not. Is there any other way that can make this trafic, instead of broadcasting to be directed to this receiver host directly ? That would require then only some port forwarding in my static ip router.
By RFC, broadcasts cannot be forwarded by routers. Plus, several ISP will filter out such packets anyway. Broadcasts are limited to the local subnet only.
I suggest you look into multicast instead.
I'm sniffing between two devices which communicate in a duplex fashion via udp. I'm using wireshark to sniff. The config file for the first device (a piece of hardware under test) states that the client port is 54718 and the server is 54717. In the config file for the second device (a simulator written years ago), only one port is specified. That of 54718.
The two devices communicate without any problems.
But how does the second device manage to connect and send to 54717 when it has no knowledge of it?
In wireshark I can see that the first device is sending to the second device such that the source port is 54717 and the destination is 54718. I can also see that the second device is sending to the first device such that the source port is 54718 and the destination is 54717.
The first device sends first and the protocol is described as that of UDP in Wireshark. The simulator replies, also via UDP. Subsequent exchanges are described as being STUN ChannelData TURN Messages. I've no knowledge of this protocol but maybe it explains why I don't see 54717 in the simulators config file.
Thanks for your help,
Barry
First, in UDP communication, there is no "connect" action. UDP is not connection-oriented.
Second, the second device will get the peer address and port from recvfrom() api call.
In all probability, the first device's use of the terminology "client port" and "server port" do not refer to two different ports within the client device. Instead, the "client port" refers to the port to be used as the point of origin within the first device, and the "server port" refers to the remote destination port on the far device, to which the first device's outgoing traffic will be sent.
The second device, on the other hand, is probably fundamentally a "listening" device. It only knows the UDP port it needs to listen on, and waits for any queries destined to that port to arrive from anywhere.
So, I will refer to the "first device" as the client, and the "second device" as the server.
Each datagram sent from the client to the server contains two sets of address information:
1) The destination IP address and port, and
2) The return IP address and port.
The server can use recvfrom() to extract the complete return address (including port number) from each incoming request.
This way, we really only need one port number to be predfined and agreed upon by both the server and the client ahead of time: The server's port number.
The client could conceivably choose to use any random port number as its origin port (but by convention it would likely choose to avoid any of the well-known reserved ports to avoid potential interoperability problems), and the server could dynamically read the return address information from each incoming request and send its responses to the correct destination dynamically.
But how does the second device manage to connect and send to 54717 when it has no knowledge of it?
UDP is connectionless, and your program likely gets the 54717 as a default fallback value if nothing else is specified (e.g. in a config file).
I am working on a C++ server/.NET client applications couple in which my server (which runs the c++ on linux) broadcasts a message to show it's alive to the whole network and my .NET program listens for packets and parses to get the uptime of the server.
As I have read, to send a regular UDP broadcast to the broadcast address, I simply have to send a packet to 192.168.0.255 (in my case 192.168.2.255) or 255.255.255.255. Is this right? Can I use the same port address? Are there any other necessities?
I understand the fact that if my .NET program listens on that particular address it is possible to receive packets from other applications than my C++ server program. Is there any method of "signing" the packet on the C++ server-side in order for my .NET program to read the header of the packet and see that it is (almost) the one I am looking for?
Regardless of the language you are using, here is my answer:
Regarding the broadcast IP addresses, both addresses are broadcast addresses but the limited broadcast address (which is 255.255.255.255) won't be forwarded by routers. It is better to use the subnet-directed broadcast address (192.168.2.255).
In order to send/receive a broadcast address, you need to define your broadcast address (broadcast IP address and port number). For example: 192.168.2.255 and port number 3000. The client applications (the senders) MUST enable SO_BROADCAST socket option as follows:
int enabled = 1;
setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &enabled, sizeof(enabled));
where sockfd is the socket descriptor.
The server application will listen on a specific port number (port 3000). Normally, the server will respond to each request using unicast message.
There will be no conflict as long as no application is listening on the same port number. Your server will not run if another application is listening on the same port unless you enabled SO_REUSEADDRESS socket option. However, if there is a conflict, then your signiture is depending on your protocol (message format). So, check the message format and reject the message if it does not follow the message format defined by your application protocol.
For client applications, the received packet is unicast (unless you have another design). So, no conflict at this side.
You also have to enable the SO_BROADCAST socket option in C++ to send broadcast traffic, or you'll get a permission denied error:
int broadcastPermission = 1;
setsockopt(socketDescriptor, SOL_SOCKET, SO_BROADCAST, (void*)&broadcastPermission, sizeof(broadcastPermission))
If your .NET program listens for broadcast traffic, it will receive any and all broadcast traffic on the network sent on that port, including traffic not sent by your server. You could put a "marker" in the payload of the broadcast messages sent by your server. This way, your .NET program could distinguish which ones it cares about.
Beyond that, I would recommend using multicast instead of broadcast. Broadcast traffic is usually restricted to hosts on the same subnet. In layman's terms, if you have a router in your network, a host on side A of the router will not see broadcast traffic sent by a host on side B (and vice versa) because the router "blocks" it. Routers will almost always forward multicast traffic if a host has joined the multicast group.
What kind of IP address does whatismyip.com provide?
How can I get it using VB.Net code?
Also what is IP port?
Thanks
Furqan
PART 1
Okay, let's pretend you have a router in your house and that you have several computers in your house all connected to the internet through your router.
In order for the router to know where traffic goes on your network, it assigns unique IP Addresses to all computers on your home network (Usually beginning with 192.168.x.x). These IP addresses are local ip addresses, meaning only your router and computers/devices connected to it in your house knows about them. If you open a command prompt and do command IPConfig you will see the IP address that your router has assigned your computer.
So what is the IP address that WhatIsMyIP.com showing you? In much the same way that your router assigns addresses to all the computers on your network, your internet service provider hands out unique IP addresses to all of their customers. Now, because you have a router, the only thing the ISP can see on your network is that router and your ISP assigns an IP address to it. This is why routers are also called hardware firewalls, because people on the other side of it, can't tell how many computers or devices are connected to it.
What this means is, when you are visiting websites on the internet, the only IP address they see is your routers external IP address (the one assigned by your ISP). So no matter which computer in your house you use, the website wouldn't know the difference because all it can see is your router's IP address. Go ahead and try it; go to www.WhatIsMyIP.com on several different computers in your house. You will see that they all show the same IP address. However, if you did IPConfig in your command prompt on each computer, that shows you the local address your router assigned and it would be different on every computer in your home.
So, now that you understand the difference between local and external IP addresses, how would you retrieve your external IP address in VB or C# .net code that is running on your PC? Well the only IP address your computer is actually aware of is that local IP that we talked about. The only way you can see your external IP address is to go to a website that tells you what address the request came from (which would be your router's IP address).
What you would need to do is write up some code in your VB.net program that would navigate out to WhatIsMyIP.com (or some other website that can give you your IP address) and tell the code to grab it. I have written a web service located at http://www.u413.com/test/terminal/myip that returns only your IP address as the entire HTTP response. Find something similar though for your application because this little sample will not stay there forever; I only put it up there as a temporary example on a domain I already own.
Visit http://www.vbdotnetheaven.com/UploadFile/kbawala/WebRequestClass04182005054320AM/WebRequestClass.aspx to see how to make web requests from code running on your computer.
NOTE: You may not be aware of what DNS is either if you are unaware of how IP addresses work. Everything on the net has an IP address, including the servers that serve up website pages. But what a pain that would be, trying to remember up to 12 digit IP addresses for all your favorite websites. That is what DNS servers were invented for. DNS servers take a domain name (e.g. www.facebook.com) and translates it into the correct IP address. That way all you need to remember is facbook.com instead of 69.63.181.12 (this is facebook's IP address. Go ahead, try it! Put that IP in your browser's address bar and you will see facebook.), domain names are much easier to remember!
If you want to see the IP address associated with a website, open up a command prompt. Once the prompt is open type PING [websitedomain] (e.g. PING Facebook.com) and your computer will send 4 test requests to the address which is displayed for you.
PART 2
Let's pretend your IP address is like the address of an apartment buliding. The pizza delivery boy needs to know the address to the apartment building in order to deliver your pizza. But what is he going to do when he gets there? There are hundreds of doors/apartments to choose from. He needs to know the apartment number (port number on your computer).
Your computer has thousands of ports, and programs can listen on any one of them for requests from the outside world. When you go to a website almost all websites are served on port 80. Port 80 is the default port for web pages. When you go to facebook.com you are actually going to facebook.com:80, you just don't see the :80 because it is implied since it is the default. If I put up a web server, I could decide any port to serve websites on. If I served web pages on a different port than port 80, then you would have to include it in your URL. http://www.SomeDudesCustomWebServer.com:1337.
Outgoing requests use a port too, but that one is usually unimportant and your computer just picks one that is available. So when you go to Facebook.com, the facebook web servers are all serving up pages over port 80, but the port your computer opened up to send the request does not have to be port 80 because it picks an available port and then sends the port with the request. Then when facebook sends its response, it sends the reply back to the ip address and port that made the request.
Outgoing ports are only used for the duration of the request. Ports that must listen for connections must stay the same otherwise the computers making requests would have no idea what port to send the request to.
Easy huh!
Hope that helps you understand a bit better.
EDIT:
Port Forwarding
Okay, in light of the chat application you want to use/create, if you want it to communicate over the net you'll have to learn about port forwarding. Basically, because all you could see of your friend's network would be his external ip address, you will have to use that address to connect to his chat server (or vice versa if he is connecting to your chat server then it will be your external IP). Because of this, the connection request would only get as far as the router that has the external IP, but it would not know what computer on the network to forward the request to.
You will need to access your router's firmware and set up port forwarding so that the router knows to forward requests on a specific port, to a specific computer on the network. Visit http://portforward.com/ for more detail on how to setup port forwarding.
EDIT 2:
Firewall
When setting up stuff to communicate with your computer using your PC, you may start getting frustrated that it just won't connect. What is likely stopping you is your firewall. By default, most ports on your PC are completely blocked by the windows firewall. For each port that you want to communicate on you will want to go into the firewall and create a rule that will open up the port. Go here http://www.top-windows-tutorials.com/windows-7-firewall.html for a video on how to use the windows firewall. I did not watch it, but it is what came up first on a google search.
Do not simply disable the firewall. Even though this is an easy and quick solution to open up all your ports, you are leaving yourself open to attack. Viruses love to set themselves up in your computer if they can and listen on an open port for a connection from their beloved creator so he can obtain access to your PC. Only open the ports you need.
UDP vs TCP
When opening and forwarding ports you may notice that it asks for UDP (User Datagram Protocol) or TCP (Transmission Control Protocol). What they stand for may not make sense but all you need to know is this: UDP is for single packet transmissions which means that two packets sent by a pc may or may not be related to each other. These types of data packets are usually used for broadcasts on a local network. An example I would use is LAN games. When you host a game on a LAN the other computers/devices can see the name of the game and join it. That is because the computer hosting the game is transmitting a UDP broadcast across the entire LAN so that any devices can see the game. Those UDP transmissions usually contain the name of the game and the connection info required to connect to the game.
TCP is for continuous packet transmission. TCP requires an established connection, any packets transmitted on this connection are always related to that one connection/request. To continue my example from the last paragraph, once you click connect on the LAN game, your computer then establishes a TCP connection with the host and uses that connection for the duration of the game or games. TCP is the most commonly used connection type and your chat program would likely communicate over TCP, especially if you are connecting across the net because UDP broadcasts are useless across the internet. UDP is only really useful on a LAN.
You should be safe forwarding and unblocking only the TCP ports, but sometimes when I'm unsure I just do both UDP and TCP just to be safe. In fact, many routers and firewalls have 3 options: TCP, UDP, or Both which saves you from having to create two rules for both types of the port.
When in doubt, open/forward both.
What's my ip provides your IP v4 public address.
It's really easy to retrieve it, this topic explain how to proceed : How to get the IP address of the server on which my C# application is running on?
The code is only a few lines long, so the language (c# in this example) does'nt matter.
They provide your external internet facing IP.
This IP will depend on how you connect to the internet. If you connect straight from your computer to your ISP without any kind of router or firewall in between, it might be the same as your internal IP, but in most circumstances this will not be the case.
If you're at home and you've connected via a router of some kind, then you might be able to query it for the IP, but there is no standard way of doing this.
There is no standard way of getting hold of your external IP from the client it self. If you've got access to a server on the internet where you could deploy some code you could connect to that server from your client PC and ask it what IP you're connecting from.
IP Port Numbers
I also needed external IP using command line, but because I didn't find it I wrote small application using vb.net. You can use reflection for source code or ask on app home page for it. Basically application opens web page that provide your IP and parse it using regular expression, but because is designed with this purpose uses many "tricks" for this (can use more web pages at once, uses fastes page, etc). Check source for details.