Problem with byte-swapped IP addresses

[Peter Van Epp]

	Comments inline ...

On Wed, Mar 10, 2010 at 10:48:56AM -0500, Carter Bullard wrote:
> Hey Martijn,
> I agree, I don't think argus is too slow.  I'm thinking that there are two possibilities,
>    1. the snaplen is too short for the encapsulations that argus is running into, and we
>        we are corrupting the pf_ring by modifying data in the ring buffer.
> 
>    2. there is an issue with libpcap/pf_ring ?  
> 
> We are not doing anything special when  a pf_ring is being used.  should we use
> pf_ring() calls rather than the "legacy"  libpcap calls?
> 
> The current argus is libpcap only.  We try to use non-blocking reads, and select(),
> if available, to see if there are packets to read from the pcap_fd.   Not sure if a 
> pf_ring based libpcap interface is selectable.
> 
> When the interface is not selectable, if we go to read some packets, and there aren't
> any there, we go to sleep for 25 mSec.  This is an arbitrary number, and maybe a
> problem for the pf_ring?  Shouldn't be but you never know.
> 

	I'm hoping this is a typo and you mean 25 usec. On a high speed link
25 msec of delay would cause massive packet loss as the buffers filled, even
25 usec may be too much (assuming something caused a brief pause in an other
wise fast stream) depending on link speed. I suspect this should be modifiable
somehow for folks with fast links and/or we should create a counter to see how
often it occurs and if it occurs when Martijn loses packets :-). This may 
be why I used to use large buffers in pf-ring, I may have run in to packet 
loss. Unfortunatly its a long time ago now and I don't remember exactly but
I was experimenting on an HPC link that was saturating a wide area gigabit 
light path with jumbo frames (` 995 megabits per second). 

> 
> In the next round, we're going to add the multi-threaded ArgusSource.c to argus,
> which means we're going to spawn a thread to read the packets, a thread per
> interface, and do a better job with scheduling.  In order to do a good job with this,
> I'll be adding DAG specific routines, and I can add pf_ring specific routines as well.
> If that would be a good idea.

	As I said I haven't looked at pf-ring in about 5 years (the HPC guys
went to 10 gig and took away my toy :-)) but it used to be a new userland
pcap library that emulated standard pcap it didn't have its own interface but
that may have changed by now. 

> 
> One thing that would be useful, if you still have the packet files, what type of packet
> was the first one that was lost, in the tcpdump capture (packet 1 of the 3846 other packets).
> If it was non-IP or something other than TCP, that maybe a clue.

	A link speed calculation may also be useful, i.e. is ~4000 packets 
around 25 msec of time on the wire or would it cause that many lost packets
with the 16K packet buffer set on pf-ring :-)? 
	I've been thinking about how to measure packet loss (my favorite method
is to use tcpreplay in a test bed to inject a known number of packets to the
argus and see what comes out, but that doesn't work that well at gig level
speeds until we get better hardware :-)). The ethernet card knows how many 
packets it passed to bpf. If we could get that number (of it it is already 
there) in to the pcap record that would help. As argus starts it notes the 
current interface packet count. As it ends it notes the interface packet count 
again and compares that to its packet count. The difference is the loss 
(although we don't know where it was, we know it occurred and how large it 
was). In between times it should be close but there may be packets in transit
(i.e. past the interface but not yet through pcap) which will throw the count
off slightly. If pcap also records how many packets it passed successfully to
the application that narrows the source of loss even further. 

Peter Van Epp