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.
Related
I am working on a Python communications class running on a Beaglebone that connects to /reconnects to remote hosts from my list of available servers.
To test the reconnecting, I have been physically unplugging my lan from my router to simulate outages.
I would like to do this in code for extended testing.
Essentially I want to create a method called kill_internet(timeout) that will pull the rug out and then restore connectivity at the end of timeout.
requirements:
Must interrupt established socket connections.
Disconnect must be brutal and ugly - no chance for socket to close
gracefully.
Finally - I prefer that lan connections are not interrupted so I can continue to monitor testing over SSH from my PC. Not a true requirement since I can always reconnect and read logfiles later.
Service Networking stop will satisfy #1 but not sure how brutal it is.
I thought about UFW ( iptables) outbound rule but that may not block established connections and same concern about #2.
I suppose I could build a hardware 2-port device to do this at hardware level but that is well - hard.
Any ideas how to proceed?
Thanks
Bill
The best way to do this in your setup is to create and tear down firewall rules on your remote server to reject/deny your client in as many different ways as you can think of. For example:
Reject connection requests with an active refusal (easy to deal with on the client).
Drop a connection mid-flow with a reset packet (again, easy to deal with).
Suddenly stop responding at all to packets from the client's IP, mid connection. This simulates a cable-cut on a part of the network you don't own and it's the hardest one to deal with on the client because you have to consider what is a reasonable timeout.
If you're on Linux, iptables can be scripted to implement these rules.
I stumbled across an easy hardware solution that cost me $22.
Amazon sells these USB controlled relays for $10-$15 - look for UsbRelay2. With this I can easily trigger the relay(s) from code. To interrupt Ethernet violently, all I have to do is cut the power to an Ethernet hub or switch. I got a $10 5-port switch which runs off 5V from a wall wart. I cut one of the 5v power wires and ran it through the relay. Triggering the relay cuts the power to the switch. Since it is all 5V wiring is all safe and no case is needed. It took all of 3 minutes to put it together.
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.
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.
I have EK1101, EL6002, EL2034 modules which is based on network devices. These modules are connected PC Ethernet port via ethernet cable. I have tested these modules with some application program, its working fine on my PC.
EK1101 working as a Coupler. It connects PC Ethernet Port and Other slave modules( EL6002, EL2034,..)
EL6002 working as a RS232 communication. EL2034 working as digital I/O. Similarly we have more than 10 different devices. These modules interfaced with EK1101 coupler at same time.
How can i implement as Linux driver? and start?Do I modify the existing network driver or start new driver from scratch? what type of i need to write, character or network driver? If its character driver how can i transfer data through Ethernet port?
Using the serial slice (EL6002) you can only send 22 bytes (each direction) per exchange for each port. At full serial bandwidth (115k) updating at 1kHz, you won't be able to miss an update without starving the transmitter and/or dropping data on the receiver. If that's a concern you will probably need to claim exclusive control over the Ethernet port being used to master the EtherCAT loop. This requires some form of root permissions, otherwise someone can always try to send packets over the port, affecting your timings. You haven't given much detail about your application or timing requirements, so maybe that's not critical for you.
I've been using the Etherlab IgH open source stack, which requires root permissions to load its kernel module which implements the underlying stack. Once that's done you can set everything else up to run from user space without root permissions.
Once your application acquires access to the master stack, you setup a data exchange domain (what TwinCat calls a task) and you will have a region of shared memory that can be used to monitor the EtherCAT frame data. Your application is responsible for deciding when to send and receive domain updates.
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.