Does libpcap get a copy of the packet or the actual packet?
By copy, I mean: the application using libpcap gets packet A, and the kernel also gets packet A.
By actual, I mean: only the application using libpcap gets packet A, but the kernel didn't get it.
libpcap will not allow you to do what you want. The goal of pcap is to transparently receive a copy of every packet in the system.
You should investigate how to inter-operate with the existing firewall in your system, or how to add your own filters to the netfilter system (on Linux)
The kernel will get the packet then pass it through a list of filters (for example, there's usually a filter for IPsec, a firewall and so on) and once it's gone through all of these filters, it passes the packet on to the application. libpcap is another filter, but it simply adds the packet to an internal database for processing, rather than inspecting the packet, modifying or whatever else the other filters will do.
For what you want to do, the simplest solution would be to use a firewall.
Related
I would like to use WinPCap library for "reliable" UDP receiving in my C++ application. All examples that I found, using this library for capturing and then proceding. Is there any way (example) how to configure PCap for streaming mode and receive UDP only and on uder defined port or how to solve this. In this time I have reliable UDP server able to receiving 0.5Gb/s. But on slower PC I have a packet lose I can see packets in ethereal but not in application.
thanks
vsm
I assume that you have already tried all of the more standard methods of increasing the number of datagrams that you are able to process? Things like increasing the recv buffer size, speeding up the processing that you do per datagram and using IOCP to allow you to bring more threads to bear on the problem or using RIO if you can target Windows 8?
If so then using WinPCap might work but it sounds like a bit of an extreme solution.
What you need to do is create a filter so that you only capture the datagrams that you are interested in... The docs include examples which use filters.
I have server from here: http://www.gamedev.net/topic/533159-article-using-udp-with-iocp/. This code working with IOCP. Its working fine on WIndows XP. There is no problem with receiving 0.5Gb/s. But now on Win7 is little unreliable. Sometimes there are packets positions error. (my device generating udp packets and in its payload there is PacketNumber - number increasing with each packet. When error occured i write all packet numbers into file. I can see for exmaple: 10,11,290,13,14... ). Is there any known differences in WinXP and Win7 for IOCP and multi threading? Or do you konw any free UDP server with IOCP processing?
In procedding loop I only adding packets into buffer and checking their numbers.
Is it doable to listen a device with 2 different filters and capture packets? For example i start listening a device with a filter and dumping the packets to a pcap file, after 15min can i start another listen on the same device with different filter and dump the packets to another pcap file without stopping the old one?
Does pcap_open or pcap_next_ex block the incoming packets? What i mean if a packet arrives while listening from two different threads one of them will get the packet and control it for filter can the other thread access the packet?
I hope im clear sorry for bad english.
can i start another listen on the same device with different filter and dump the packets to another pcap > file without stopping the old one?
Yes. Albeit, you'd better start that listener in a different thread/process to process it.
Does pcap_open or pcap_next_ex block the incoming packets?
It does not. It drops the packets to your pcap listener if one part (you or the OS) can't keep up with the incoming packets.
pcap will also duplicate the packets(speaking at least of the *nix pcap, assuming winpcap works the same) so if you have several pcap listners, filtering for the same packets , they will all get a copy.
For each open device handle you get, you have a seperate filter, and packet buffer.
say handle 'A' and handle 'B'
now lets say both handles are on the same network device.
Now lets say that the network device gets 4 packets.
each packet gets to the hardware driver, then to winpcap.
at that point winpcap applys each handles filter one at a time.
if a match is made, the packet will be copied to that handles packet buffer.
after all handles have been processed, the packet is handed off to the OS.
Does pcap_open or pcap_next_ex block the incoming packets? No.
The fact is that the operating system, will most likely see the packet before your application will process it.
I may be wrong but I don't think winpcap has any standard method for blocking a packet.
On Redhat Linux, I have a multicast listener listening to a very busy multicast data source. It runs perfectly by itself, no packet losses. However, once I start the second instance of the same application with the exactly same settings (same src/dst IP address, sock buffer size, user buffer size, etc.) I started to see very frequent packet losses from both instances. And they lost exact the same packets. If I stop the one of the instances, the remaining one returns to normal without any packet loss.
Initially, I though it is the CPU/kernel load issue, maybe it could not get the packets out of buffer quickly enough. So I did another test. I still keep one instance of the application running. But then started a totally different multicast listener on the same computer but use the second NIC card and listen to a different but even busier multicast source. Both applications run fine without any packet loss.
So it looks like one NIC card is not powerful enough to support two multicast applications, even though they listen to exact the same thing. The possible cause to the packet loss problem might be that, in this scenario, the NIC card driver needs to copy the incoming data to two sock buffers, and this extra copy task is too much for the ether card to handle so it drops packets. Any deeper analysis on this issue and any possible solutions?
Thanks
You are basically finding out that the kernel is inefficient at fan-out of multicast packets. Worst case scenario the code is for every incoming packet allocating two new buffers, the SKB object and packet payload, and copying the NIC buffer twice.
Pick the best case scenario, for every incoming packet a new SKB is allocated but the packet payload is shared between the two sockets with reference counting. Now imagine what happens when two applications, each on their own core and on separate sockets. Every reference to the packet payload is going to cause the memory bus to stall whilst both core caches have to flush and reload, and above that each application is having to kernel context switch back and forth to pass the socket payload. The result is terrible performance.
You aren't the first to encounter such a problem and many vendors have created solutions to it. The basic design is to limit the incoming data to one thread on one core on one socket, then have that thread distribute the data to all other interested threads, preferably using user space code building upon shared memory and lockless data structures.
Examples are TIBCO's Rendezvous and 29 West's Ultra Messaging showing a 660ns IPC bus:
http://www.globenewswire.com/newsroom/news.html?d=194703
If I understand the parallel port right, sending data from (D0 to D7) simultaneous, but that it can control the sticks individually?
example:
D0 = Input
D1 = Input
D2 = Output
...
...
...
D7 = Input
would it work?
what I want to do is to both send and receive data simultaneously.
Data wires (D0-D7) are being read or set simultaneously. For various tecniques for bidirectional I/O read the attached articles:
Standard parallel port: http://www.beyondlogic.org/spp/parallel.htm
EPP: http://www.beyondlogic.org/epp/epp.htm
ECP: http://www.beyondlogic.org/ecp/ecp.htm
This site is a good source for programming the parallel port.
The basic idea is that you need a DLL, add-on or library that allows you to access the I/O Ports of the PC. For Windows XP on up you need a specific driver that will allow you do this as the OS doesn't offer access out of the box.
The Parallel port will generally reside at one of three address 278,378, 3BC. This port. have the bytes you are reading or writing.
The (base)+1 port allows access to the status bytes. IE. 279,379, 3BD
The (base)+2 port allows access to the control bytes. IE. 27A,37A,3BE
The parallel port documentation will tell not only how to implement the common modes (like bi-directional) but how to control the port at the byte level to implement your own custom.
Back in the day there was only the standard mode available. You pump out your bytes at the (base) port. Some application, like mine, manipulated individual bits of that ports as form of cheap Digital I/O Controller. We did use the status and control bytes as additional inputs and outputs. There were commands you can send to the Parallel Port chip configure the modes precisely.
Today there are are hundreds of sites with example of using the Parallel Port to solve all kinds of problems. I would be surprised that one of doesn't have something you can use for you specific application.
Again the book I recommend starting with is Parallel Port complete. It tells just about everything you need to start with. If your application is too esoteric for that book it will give a springboard from which you can find the exact setup you need.
Of course by sending a number that has just the required bit set (2n) you'd get the expected result.
I'm not sure about bidirectional access though. I guess it's achieved by using control pins along with the data pins but that's just a guess.
Parallel ports doing EPP or ECP only allow D0-D7 to be all input or all output. Trying to do otherwise may fry your hardware.
See http://www.nor-tech.com/solutions/dox/ieee1284_parallel_ports.pdf, page 6.
However, parallel ports have several control lines that may be useful if you only need a small amount of input/output in the "other" direction.
I believe its bit 5 in the port's control register (base address + 2) that switches direction. (no hardware line attached)
This Question is extension of the following
OpenFlow Rule Metadata
I would like to have this clarified, on my question about Metadata
Let us say, I have an Open Flow rules, as below
Cookie=0x8000001, duration=228925.445s, table=17, n_packets=350, n_bytes=32424, priority=10,metadata=0xc000f30000000000/0xffffff0000000000 actions=goto_table:19
I wanted to understand the following
Do we have certain rule/ Algorithm , to determine these Metadata from a Packet.
because the Packet in OVS is actually switched based on Matching Metadata, Is that correct ?? ( At least according to the above flow rule )
And the Packet itself does not carry the Metadata, then how exactly
the packet hitting a flow matched against the Metadata.
So, If I understood it correctly the Packets those are traversed between the flow-tables, are within the OVS application itself or Handled #OVS Application level, until it had determined Egress Port
So in that Case, the MetaData are handled #OVS-Application level, until the Packets is send via Egress Port.
Is this correct??
Finally which Module in ODL is responsible for determine the Metadata, and I would like to understand from the code how exactly it was done.
The OpenFlow metadata field starts with a value of zero for every packets. Tables can then writes to this field and you can match on it in subsequent tables. It is only used to carry information from one table to the next, as explained in the OpenFlow specifications:
Metadata: a maskable register that is used to carry information from one table to the next.
first of all you can try Ryu instead, its code is more easy to read and understand.
Then, I think metadata/instructions/actions.... these things are belong to the processing of OVS forwarding, but these things needs to attach to something and that is the packet that OVS received. About the question "Do we have certain rule/ Algorithm , to determine these Metadata from a Packet. " I think the value of the Metadata is determind by the controller, which means that it depends on 'how do you design your own network instance using some(e.g. RYU) controller application'.