I am still trying to understand DDS and its concepts.
I have a configuration where 2 laptops run dds based application. My environment does not permit multicast so I decided to go for peer to peer connection(unicast). To bring both the laptops in the same network, I connected them using ethernet cable (Not sure if it was necessary or not).
Now I did not change anything in the QoS i.e. i did not do any settings for unicasting. But now my applications are communicating with each other.
Question :
How are the participants being discovered ? Multicasting ? as I did not do any settings for unicasting.
Was it necessary to bring them under one network i.e. connect with ethernet cable if I wanted to use unicasting ?
EDIT :
Configuration is as follows :
First laptop : Windows OS : Native DDS based application : Publisher : Multicast not allowed.
Second Laptop : Linux : ROS2 based subscriber : Multicast no problem
Out of the box, DDS is required to support Multicast and Unicast Discovery. Anonymous connections are handled through multicast. If you know the IP address of the recipient, you can manually configure those addresses into the unicast discovery list (each vendor will have their own way to name/process this list).
"Multicast is not permitted on our network", in most cases, means that your IT department has turned off multicast packet forwarding at the switch (or the switches) that define the fabric that is your network.
The as-shipped, standard-compliant DDS configuration, however, has no knowledge of this local policy (how could it?). If you haven't changed the configuration in line with your local policies, the DDS Participants are still going to try to connect via Multicast, because you haven't turned it off.
If the DDS-using machines are connected to the same hub, or to an unmanaged switch (defined here as one that your IT department doesn't care about, or is misconfigured), and the network topology does not cross a managed switch, and they are using the default configuration, and they find each other, then they are using Multicast anonymous discovery.
Figure out how to configure your DDS implementation, to add the unicast ip addresses of the machines that need to communicate. Because discovery is usually only needed in one direction (if A discovers B, then it is true that B has discovered A, assuming neither A nor B are configured to ignore the other[1]).
Once you have configured for unicast discovery, you can configure for no-multicast. If the machines are on IP hopping networks (WiFi, etc) it will be difficult unless the DDS implementation understands multipathing. Talk to the vendor to see if this is the case.
[1] DDS is nothing if not overly configurable.
How are the participants being discovered ? Multicasting ? as I did not do any settings for unicasting.
It is not possible for me to answer this question with complete certainty since you are using DDS as part of the ROS2 framework and I am not familiar with the exact details of how the two are set up to interact together. Having said that, from your description it does seem that the participants are indeed using multicast to discover each other.
The best way to get a conclusive answer is by sniffing the network -- assuming that you have the required privileges to do so. For example you can use Wireshark , which comes with an RTPS dissector that allows you to filter on RTPS messages. (RTPS is the name of the standardized DDS wire protocol.) Check out the destination address and see if you detect any addresses in the multicast range. You can do this while firing up a single DDS-based application. It will start announcing itself over the network immediately.
Was it necessary to bring them under one network i.e. connect with ethernet cable if I wanted to use unicasting ?
If you want to use unicasting, you will need to know IP addresses or host names of all peer nodes. As long as those peer nodes can reach each other over UDP, you are good to go. Often, but not always, ping will let you know whether this is the case. Firewalls are a typical cause of problems.
However, be aware that different types of network have their own specific properties that you might have to adjust your configuration to. Over WiFi for example, the likelihood of packets being dropped (especially with bursts of data) is much larger than when connecting nodes directly with a wire. DDS allows for tuning its protocol to deal with that.
Related
I would like to communicate over USB using COAP protocol.
I am currently planning to use libcoap, it has examples but it is based on UDP server-client.
If I want to use USB, what must be done?
Thanks
Depends a bit on the deployment scenario, but in general I'd recommend using USB Ethernet inbetween (CDC-ECM). Then you can use CoAP over USB like you use it over any other network connection. (If you use RIOT for your embedded device and build the gcoap example on a board with native USB and enable the usbus_cdc_ecm module, you get that almost out of the box).
The large downside of this approach is that you are subject to the whims of the host OS's network setup. Probably it'll take up at least the IPv6 link-local interface so you can go ahead with requests to fe80::addr:ess (or even use link-local multicast to find your device), but there may be pitfalls.
There is the slipmux proposal which would do CoAP over serial, but a) I don't know implementations thereof, and b) it leaves you with similar issues of how to make sure your application can really find the right serial port.
It wouldn't be impossible to specify CoAP over custom USB commands (which would then be taken up by an application), but there'd need to be really good reasons not to just go through USB networking to justify them, and I'm not sure that the complexity of ensuring that your NetworkManager is set up correctly counts.
Tun/Tap interface based tunnel
Can someone tell me how such a tunnel is created and works?
I have tried Googling the answer, but there are very few ressources and they are primarily very technical.
I know that packets sent through such an interface gets injected into the OS network stack and look like packets received from an external host. Also, packets received on this interface gets passed to a user-space program.
However, what I do not understand the following:
Why does such a tunnel involve the use of setting up network connections? Is the programs on either side of the tunnel neccessarily running on the same host, or can they be running on different hosts? Does the network stack deliver tap or tun packages through TCP/UDP?
Both Tun and Tap interfaces deliver data from one host to another. The main difference is the features (pros/cons) that you get when you are using Tun or Tap.
Data delivered via Tap interface gets injected at layer2 of OSI stack and data delivered via Tun interface gets injected and layer3. There is no better/worse choice here - each is suited for specific purpose. You can read a very good explanation here.
Now to answer your questions:
Why does such a tunnel involve the use of setting up network connections?
You want to deliver packets from one host to another regardless the interface type (tun/tap). To do so you capture those packets, encapsulate them and then you need to send over encapsulated data to the remote end. To do this you need to set up a network connection.
Is the programs on either side of the tunnel neccessarily running on the same host, or can they be running on different hosts?
You are creating a VPN connection between two different hosts, so yes - there will be software running on both hosts which will handle the encapsulation/decapsulation.
Does the network stack deliver tap or tun packages through TCP/UDP?
TCP/UDP are layer4 protocols, so from point of view of TCP/UDP stack it does not matter at all if the packet came to your host via tun or tap interface.
EDIT: Clarification about the follow up questions:
Since you are asking about Tun/Tap adapters, let's take a step back. When you run a VPN, you have a computer A behaving as if it is directly connected to network N, even though it might be somewhere far away. To make this happen, you run a VPN software. You have to run this VPN software in two places - one in the computer A and another in computer (or network device) connected to the network N. When running a VPN software in the computer A, you have a choice of creating a Tun or Tap adapter.
Q1: Yes - delivered means sent and received.
Q2: Yes - means that VPN connection is like a pipe, and there is VPN software running at both ends.
Q3: When VPN software is running in the computer A, it creates what is called a virtual network adapter. This virtual network adapter, in the eyes of OS, behaves like a normal network adapter. Just instead of sending data over the wire or waves, it caputers the data, encapsulates it and sends over some other adapter in the system.
We have developed a device that is connected to our clients network and we would like to be able to get its ip or set the ip without knowing its ip.
The device has a Linux OS.
We can save the device MAC Address before giving it to customers. We can program a service to broadcast the device IP and MAC Address to a certain IP or port/socket. We can listen to a certain port/socket for commands. Is this the right direction? Should we investigate in other network protocols other than TCP/IP?
We have seen this feature in hardware/device manufacturers provide a CD with a software that can locate their devices on a network even if they have been newly added to the network without network or ip configuration.
Best regards,
Hussam Kazah
Using propriety broadcasting protocol is a very common technique for detecting devices on network without knowing it's name.
However there's a better option:
UPNP, is an excellent protocol for achieving your goals.
libupnp can get you started in no time.
There's a standard protocol called DHCP which allows a network device to make a broadcast request for its IP address. This protocol is widely used by network appliances. On the other hand you may scan your local network for all connected devices using ARP (address resolution protocol) using for example arp-scan utility.
Recently i had a case where i was trying to establish a p2p connection using Microsoft PNRP technology between two applications. One application was on Lan and another was on same Lan (diff computer but same Service provider) but was behind a WiFi router. Since, I registered the two peers in all clouds(Global & local links) on respective system but when i tried to resolve the another i could not find the respective peers. As far as i know those peers must be discoverable since i also registered them in global cloud (Internet). How can i achieve the aforesaid scenario ?
Using PNRP in this way depends on a couple of technologies, the most important of which is Teredo tunnelling. You've probably run into a restriction of Teredo tunnelling and how it works behind firewalls.
To summarise it, Teredo routes IPv6 traffic over UDP packets sent to a specific port with IPv4. Because of this only certain kinds of NAT are supported for direct connections. You'll probably find that each of your systems can resolve themselves and other services, but not each other within the firewall if they're on different networks.
The easiest way for you to resolve this will be to either make the computers connect to completely different networks, or have them on the same network (as PNRP also supports link-local discovery).
More information can be found on Wikipedia.
I've been playing around with an ethernet protocol (not IP) constructed using
socket(PF_PACKET, SOCK_RAW, ether_type)
I have a small problem. I've got a packet constructed that has the source and destination mac set to my local cards mac that I've also bound the socket to with bind.
I can receive packets fine from the network.
I'm able to send packets to the degree where I see them appear in wireshark.
However, my listening app doesn't see those packets. It is able to see packets from other sources on the network however.
I should point out that my mac addresses do appear to be being sent in the correct byte order.
Can you send packets to yourself?
Do network cards not loopback?
Does the linux kernel do something special at the IP level for loopback and because I'm below that, ignore me?
Yes, IP "loopback" packets, as you put it, are treated specially. They're looped back internally, not sent out through the interface. So ethernet-level loopback, in this sense, is a special case that doesn't normally need to be supported. Some old 10Mbit ethernet cards were even half-duplex, so it couldn't have worked on that hardware :).
On the other hand, you can buy/make loopback adaptor cables to test network cards. So it must be possible on (hopefully all) modern hardware. And people have used them under linux with AF_PACKET (evidence, though no more details, here).
I guess the next question would be whether your switch supports this. A dumb hub would have to support it, but there's room for a modern switch to get confused. Or maybe disallowing it in fear of an infinite loop of packets.