Re: [tcpdump-workers] Sniffing inbound ethernet frames only

2006-10-23 Thread Jost-DVSB
Hannes Gredler wrote: > > [EMAIL PROTECTED] wrote: >> Dear tcpdump experts, >> >> I have a Linux box with two Fast Ethernet interfaces. >> In two separate windows on the desktop I want to see >> all inbound ethernet frames (from the wire), but not >> the ethernet frames coming down the local netwo

Re: [tcpdump-workers] why not filtering at driver level ?

2006-10-23 Thread Jefferson Ogata
On 2006-10-24 05:15, Guy Harris wrote: > Guy Harris wrote: > >> You forgot option 3: >> >> 3. Raise the limit on the maximum number of BPF instructions. >> > You might also have to raise the limit on socket options; see > > http://www.tcpdump.org/lists/workers/2004/05/msg7.html Well,

Re: [tcpdump-workers] why not filtering at driver level ?

2006-10-23 Thread Jefferson Ogata
On 2006-10-24 05:11, Guy Harris wrote: > 3. Raise the limit on the maximum number of BPF instructions. > > You're going to have to add stuff to, or change stuff in, the kernel to > implement this *anyway*, so you might as well just boost the maximum > number of BPF instructions and not have to

Re: [tcpdump-workers] why not filtering at driver level ?

2006-10-23 Thread Guy Harris
Guy Harris wrote: You forgot option 3: 3. Raise the limit on the maximum number of BPF instructions. You're going to have to add stuff to, or change stuff in, the kernel to implement this *anyway*, so you might as well just boost the maximum number of BPF instructions and not have to cha

Re: [tcpdump-workers] why not filtering at driver level ?

2006-10-23 Thread Guy Harris
madhuresh wrote: So the final question is "Is there any alternative way (consider operating system to be linux) apart from BPF code for kernel level filtering" ? To my understanding there can be two possibilties: 1. A new interface (say XYZ0) where only filtered packets come from driver/ker

Re: [tcpdump-workers] why not filtering at driver level ?

2006-10-23 Thread madhuresh
Thanks for correcting me. So the final question is "Is there any alternative way (consider operating system to be linux) apart from BPF code for kernel level filtering" ? To my understanding there can be two possibilties: 1. A new interface (say XYZ0) where only filtered packets come from

Re: [tcpdump-workers] why not filtering at driver level ?

2006-10-23 Thread Guy Harris
On Oct 23, 2006, at 12:56 PM, madhuresh wrote: Note, however, "in kernel space" doesn't necessarily mean "at the driver level"; on Linux, the in-kernel filtering is done by "socket filters" above the driver, and, even on BSD, although the driver directly calls the BPF routine to supply a p

Re: [tcpdump-workers] why not filtering at driver level ?

2006-10-23 Thread madhuresh
Guy Harris wrote: madhuresh wrote: I am just anxious to know that why we do filtering of packets at user space and not at driver level (kernel space). Because, on those OSes where filtering is done in user space, the OS and drivers either don't have a filtering mechanism or don't have one

Re: [tcpdump-workers] why not filtering at driver level ?

2006-10-23 Thread Guy Harris
madhuresh wrote: I am just anxious to know that why we do filtering of packets at user space and not at driver level (kernel space). Because, on those OSes where filtering is done in user space, the OS and drivers either don't have a filtering mechanism or don't have one that uses BPF progra

[tcpdump-workers] why not filtering at driver level ?

2006-10-23 Thread madhuresh
Hi, I am just anxious to know that why we do filtering of packets at user space and not at driver level (kernel space). What if libpcap can communicate the filter options to the driver under consideration which will then transfer, only the filtered packets to a new interface say ABC0. Then l

Re: [tcpdump-workers] Sniffing inbound ethernet frames only

2006-10-23 Thread Hannes Gredler
[EMAIL PROTECTED] wrote: > Dear tcpdump experts, > > I have a Linux box with two Fast Ethernet interfaces. > In two separate windows on the desktop I want to see > all inbound ethernet frames (from the wire), but not > the ethernet frames coming down the local network stack. > In the left window

Re: [tcpdump-workers] [PATCH] fix usb off by one

2006-10-23 Thread Joerg Mayer
On Sun, Oct 15, 2006 at 07:35:36PM +0200, Paolo Abeni wrote: > p.s. the gettimeofday syscall give some overhead to the sniffing code, > but currently the text interface provided by the kernel is IMHO the real > bottleneck. Could you post a kernel-patch that fixes the worst problems with the interf

[tcpdump-workers] libpcap + netlink socket

2006-10-23 Thread madhuresh
Hello friends, In the present architecture of linux kernel, 802.11 mac details are lost at the driver level. I wish to filter packets (collected on wireless interface wlan0) based on their signal strength (present in 802.11 mac). For this i wish to set filter code in the driver (hostap in m

Re: [tcpdump-workers] Sniffing inbound ethernet frames only

2006-10-23 Thread Jefferson Ogata
On 2006-10-23 15:13, [EMAIL PROTECTED] wrote: > Jefferson Ogata wrote: >> Have you tried >> >> left window: not ether src mac:addr:of:eth0 >> right window: not ether src mac:addr:of:eth1 > > Hello Jefferson, > > thanks for the quick response. > Is there a per process filtering or is there > one k

Re: [tcpdump-workers] Sniffing inbound ethernet frames only

2006-10-23 Thread Jost-DVSB
Jefferson Ogata wrote: > Have you tried > > left window: not ether src mac:addr:of:eth0 > right window: not ether src mac:addr:of:eth1 > Hello Jefferson, thanks for the quick response. Is there a per process filtering or is there one kernel filter for all processes? In the latter case the filte

Re: [tcpdump-workers] Passing the PCAP file descriptor to another

2006-10-23 Thread Guy Harris
Sebastien Raveau wrote: I'm currently trying to pass the file descriptor of a live capture to another process, so that I can have a very small (as in "auditable") privileged process able to call pcap_open_live() on the one hand, and a big/fat/ugly/gui process on the other hand running all the