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
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,
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
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
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
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
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
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
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
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
[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
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
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
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
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
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
16 matches
Mail list logo