I have installed npcap driver which supports loopback interface. I installed it because I need to inyect packets to loopback interface and read them from it. I can easily read packets in the loopback with "pcap_next_ex" as I can do in winpcap in ethernet interfaces, but when I want to inyect a packet to the loopback with "pcap_sendpacket" dosent work, and the function returns 0 (successfull).
I verified this by opening wireshark and watching the packets incoming to the interface, when I use pcap_sendpacket on ethernet interface I can watch the packets, but in the loopback they dont appear when I tried to inject them. Why?
//The array which contains the data of the test package
UCHAR packet[] = "\x..";
//loopback adapter is already opened here
for (int i = 0; i < 100; i++)
printf("%d ", pcap_sendpacket(loopbackAdapter, packet, sizeof(packet)));
I use this code on loopback interface and didnt work (but pcap_sendpacket returned always success), because in wireshark the packets didnt appear, but in ethernet interfaces the injection was successfull.
Does npcap support loopback packet inyection?
Thank you and regards!.
You need to understand that every network packet (even a loopback one) has a direction: on send path (Tx) or on receive path (Rx). Usually, when you send a packet to Npcap Loopback Adapter, you are actually sending it to the Tx path of the Windows TCP/IP stack. When you are sending Tx packets, you usually wait for a localhost application (or a protocol, a driver, etc) responding to them.
I don't know why you want to inject packets to loopback interface and read them from it. Npcap's low-level logic for this part is just not letting the current session (a pcap_t) receive the packets that this session injects. But other sessions can see them, this is why Wireshark can see the packets that you inject.
I just don't know why you are doing this. You seem not to want any other applications respond to these packets. But as a workaround, I think you can get what you want by injecting the packets to the Rx path. By sending packets to Rx, it means to fool Windows to believe that these packets are received from outside. I don't remember how I implement it, but the same session should be able to see these packets in Rx.
We didn't document the Rx feature very clearly. There's only some description in releases: v0.05-r6 and v0.05-r7, and an example here: https://github.com/hsluoyz/UserBridge. They should work even in latest Npcap.
Related
I have an application that creates, listens on and writes to a tap interface. The software will read(tun_fd,...) and perform some action on that data, and it will return data to the system as UDP packets via write(tun_fd,...).
I assign an IP to the interface, 10.10.10.10\24 so that a socket application can bind to it and so that the kernel will pass any packets for the virtual subnet to the tap interface.
The software generate frames with IP/UDP packets with the destination IP being that assigned to the interface, and a source IP existing in the same subnet. The source and dest mac address match that of the tap device. Those frames are written back to the kernel with write(tun_fd,...).
If I open said tap interface in wireshark I will see my frames/packets as I expect to, properly formatted, expected ports, expected macs and IPs. But if I try to read those packets with netcat -lvu 0.0.0.0 ${MY_UDP_PORT} I don't see anything.
Is this expected behavior?
Update 1
INADDR_ANY is a red herring. I have the problem even when explicitly binding to an interface / port as in this pseudo code:
#> # make_tap_gen is a fake program that creates a tap interface and pushes UDP packets to 10.10.10.10#1234
#> ./make_tap_gen tun0
#> ip addr add dev tun0 10.10.10.10/24
#> netcat -lvu 10.10.10.10 1234
Update 2
I modified my code to be able to switch to a tun as opposed to a tap and I experience the same issue (well formatted packets in Wireshark but no data in socket applications).
Update 3
In the kernel documentation for tuntap it says
Let's say that you configured IPv6 on the tap0, then whenever
the kernel sends an IPv6 packet to tap0, it is passed to the application
(VTun for example). The application encrypts, compresses and sends it to
the other side over TCP or UDP. The application on the other side decompresses
and decrypts the data received and writes the packet to the TAP device,
the kernel handles the packet like it came from real physical device.
This implies to me that a write(tun_fd,...) where the packet was properly formatted and destined for an IP assigned to some interface on the system should be received by any application listening to 0.0.0.0:${MY_UDP_PORT}
Yes, data written into the tuntap device via write(tun_fd...) should get passed to the kernel protocol stack and distributed to listening sockets with matching packet information just like the frame had arrived over a wire attached to a physical ethernet device.
It requires that the packets be properly formed (IP checksum is good, UDP checksum is good or 0). It requires that the kernel know how to handle the packet (is there an interface on the system with a matching destination IP?). If it's a tap device it may also require that your application is properly ARP'ing (although this might not be necessary for a 'received' packet from the perspective of a socket application listening to an address assigned to the tap device).
In my case the problem was silly. While I had turned on UDP checksum verification in wireshark I forgot to turn on IP header verification. An extra byteswap was breaking that checksum. After fixing that I was immediately able to see packets written into the TAP device in a socket application listening on the address assigned to that interface.
I am developing a logic core to perform data transfer between a FPGA and a PC over ethernet, using a LAN8710 PHY on my FPGA board.
I've achieved to transfer some UDP data packets from the FPGA to the PC. It's a simple core that complies with the PHY transfer requirements. It builds the UDP package and transfer it to the PC.
To check the reception on the PC, I am using Wireshark and as said above, I receive the packets correctly. I've checked the reception with a simple UDP receiver written by myself.
But, I've noticed that I only receive these packets when Wireshark is running on the PC. I mean, if Wireshark is ON, my application receives the packets too, and the counter of received packets of the following picture increases. (This picture is not mine, just one from the internet)
http://i.stack.imgur.com/wsChT.gif
If I close Wireshark, the PC stops receiving packets and the counter of received packets stops. My application stops receiving too.
Although novice on networking topics, I suspect that this issue is related to PC-side. Seems like Wireshark is "opening/closing" the ethernet communication channel, or something like that. Does anyone knows about this issue?
To build a functional core to transfer data between a PC and the FPGA, I've developed a core to transfer and receive UDP packets. Next step will be ARP implementation (to let the PC identify my FPGA board, as I understand). What protocols are necessary to perform full-duplex data transfer between this 2 devices?
Thank you very much in advance,
migue.
Check whether you are able to get appropriate receive interrupt at ethernet driver level on PC-side for a single transmitted packet by FPGA. If you do not get the receive interrupt, check on the transmit side(FPGA) for appropriate transmit interrupts for packet that is being transmitted. This should mostly help you in cornering the issue.
As far as i know, wireshark is just a packet analyzer/sniffer. However, if wireshark is suspected, one option could be to try with alternate packet sniffer to rule out if any such scenario is happening.
A handy tool for determining problems in network and also for determining the network statistics shall be netstat. netstat -sp udp shall list down the statistics only for UDP. There are many other parameters that can be used with netstat for diagnosis.
After many months I solved it, I post to help someone stucked in the same point.
Finally I figured out that Wireshark uses a tool to access the network link layer of the computer. This tool allows Wireshark to sniff all incoming and outgoing packets at a specified network device. To do this, the first step is to OPEN the network device, and that's why my program only worked if Wireshark was open.
Regards.
So I was curious if this is possible at all. Currently i have a program running in a micro controller (digi rabbit) that reads SPI data from a chip. I also have TCP/IP protocol set in this program so it sends the SPI data to the server. Microcontroller is programmed in C. Server is in java. I convert SPI data into string and send it over, the server reads the raw data.
But i wanted to know if there is a way that I can read the data from Ethernet port. So what i want is one end of cat 5 cable on micro controller and the other on Ethernet port of the computer. Just for testing purposes that micro controller port and everything is installed properly, before i turn on the server. I am not that experienced with networking. So if anyone can point to a blog, or any tips that would be great. My question is how would i go about it?
Thank You
What you want to do is called raw Ethernet. Of course this can be done.
On the microcontroller side you need to follow its Ethernet controller datasheet to send out and receive packets. On the PC side this is a bit more complicated and depends on the OS that is running on the PC. On Windows you can use the WinPcap driver to send and receive raw Ethernet packets.
Be aware, that both Ethernet controllers, the one on the PC and the one on the microcontroller, filter all incoming packets that do not contain the receivers MAC address or any multicast/broadcast address. For a simple check the broadcast address (all address bits are 1) will do.
Also note, that the OS on your PC will transmit all kind of packets as soon as the link is established. So you may use a unique protocol identifier in the type field of your raw Ethernet frame. Check Wikipedia's article about Ethernet frames. Btw. don't get confused. You only need to send MAC-adresses, Ethertype and the payload. Everything else, like the CRC, preamble etc., is added by the Ethernet controller automatically.
Is it possible to push all packets received at NIC to the TCP/IP stack even if their ethernet address doesn't match my ethernet address? In other words I want to process all incoming packets at my NIC.
Can anyone mention a possible scenario for changing network interface driver code?how could I check the operation of driver code?
In the typical system, this already happens. That is, all you have to do is put the interface into promiscuous mode. The driver then sends all packets it receives to the TCP/IP stack. Check any ordinary network driver, you'll see that in processing received packets, there is no comparison of the MAC (or ethernet) address with the device's MAC address.
Simplifying considerably:
What normally happens is that when you don't have promiscuous mode enabled, the driver configures the device such that it filters on a specific MAC address, only delivering frames that have a matching address or a broadcast address (or occasionally a multicast address, which may or may not also be filtered). When you enable promiscuous mode, the driver simply tells the device not to filter on MAC address but to deliver all frames. The driver then will receive all frames and deliver them to the stack. In linux, this typically happens through a call to netif_receive_skb() or a variant thereof.
The TCP/IP stack itself doesn't care about the MAC address. It will instead look for packets that have an IP address matching one of its own. Any packets received that don't have an IP address belonging to this box are simply discarded -- unless there's a user-mode program trying to receive raw packets (such as tcpdump). [In the latter case, it's still discarded after being delivered to tcpdump.]
If it matches on the IP address, it's then passed up the stack to TCP or UDP [etc] -- where it could also be discarded if it doesn't correspond to a session / port that anything on the box cares about.
But typically packets destined for a MAC address not matching one assigned to this device will not be packets that this machine cares about. Hence, promiscuous mode is usually only enabled for debugging, troubleshooting, forensics (i.e. tcpdump, wireshark, etc). The rest of the time, it's a waste of processing resources since the packets will just be discarded.
Im new to the networking world and I'm trying to use wireshark to get a hang of how packets are sent from my machine etc. Hence this question might be a dumb one.
When I open the wireshark packet analyzer GUI (on windows 7) there is a source and destination column. It shows packets where source IP is not mine and the destination IP is not mine either. Why is this happening? My network interface card should be receiving and sending only packets addressed to/sent from my IP address, right?
(attaching a screenshot. My IP address is 10.177.255.186)
Thanks.
On a small LAN all packets are generally broadcast to everyone. By broadcast I mean that the data is physically sent to everyone. When received the network interface determines if the packet was sent to you by looking at the address.
Using Wireshark your network interface can be set into promiscuous mode which means that all packets are captured and sent from the network interface to the CPU. This allows programs like Wireshark to record all those packets and not just the ones addressed for your computer.
Edit: However the packets don't have to be sent to all computers. A hub can be used to connect multiple computers together and acts as just a repeater meaning all packets are always sent everywhere (except on the wire where the packet came from). A switch however is similar but smarter.
If three computers A, B and C are connected to a switch and A sends a packet to B then the packet will first arrive at the switch. If the switch knows what wire B is connected to then it will only send it down that wire. If it doesn't know it sends it everywhere and later if B replies to A the switch will figure out what wire B is on. This means that C will generally never get to see any of the messages sent between A and B once the switch knows what wires A and B are on.