> > On 3. Mar 2023, at 14:52, Rodney W. Grimes
> > wrote:
> >
> >>> On 2. Mar 2023, at 18:20, Rodney W. Grimes
> >>> wrote:
> >>>
> > On 2. Mar 2023, at 02:24, Rodney W. Grimes
> > wrote:
> >
> >> Hi group,
> >>
> >> Maybe someone can help me with this question - a
> On 3. Mar 2023, at 14:52, Rodney W. Grimes
> wrote:
>
>>> On 2. Mar 2023, at 18:20, Rodney W. Grimes
>>> wrote:
>>>
> On 2. Mar 2023, at 02:24, Rodney W. Grimes
> wrote:
>
>> Hi group,
>>
>> Maybe someone can help me with this question - as I am usually only
>>>
> > On 2. Mar 2023, at 18:20, Rodney W. Grimes
> > wrote:
> >
> >>> On 2. Mar 2023, at 02:24, Rodney W. Grimes
> >>> wrote:
> >>>
> Hi group,
>
> Maybe someone can help me with this question - as I am usually only
> looking at L4 and the top side of L3 ;)
>
>
> On 2. Mar 2023, at 18:20, Rodney W. Grimes
> wrote:
>
>>> On 2. Mar 2023, at 02:24, Rodney W. Grimes
>>> wrote:
>>>
Hi group,
Maybe someone can help me with this question - as I am usually only
looking at L4 and the top side of L3 ;)
In order to validate a p
> > On 2. Mar 2023, at 02:24, Rodney W. Grimes
> > wrote:
> >
> >> Hi group,
> >>
> >> Maybe someone can help me with this question - as I am usually only
> >> looking at L4 and the top side of L3 ;)
> >>
> >> In order to validate a peculiar switches behavior, I want to adjust some
> >> fiel
> On 2. Mar 2023, at 02:24, Rodney W. Grimes
> wrote:
>
>> Hi group,
>>
>> Maybe someone can help me with this question - as I am usually only
>> looking at L4 and the top side of L3 ;)
>>
>> In order to validate a peculiar switches behavior, I want to adjust some
>> fields in gracious arps
> Hi group,
>
> Maybe someone can help me with this question - as I am usually only
> looking at L4 and the top side of L3 ;)
>
> In order to validate a peculiar switches behavior, I want to adjust some
> fields in gracious arps sent out by an interface, after a new IP is
> assigned or changed
> On 1. Mar 2023, at 22:10, Scheffenegger, Richard
> wrote:
>
>>> On 1. Mar 2023, at 21:33, Scheffenegger, Richard
>>> wrote:
>>>
>>> Hi group,
>>>
>>> Maybe someone can help me with this question - as I am usually only looking
>>> at L4 and the top side of L3 ;)
>>
>>> In order to validat
>> On 1. Mar 2023, at 21:33, Scheffenegger, Richard wrote:
>>
>> Hi group,
>>
>> Maybe someone can help me with this question - as I am usually only looking
>> at L4 and the top side of L3 ;)
>
>> In order to validate a peculiar switches behavior, I want to adjust some
>> fields in gracious arps
> On 1. Mar 2023, at 21:33, Scheffenegger, Richard wrote:
>
> Hi group,
>
> Maybe someone can help me with this question - as I am usually only looking
> at L4 and the top side of L3 ;)
>
> In order to validate a peculiar switches behavior, I want to adjust some
> fields in gracious arps sent
Do not allocate MJUM9BYTES clusters under any circumstances. Trying
to allocate them when the system is under memory pressure is
enormously expensive and stands a good chance of livelocking the
system if you try to allocate too many too quickly, even when
allocating with M_NOWAIT.
Honestly, suppo
On 21 Nov 2017, at 17:14, Catalin Salgau wrote:
Actually m_getm2() will always produce a chain for a size larger than
the page size, due to m_getjcl() being called with MJUMPAGESIZE every
time a large buffer is requested. The function could probably be
called
with MJUM9BYTES in this case, but t
On 20/11/2017 11:26 pm, Kristof Provost wrote:
> On 19 Nov 2017, at 19:49, Catalin Salgau wrote:
>
> I'm trying to address the limitation in (upstream) net/vblade that was
> brought up in
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205164
> This is related to writes large
On 19 Nov 2017, at 19:49, Catalin Salgau wrote:
I'm trying to address the limitation in (upstream) net/vblade that was
brought up in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205164
This is related to writes larger than hw.pagesize but smaller than the
configured MTU with BPF.
I traced th
On 30/12/2015 12:22 PM, Juan Herrera wrote:
Hello BSD folks,
I am developing a networking application in C and I have a question
regarding BPF (Berkeley Packet Filters),
I will give you an idea of the app first, I need to send a packet from
machine A to machine B (any kind of packet) so for thi
On 30/12/2015 6:26 AM, Juan Herrera wrote:
Hello,
I have a question regarding Berkeley Packet filter, which is Can I read an
incoming packet length with BPF, I am working on a project that requires to
filter the receiving packets in the kernel before they get to userspace,
but I need to be able
On Thursday, May 23, 2013 5:05:39 pm Guy Helmer wrote:
>
> On Jan 9, 2013, at 2:35 PM, John Baldwin wrote:
>
> > On Tuesday, November 13, 2012 4:40:57 pm Guy Helmer wrote:
> >> To try to completely resolve the race in bpfread(), I have put together
> > these changes to add a flag to indicate wh
On Jan 9, 2013, at 2:35 PM, John Baldwin wrote:
> On Tuesday, November 13, 2012 4:40:57 pm Guy Helmer wrote:
>> To try to completely resolve the race in bpfread(), I have put together
> these changes to add a flag to indicate when the hold buffer cannot be
> modified because it is in use. Sinc
On Jan 11, 2013, at 5:48 PM, Christian Peron wrote:
> Guy,
>
> Can you please describe the race and how to reproduce it? When we introduced
> zerocopy-bpf, we also introduced bpf_bufheld() and bpf_bufreclaimed() which
> are effectively nops for the regular buffer mode. Maybe we could maintain
I meant "nops" for the regular buffer mode…
On 2013-01-11, at 5:48 PM, Christian Peron wrote:
> Guy,
>
> Can you please describe the race and how to reproduce it? When we introduced
> zerocopy-bpf, we also introduced bpf_bufheld() and bpf_bufreclaimed() which
> are effectively hops for the reg
Guy,
Can you please describe the race and how to reproduce it? When we introduced
zerocopy-bpf, we also introduced bpf_bufheld() and bpf_bufreclaimed() which are
effectively hops for the regular buffer mode. Maybe we could maintain state
there as well? In any case, I would like to understand th
On Tuesday, November 13, 2012 4:40:57 pm Guy Helmer wrote:
> To try to completely resolve the race in bpfread(), I have put together
these changes to add a flag to indicate when the hold buffer cannot be
modified because it is in use. Since it's my first time using mtx_sleep() and
wakeup(), I wa
On 04.06.2012 18:31, Michael Pounov wrote:
Kernel crash when you wish to change interface name from vlan0 to other name
It seems to be in arrival/departure events.
Yes, this is already fixed in r236559.
--
WBR, Alexander
___
freebsd-net@freebsd.org
On Mon, 2012-06-04 at 17:31 +0300, Michael Pounov wrote:
> Kernel crash when you wish to change interface name from vlan0 to other name
>
> It seems to be in arrival/departure events.
>
> 1) when I set up vlan0 and change name to mgmt and after that destroy mgmt.
> kernel crash in bpfdetach() at
> I hope this is the appropriate list. I am having issues using BPFs to
> filter out traffic captures. If I want to block a specific host by IP, the
> traffic is still recorded. I tried tcpdump and get the same results.
>
> Am I missing something?
Does your igb2 interface use VLAN encapsulatio
I "evaluated" Avahi, but it is too big for my needs. I will check howl
too. However Zeroconf seems relatively easy to implement, plus i need
this module to work in cooperation with others. The License does
matter too :)
On Thu, Nov 6, 2008 at 8:14 PM, Eygene Ryabinkin <[EMAIL PROTECTED]> wrote:
>
Just a side note.
Thu, Nov 06, 2008 at 07:54:13PM +0200, Ivo Vachkov wrote:
> P.S. I'm implementing part of RFC3927 (ZeroConf) as part of a bigger project
Had you glanced at /usr/ports/net/howl and may be /usr/ports/net/avahi?
--
Eygene
____ _.--. #
\`.|\.....-'`
I use following code:
/* Send Announce Packet */
int zc_freebsd_sendannounce(int fd, unsigned char *mac, int zc_addr) {
unsigned char *announce = NULL;
int i = 0;
unsigned int packet_len = 0;
struct ether_header *eth_hdr = NULL;
struct ether_arp *e
On Thu, 6 Nov 2008, Ivo Vachkov wrote:
I am using simple write() calls to send packets over BPF file descriptor.
The BPF file descriptor is in buffered read mode (I assume this is the
default and I do not set it explicitly). From what I see my write() calls
are somewhat buffered. Since timing
On Tue, Jul 15, 2008 at 14:25 -0700, you wrote:
>> Thanks for the suggestion. Here's the netstat -B output at the time
>> it has stalled (after about 6 hours of working normally):
[...]
> at your rate of receiving packets, it passed that value about
> 2 minutes before this snapshot was taken..
S
Robin Sommer wrote:
On Mon, Jul 14, 2008 at 14:44 +0100, Bruce M. Simpson wrote:
One place to start might be: netstat -B output in 7.x (I *think* this got
MFCed), this will let us see what the drop count is for the Bro process,
and what the flags are for the open BPF descriptors in the system.
On Mon, Jul 14, 2008 at 14:44 +0100, Bruce M. Simpson wrote:
> One place to start might be: netstat -B output in 7.x (I *think* this got
> MFCed), this will let us see what the drop count is for the Bro process,
> and what the flags are for the open BPF descriptors in the system.
Thanks for th
Robin Sommer wrote:
Hi all,
we're seeing some strange effects with our libpcap-based application
(the Bro network intrusion detection system) on a FreeBSD 7-RELEASE
system. As the application has always been running fine on 6.x,
we're wondering whether this might be triggered by any of the
chang
On Tuesday 15 April 2008 12:11 pm, Jung-uk Kim wrote:
> On Tuesday 15 April 2008 11:05 am, Jung-uk Kim wrote:
> > On Tuesday 15 April 2008 09:51 am, Eugene Grosbein wrote:
> > > > Can you try the attached patch?
> > >
> > > Works for me :-)
> >
> > Sorry, I committed a different version:
> >
> > ht
On Tuesday 15 April 2008 11:05 am, Jung-uk Kim wrote:
> On Tuesday 15 April 2008 09:51 am, Eugene Grosbein wrote:
> > > Can you try the attached patch?
> >
> > Works for me :-)
>
> Sorry, I committed a different version:
>
> http://docs.freebsd.org/cgi/mid.cgi?200804150050.m3F0o1aV091591
>
> This p
On Tuesday 15 April 2008 09:51 am, Eugene Grosbein wrote:
> > Can you try the attached patch?
>
> Works for me :-)
Sorry, I committed a different version:
http://docs.freebsd.org/cgi/mid.cgi?200804150050.m3F0o1aV091591
This patch does not touch m_flags any more. Can you test it again?
Thanks!
> Can you try the attached patch?
Works for me :-)
Thanks!
Eugene Grosbein
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Jung-uk Kim wrote:
> Can you try the attached patch?
I will this evening when get to my 7.0 home system.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Saturday 12 April 2008 02:22 am, Eugene Grosbein wrote:
> Hi!
>
> One of 7.0 users has reported in some cyrillic newsgroup
> a problem that I have reproduced in my 7.0-STABLE system.
> That is: tcpdump does not show locally originated outgoing IP
> packets that were processed by 'ipfw fwd' rule.
On Sat, Apr 12, 2008 at 07:10:38PM +0100, Robert Watson wrote:
> If you ping from host A to host B, does tcpdump see both the ICMP echo
> request and reply on both boxes? In principle, ipfw fwd uses the same
> output paths as the rest of the IP stack, so it would be useful to know
> whether it
On Sat, 12 Apr 2008, Eugene Grosbein wrote:
One of 7.0 users has reported in some cyrillic newsgroup a problem that I
have reproduced in my 7.0-STABLE system. That is: tcpdump does not show
locally originated outgoing IP packets that were processed by 'ipfw fwd'
rule. The same configuration p
On Sat, Apr 12, 2008 at 01:50:17PM +0100, Alireza Torabi wrote:
> It'll be in tcpdump code where it sets up BPF. It's a new IOCTL in 7 BPF.
How to check?
> Is your tcpdump source up to date?
I use stock tcpdump that comes with 7.0-STABLE.
Eugene Grosbein
___
It'll be in tcpdump code where it sets up BPF. It's a new IOCTL in 7 BPF.
Is your tcpdump source up to date?
On Sat, Apr 12, 2008 at 1:43 PM, Eugene Grosbein <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 12, 2008 at 11:53:00AM +0100, Alireza Torabi wrote:
>
> > Is BIOCFEEDBACK set?
>
> What's that an
On Sat, Apr 12, 2008 at 11:53:00AM +0100, Alireza Torabi wrote:
> Is BIOCFEEDBACK set?
What's that and how to check it?
Eugene Grosbein
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send
Is BIOCFEEDBACK set?
On Sat, Apr 12, 2008 at 7:22 AM, Eugene Grosbein <[EMAIL PROTECTED]> wrote:
> Hi!
>
> One of 7.0 users has reported in some cyrillic newsgroup
> a problem that I have reproduced in my 7.0-STABLE system.
> That is: tcpdump does not show locally originated outgoing IP packet
Ok I have read this again,
I think you are trying to hijack a session before the intended
target can start it up... but you have some problems.
The original packets will continue on to the intended server so it
will respond as well. And when the session you have created
starts talking, that origi
Alireza Torabi wrote:
On Fri, Mar 21, 2008 at 6:35 AM, Peter Jeremy
<[EMAIL PROTECTED]> wrote:
On Thu, Mar 20, 2008 at 11:27:53AM +, Alireza Torabi wrote:
>Imagine this:
>
> | (1)
>packets
> | | (4)
>[nic1] [nic2]
>
On Fri, Mar 21, 2008 at 6:35 AM, Peter Jeremy
<[EMAIL PROTECTED]> wrote:
> On Thu, Mar 20, 2008 at 11:27:53AM +, Alireza Torabi wrote:
> >Imagine this:
> >
> > | (1)
> > packets
> > | | (4)
> >[nic1] [nic2]
> > bpf
On Thu, Mar 20, 2008 at 11:27:53AM +, Alireza Torabi wrote:
>Imagine this:
>
> | (1)
> packets
> | | (4)
>[nic1] [nic2]
> bpf SOCK_STREAM
> | (2)|
> [FreeBSD] (3)
>
>1) all
rom B)
hope this helps.
On 3/20/08, Vadim Goncharov <[EMAIL PROTECTED]> wrote:
> Hi Alireza Torabi!
>
> On Thu, 20 Mar 2008 10:57:39 +; Alireza Torabi wrote about 'Re: bpf
> packet capture and SOCK_STREAM socket redirects...':
>
> > That's sort of t
Hi Alireza Torabi!
On Thu, 20 Mar 2008 10:57:39 +; Alireza Torabi wrote about 'Re: bpf packet
capture and SOCK_STREAM socket redirects...':
> That's sort of the problem. I've got a data link capture of the packet
> (bpf) and let say I redirect this packet to
Thanks for reply.
That's sort of the problem. I've got a data link capture of the packet
(bpf) and let say I redirect this packet to a SOCK_STREAM on another
machine and the whole thing will work fine (OK after rewritting some
mac and ip and checksums...).
I just need to do this on the SOCK_STRE
Hi Alireza Torabi!
On Thu, 20 Mar 2008 09:43:52 +; Alireza Torabi wrote about 'bpf packet
capture and SOCK_STREAM socket redirects...':
> Is it possible to redirect/send/divert a bpf packet capture of one
> interface to a listening tcp socket on another interface of the same
> machine?
> He
On Nov 18, 2007 7:18 PM, Matthew Luckie <[EMAIL PROTECTED]> wrote:
> BIOCSETF and BIOCSETWF call reset_d which discards any packets
> currently in the hold buffer and resets the packet rx count.
>
> The patch below adds BIOCSETFNR, an ioctl that swaps the BPF filter
> without resetting the hold buf
On 7/5/06, Vlad GALU <[EMAIL PROTECTED]> wrote:
I was debugging a dspam->clamav connection and I saw two packets
which didn't belong to the loopback interface. The destination IP was
assigned to one of the physical interfaces, and the source IP was
somewhere on the internet. I've no idea how
On Thu, Feb 23, 2006 at 03:19:46AM -0500, Kris Kennaway wrote:
> I ran tcpdump and killall tcpdump in a loop on 7.0, and after a few
> minutes it panicked with:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x8
> fault code = supervis
I'd suggest a name like DLT_PSEUDO might be better -- it may be helpful to
get review for the change from the NetBSD and OpenBSD guys too, as well as
the tcpdump.org guys.
I posted a patch to netbsd tech-kern and have had positive feedback:
http://mail-index.netbsd.org/tech-net/2005/06/09/0003.
On Jun 7, 2005, at 4:56 PM, Matthew Luckie wrote:
Agreed. When you use BPF or PCAP to capture packets, for the
DTL_NULL case there is a 4-byte offset between where PCAP says
the packet starts and where the actual raw IP packet starts.
If you want BPF/PCAP to return packets without the 4-byt
this was the behaviour expected of most DLT_NULL bpf devices already
(passing a 32bit int when writing). It is important to note that the
behaviour of BPF writers does not change in these cases, and my patch
is merely a bug fix.
Agreed. When you use BPF or PCAP to capture packets, for the
On Jun 7, 2005, at 3:54 PM, Matthew Luckie wrote:
I'd be wary of changing the definition of DLT_NULL however -- it
literally
means 'there's nothing here apart from raw data', and changing
this notion
would mean that we have to change it everywhere, including bpf
clients,
because the change b
I'd be wary of changing the definition of DLT_NULL however -- it literally
means 'there's nothing here apart from raw data', and changing this notion
would mean that we have to change it everywhere, including bpf clients,
because the change being proposed would make DLT_NULL mean 'there's a 32-bit
On Tue, Jun 07, 2005 at 10:19:29PM +1200, Matthew Luckie wrote:
> Please review.
This is good and useful work. It looks like something which has been in
need of cleanup for a while.
Unfortunately my current situation re resources (time and infrastructure)
means that whilst I can review and commit
> is there a good reason why _all_ DLT_NULL bpf devices could not simply
> have writes supported? the user space application would pass the
> address family in the first 4 bytes of the packet; this is currently
> done anyway for if_disc, if_loop, if_tun, if_faith, and ng_iface.
> ip_carp could get
> > If I was to pursue this, would someone on this list consider committing the
> > work to current?
> ...
> > + case DLT_NULL:
> > + sockp->sa_family = AF_UNSPEC;
> > + if(strcmp(ifp->if_name, "tun") == 0)
> > + hlen = sizeof(int);
> > + else
> > +
On Mon, Jun 06, 2005 at 08:16:38PM +1200, Matthew Luckie wrote:
> If I was to pursue this, would someone on this list consider committing the
> work to current?
...
> + case DLT_NULL:
> + sockp->sa_family = AF_UNSPEC;
> + if(strcmp(ifp->if_name, "tun") == 0)
> +
> I can successfully write BPF packets up to 1500 bytes in size (1496 IP
> bytes without the address family integer). Writes larger than this
> return EMSGSIZE.
http://lists.freebsd.org/pipermail/freebsd-net/2005-May/007371.html
Just for the record, the patch below fixes this on 4.11; the same
In article <[EMAIL PROTECTED]>,
Sam Leffler <[EMAIL PROTECTED]> wrote:
> My point is that the extra calls to bpf_mtap would harm performance
> even when bpf wasn't being used.
In -current I believe all the calls are prefixed with a check for
ifp->if_bpf or similar. So any slow down should only ha
On Tue, Aug 05, 2003 at 11:17:07AM -0700, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Edwin Groothuis <[EMAIL PROTECTED]> wrote:
>
> > This afternoon I ran into the ever lasting of "bpf runs before ipfw"
> > problem again: when you run tcpdump and you get all the rubbish
> > coming fr
In article <[EMAIL PROTECTED]>,
Petri Helenius <[EMAIL PROTECTED]> wrote:
> >
> > This would add additional delays to the code path for both ingress
> > and egress. In a world where gigabit ethernet is becoming the norm,
> > every nanosecond counts. I don't think the benefits of your proposal
> >
one thing one could do is to add special 'interface names'
to the list recognised by /dev/bpf (e.g. "ipfw", "ipf", etc)
in bpf_setif(), and insert calls to bpf_mtap() at the end
of ipfw_check() and friends. Now the question is, of course,
do you want only 'accept'ed packets, or all of them ?
In th
In article <[EMAIL PROTECTED]>,
Petri Helenius <[EMAIL PROTECTED]> wrote:
>
> This would add additional delays to the code path for both ingress
> and egress. In a world where gigabit ethernet is becoming the norm,
> every nanosecond counts. I don't think the benefits of your proposal
> would jus
>
> This would add additional delays to the code path for both ingress
> and egress. In a world where gigabit ethernet is becoming the norm,
> every nanosecond counts. I don't think the benefits of your proposal
> would justify the performance loss. At the very least, I'd want the
> extra calls
On Tue, Aug 05, 2003 at 10:31:01AM -0400, Barney Wolff wrote:
> On Tue, Aug 05, 2003 at 11:39:23PM +1000, Edwin Groothuis wrote:
> >
> > Now my question to you guys is, does what I want or what I describe
> > here make a little bit sense? Or am I totally going the wrong way?
> > Or has this topic
On Tue, Aug 05, 2003 at 11:39:23PM +1000, Edwin Groothuis wrote:
>
> Now my question to you guys is, does what I want or what I describe
> here make a little bit sense? Or am I totally going the wrong way?
> Or has this topic already been discussed multiple times and decided
> not to do it? Maybe
In article <[EMAIL PROTECTED]>,
Sam Leffler <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > Sam Leffler <[EMAIL PROTECTED]> wrote:
> >> > My point is that the extra calls to bpf_mtap would harm performance
> >> > even when bpf wasn't being used.
> >>
> >> In -current I believe
In article <[EMAIL PROTECTED]>,
Edwin Groothuis <[EMAIL PROTECTED]> wrote:
> This afternoon I ran into the ever lasting of "bpf runs before ipfw"
> problem again: when you run tcpdump and you get all the rubbish
> coming from the public internet into an interface, while all I
> wanted to see was
In article <[EMAIL PROTECTED]>,
Sam Leffler <[EMAIL PROTECTED]> wrote:
> > My point is that the extra calls to bpf_mtap would harm performance
> > even when bpf wasn't being used.
>
> In -current I believe all the calls are prefixed with a check for
> ifp->if_bpf or similar. So any slow down sh
In article <[EMAIL PROTECTED]>,
Edwin Groothuis <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 05, 2003 at 11:17:07AM -0700, John Polstra wrote:
> > Tcpdump has always shown traffic _at_ the network interface. That's
> > why it has the "-i" option. I would not like to see that behavior
> > changed.
>
On Wed, Aug 06, 2003 at 09:54:11AM +1000, Edwin Groothuis wrote:
> On Tue, Aug 05, 2003 at 10:31:01AM -0400, Barney Wolff wrote:
> > Seems to me that with ipfw logging and tcpdump packet selection this
> > is largely a non-issue. We should be wary of adding complexity to
> > what's already at the
> How about to call ioctl(fd, BIOCSRTIMEOUT, &timeval) ?
> I think select(2) sets the fd for the bpf if the bpf buffer is full,
> or if the bpf buffer is not empty after timed out.
>
This worked for me, thanks. I must have missed it on the documentation
for some reason.
Pete
To Unsubscribe: sen
On Wed, Nov 06, 2002 at 10:03:06AM +0200, Petri Helenius wrote:
>
> The specific problem with bpf is that one might have a half-full buffer
> of captured data when the select timeout hits. In that case the select
> returns with no FDs ready while I think it really should return with
> the bpf fd.
> I believe the select operation on bpf is not functioning as supposed to.
> I'm calling select with 100ms timeout. The bpf interface is listening to
> an interface with constant packet rate, so it's certain that multiple
> packets have been received during the select call. However the fd for
> I believe you're misunderstanding the meaning of the timeout in select(2).
> Timeout applies only when no FDs are ready.
The specific problem with bpf is that one might have a half-full buffer
of captured data when the select timeout hits. In that case the select
returns with no FDs ready whil
I believe you're misunderstanding the meaning of the timeout in select(2).
Timeout applies only when no FDs are ready.
Also, you might be better off setting immediate mode on your bpf fd,
if you want a return before the buffer is full.
On Mon, Nov 04, 2002 at 12:12:26AM +0200, Petri Helenius wrot
Julian,
Thanks for your assistance. My understanding of the use and power of
netgraph is
much improved. Your first response to my question (Go to the source, ...),
gave me the
idea to filter the response "from" the process which was using BPF for it's
read and write
operations. This was done
Ipfw divers from within the IP stack
by then it's too late.
you could diver th epackets using netgraph and filter them and then
pass them back into the eiface netgraph node to continue up.
then you tell your application to listen to the "nge"
interface.. unfortunatly another driver also produce
At 04:50 PM 6/27/2002, Julian Elischer wrote:
> > Are there any other taps I may access in order to accomplish this goal?
>
>I forget the goal. sorry
No problem - Hope you don't mind if I restate it.
I am trying to strip/drop packets before they reach a server process which uses
BPF for communi
On Thu, 27 Jun 2002, Arthur Peet wrote:
>
> >Use the Source Luke!
>
> Thanks, Obi! :) I REALLY appreciate your response.
>
> >as you see, bpf copies are taken before netgraph processing..
> >and non-netgraph bridging occurs after that.
>
> It appears to me that if I switched the order in
>Use the Source Luke!
Thanks, Obi! :) I REALLY appreciate your response.
>as you see, bpf copies are taken before netgraph processing..
>and non-netgraph bridging occurs after that.
It appears to me that if I switched the order in which the processing
occurs and recompiled the kernel, the fu
Use the Source Luke!
ether_input(ifp, eh, m)
struct ifnet *ifp;
struct ether_header *eh;
struct mbuf *m;
{
struct ether_header save_eh;
/* Check for a BPF tap */
if (ifp->if_bpf != NULL) {
struct m_hdr mh;
/* T
Depends on the SIMPLEX flag I believe, but for most ethernet interfaces,
there's a software loopback. I actually take advantage of that to support
the following BPF ioctl which I added:
BIOCSSEESENT
BIOCGSEESENT (u_int) Set or get the flag determining whether locally
On Wed, 29 Aug 2001, Julian Elischer wrote:
>
> To some extent it depends on the driver.
>
> check if_ethersubr.c and the driver for your interface to be sure.
Ok, yeah, I found it. Looks like the driver gets its grubby little hands
on the packet before injecting it into bpf. I'll have him tr
To some extent it depends on the driver.
check if_ethersubr.c and the driver for your interface to be sure.
On Wed, 29 Aug 2001, Mike Silbersack wrote:
> Silly question I could probably figure out myself, but thought it would be
> quicker to ask here...
>
> When listening on an ethernet inter
* Mike Silbersack <[EMAIL PROTECTED]> [010829 13:56] wrote:
> Silly question I could probably figure out myself, but thought it would be
> quicker to ask here...
>
> When listening on an ethernet interface, are the packets you see from
> yourself intercepted inside the network stack, or are you a
> Note that the packets sent to the local IP address are not picked up by
> tcpdump. This can be tried with any traffic type, I have just used ping
> as an example.
>
> Is this the correct/desired behaviour? If it is, is there any other way
> to capture these packets?
This is the expected beha
*doh* of course... the loopback device!
thanks
Henry
On Mon, 6 Aug 2001, [EMAIL PROTECTED] wrote:
Hi,
to see the packets to 192.168.2.1 you have to specify the interface lo0,
because it's your own address. Packets to this address aren't send to fxp0.
So use:
tcpdump -ni
Hi,
to see the packets to 192.168.2.1 you have to specify the interface lo0,
because it's your own address. Packets to this address aren't send to fxp0.
So use:
tcpdump -ni lo0
Martin
> Take the following example:
> # ifconfig fxp0
> fxp0: flags=8843 mtu 1500
> inet 192.168.2.1 netmas
97 matches
Mail list logo
