I work in company where there are strict restrictions on the network. I need to write an application in python 3, where a wired connection and wi-fi will be used simultaneously. For example, to send data to internal resources, I will use Ethernet and to go data from the network use wi-fi
Related
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.
I have a collection of wifi enabled linux devices.
I would like to configure one to use the wifi and the rest to automatically join the same network. It seems to me if I could set up a data link client/server model, all the devices could exchange network credentials and join the same wifi network. Is this possible? Can it be done over command line? How can devices communicate when they have not yet joined a network or received and ip address?
For your devices to communicate they need to connect to something. Since your goal is to have them learn WiFi credentials X, we should assume they can't use credentials X to connect to each other. So they'll have to do something peer-to-peer. Some ideas:
Have the one device which knows credentials X create an "ad hoc" WiFi network. Have the others join it and connect to the creator to learn credentials X.
Use an alternate protocol for credential exchange, such as Bluetooth.
Neither of these ideas will be best implemented in Bash. Something like Python or C may be easier.
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.
I am currently working on some design concepts that would see me have the requirements for the following type of system.
In short I am looking at ways to Tunnel a connection through NAT similar to VPN but without the complexity.
I have a small embedded linux device that sits behind a home LAN that I would like to be able to interface with through an API that I have created.
Currently the setup I have is as follows:
Device A (Embedded Linux) - Public IP
Device B (Amazon Server)
I am using a REST/Json api to control Device A from Device B.
I am looking for a protocol or solution that would allow me to send two way communication from Device A and B possibly by adding a third proxy server to handle this "Tunnelled" connection.
Notes:
Would preferably like to avoid complex VPN's and the need for the NAT device to support VPN Passthough.
Traffic between Device A and B is small and not highly sensitive but some security like SSL would be nice.
This is a multinode system, Hence, There are many Device A's.
Any advice as to where I should be looking would be greatly appreciated.
Regards
pjf
I know the purpose of softAP in WiFi.
While enabling the softAP WiFi playing a host role we cant activate to client role till deactivate the softAP.
Why we can't design the double role softAP, which means why can't we activate our WiFi to play client and host at same time ?
If we do, what kind of problem we happen to face, is't possible?
Because in GSM we are creating virtual multiplexing ports for data,call,SMS etc.., like wise why can't we develop any firmware do perform like this for WiFi?
Of course, it's possible and it exists for various NICs. It's more complex because double mode requires handling the coexistence of both links.
Microsoft added a feature called "Virtual Wi-Fi" to Windows 7 and later operating systems, which enabled a Wi-Fi card to act as both a Wi-Fi client and a wireless access point simultaneously. Although a relatively fresh concept, new computers with Windows 7 and above were now being released with "Virtual WiFi" as a default program, making personal computing less complicated without the need for a second device.