I am sending packets to a Windows network card (eth1) using the Linux sendto() function and a RAW socket (socket(AF_INET, SOCK_RAW, IPPROTO_RAW);). However, although the packets are addressed to the IP address of the network card, the host OS appears to "ignore" the packets.
For example, the network card has IP 192.168.1.2, and my userspace application sends a network packet containing a ping addressed to 192.168.1.2. I can observe in Wireshark the ping arrive on the network device at 192.168.1.2, however no reply is generated. The TTL on the ping is non-zero, so I'm lost as to why the host OS would appear to "ignore" packets destined for it.
Equivalently, if I create a UDP socket and bind it listening to 192.168.1.2 on port 5050, and then send a userspace UDP packet addressed to 192.168.1.2 on port 5050, the packet is never delivered to the port.
What would cause a packet to be ignored by the network card that receives it?
Is there any socket flag needed if I'm sending packets in from userspace (over a custom IP tunnel) to force processing of the packets, as if they came from a router?
The issue turned out to be the native windows firewall, disabling the firewall fixed this issue.
In addition, if republishing network packets on a network device, if a single device (mac addr) is publishing multiple ip packets from various source ips, windows may filter out packets with the assumption that mac<->ip is a unique 1:1 mapping.
Related
I played a bit with the official dpdk by setting up the environment and running some example applications. Then I found out about the UDPDK which combined the DPDK with the UDP stack.
I already have set up the environment for UDPDK as per documentation and then ran the sample app 'pktgen' (both in the local VM and on the public server). Now as far as I understand, this project's aim was to send pure UDP packets between connected devices.
I tried to send UDP packets from VM1(using DPRK) to VM2(normal) and tried to receive packets through a normal UDP receiver (java app) and succeeded, Also was able to send from one server(using DPDK) to another server (normal & both servers are connected to same switch as I could arping between them)
Edit :
My next target / main goal is to send/receive UDP packets from/to 1 public server (using DPDK) to another public server (normal & they are not connected, and no control over switch). Then I came to know about Open vSwitch and been told that this can be the way though I saw DPDK-OVS being used between VM's mainly. Is it really possible to send/receive UDP packets from/to remote public server using DPDK-OVS and if so then how?
Thanks in advance for any help.
For the question can one send UDP packets between 2 servers which are remotely connected (not connected directly or through the switch); the answer is yes, one can do the same without any external or 3rd party switching applciation
Reason:
packets traverse through the local network using Ethernet and VLAN
packets traverse through the remote network using MPLS, IP address or tunnel protocols.
So as long a valid packet with ethernet, vlan, IP, UDP is constructed sending it locally or remotely is possible.
How to do it:
Ensure the port used supports VF
create a VF instance and bind to DPDK
use DPDK API such as pktmbuf_alloc, mtod, eth, IP, udp to create the desired packet.
send a packet on VF interface using tx_buffer or tx_burst.
As long as the right MAC address, VLAN and|or MPLS is right external routing is taken care.
If packets are travelled through the tunnelling via NAT, ip-in-ip or GRE|Geneve, then we have 2 options
Prepare the NAT, tunnelling in DPDK and send over a physical interface
send the custom packet from the DPDK application using TAP PMD into the kernel, using network IP route tables the packets will be forwarded with appropriate tunnelling.
The above second approach takes care of neighbour discovery and tunnelling overhead.
hence the use of DPDK-OVS or OVS or any virtual switch does not solve the underlying issue.
DPDK-OVS provides DPDK vhostuser/vhostuserclient type port as virtual (virtio) device to VM. to VM, the virtio device in VM is just like any other normal network device, the UDP applications runs on VM does not care what underlying network devices the VM runs, UDP receives/sends packet through Linux network stack. you could run another userspace stack on VM and UDP applications runs on top of the userspace stack to bypass VM Linux stack.
I just read about promiscuous mode can be turned on of a internet interface? So I made a small test environment, I opened 3 droplet server on digitalocean, with private networking on. so I end up with 3 server within the 10.130.x.x local network.
server1: 10.130.247.92
server2: 10.130.237.218
server3: 10.130.237.219
in server1, I'm using tshark to capture packets from eth1(private network interface) by
tshark -i eth1
And in server2, I constantly ping server1
ping 10.130.247.92
now server1 capture all the ICMP packets from server2, in the meantime, I turn on promiscuous mode of eth1 in server3
ifconfig eth1 promisc
and start to capture eth1, but I couldn't capture the ICMP packet to server1.
Why is that? I'm guessing in the network is switch based, instead of hub based, so server3 can't capture packets from server2 to sever1, even they are all in the same local network and promiscuous mode is on
Your guess that switch is the culprit is correct. Promiscuous mode means that Ethernet controller would accept packets with any destination MAC address. It does not guarantee that such packet will be sent to that controller.
Even though those hosts are on the same subnet, these days the hosts on that subnet are likely to be connected to an ethernet switch. The switch monitors incoming packets from all ports and learns behind which port it's seen particular MAC addresses. So, if box A is connected to port 0, box B, to port 1 and box C to port 2, and assuming that each host already sent at least one packet so the switch knows who's where, if A sends a packet to B, the switch will send the packet only to port 1. If you've enabled promiscuous mode on C, you will not see the packet sent from A to B.
Here's somewhat more detailed explanation how MAC learning works.
I want to estabilish TCP connection over the internet between 2 computers which are in different local networks(wifi).
I have looked for description of TCP protocol, esspecially the structure of TCP header: http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation
I assumed from that data that only: Source address(global ip), Destination address(global ip), Source port, Destination port are needed.
But how router in recipient's local network will know which computer in this network is recpient without MAC address or local ip address?
So the question: Is MAC address is needed to estabilish connection?
No, MAC addresses are not needed for that.
What you´re asking is called port forwarding:
The router of the server side must be configured that way
that incoming connections on port x are connected to local PC y.
(This could maybe be automated with UPNP, depends on the router etc.)
At the client side, after the client send something to the server,
the router "remembers" where to forward the incoming answer
So right now I'm using only TCP for my clients - they connect to the server, open socket and freely getting packets.
But what if I will decide to use also UDP in my game? Will they gonna have to open ports? For example, if they are using a regular WiFi, can I send UDP to the client without having opening ports problem?
Thanks.
TCP and UDP are just two examples of transport layer implementations. Both of them are using term 'port' to determine which app should receive incoming packet, but they could be routed/filtered differently by routers/switches/firewalls/etc.
So the answer is no. You will have similar problems with opening ports. Just except 'TCP port xxx should be opened' you have to demand 'UDP port xxx should be opened'.
In most home networks firewall rules allow outgoing packets (requests) to any remote port (on your server for example, where this port should be opened). And when such a packet goes through a router - it creates temporary rule to allow answers come back to the local port from which request packet.
So, normal scenario is like that:
Packet originated from home computer with IP 5.5.5.5. Lets say it has source UDP port 55555, source IP address 5.5.5.5 and destination port 8888.
Packet reaches home router. As it is going from inside - router allows it to pass through and creates rule say for 2 minutes to allow packets targeted to 5.5.5.5 to UDP port 55555.
Packet reaches corporate router before your server. It has rule to pass packets for port 8888 so packet is allowed to go.
Your server receives the packet and processes it. In response it creates packet for IP 5.5.5.5 and UDP port 55555.
Corporate router allows response to go.
Home router allows response to go according to temporary rule.
Your computer receives the response.
Corporate computers and routers often more restrictive to ensure security, so second point could restrict packet if your user (IP 5.5.5.5) is in corporate network.
It is very simplified as in reality there's almost always things like NAT and rules are more complex... But in general it gives the idea how it works internally.
Can someone tell me how exactly works "test ICMP"? (One of methods to detect sniffing in local network)
Sniffing detection is basically detecting if there are any sniffers in your network. The main feature of sniffers that is used to detect them is that they place the network card in promiscuous mode, listening for all traffic. Typically, a sniffer is placed on a machine with a full TCP/IP stack which will be affected by this mode.
ICMP is the protocol behind the ping command. To ping a machine, you send an ICMP Echo request packet to it and wait for an ICMP response one. Usually, the ICMP request is embedded in an Ethernet packet to be delivered across the network. A standard Ethernet packet would include the MAC address of the addressed network card, as well as the IP address of that machine in the embedded ICMP packet. The packet would be detected by the appropriate card and that machine would respond to the ping. This is the standard process.
Now let's see what happens if we sent a ping packet (ICMP Echo request one) with the IP address of the suspected sniffer address but with a different, faulty MAC address in the Ethernet envelope.
If the network card in the sniffer machine is not on promiscuous mode, then the packet will not be received by that machine. Naturally, the machine wouldn't respond. The ping attempt would fail.
If the network card in the sniffer machine is on promiscuous mode, then the machine will see all packets in the network. The TCP/IP stack on that machine would thus accept the ping packet by identifying the received packet IP address. The stack would thus send a response. The ping attempt would succeed.
Similar to other methods of detection, this has false positives as well as false negatives. The sniffer machine may be instructed to ignore all ICMP requests. Detecting promiscuous mode is not exactly detecting sniffers, though it is a very significant clue.