jkim2008-08-29 20:34:06 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
SVN rev 182462 on 2008-08-29 20:34:06Z by jkim
Make bpf_maxinsns visible from ng_bpf.c.
Pass me the pointyhat, please.
Revision ChangesPath
1.201 +1 -1
dwmalone2008-08-16 11:48:10 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
sys/net bpf.c bpf.h
Log:
SVN rev 181783 on 2008-08-16 11:48:10Z by dwmalone
MFC:
Add a new ioctl for changing the read filter (BIOCSETFNR). This is
just like BIO
jkim2008-08-07 20:06:49 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/net bpf.c
Log:
SVN rev 181388 on 2008-08-07 20:06:49Z by jkim
MFC:r180515
Allow injecting big packets via bpf(4) up to min(MTU, 16K-byte).
Revision
jkim2008-08-07 20:06:09 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
sys/net bpf.c
Log:
SVN rev 181387 on 2008-08-07 20:06:09Z by jkim
MFC:r180515
Allow injecting big packets via bpf(4) up to min(MTU, 16K-byte).
Revision
csjp2008-08-01 21:38:46 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
SVN rev 181135 on 2008-08-01 21:38:46Z by csjp
Annotate why we do not call BPF_CHECK_DIRECTION() in this tapping routine.
There is no way for the caller to tell us which
rwatson 2008-07-30 14:04:01 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
sys/net bpf.c
Log:
SVN rev 180997 on 2008-07-30 14:04:01Z by rwatson
Merge r175903 from head to stable/7:
Add comment that bpfread() has multi-threading issue
jkim2008-07-14 22:41:48 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
SVN rev 180515 on 2008-07-14 22:41:48Z by jkim
Allow injecting big packets via bpf(4) up to min(MTU, 16K-byte).
MFC after: 1 week
Revision ChangesPath
dwmalone2008-07-07 09:25:49 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c bpf.h
Log:
SVN rev 180337 on 2008-07-07 09:25:49Z by dwmalone
Add a new ioctl for changing the read filter (BIOCSETFNR). This is
just like BIOCSETF but it doesn't drop all the
csjp2008-07-05 20:11:28 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c bpf_zerocopy.c bpf_zerocopy.h
Log:
SVN rev 180310 on 2008-07-05 20:11:28Z by csjp
Make sure we are clearing the ZBUF_FLAG_IMMUTABLE any time a free buffer
is reclaimed by the
On Tuesday 27 May 2008 11:00:18 am Christian S.J. Peron wrote:
> John
>
> Sorry for the delay. I don't think there was a reason. I just
> took a look at the change and i think it should be safe to be MFCed
So I just thought of one problem with these changes. They don't lock Giant
around ifnet
jhb 2008-05-19 18:19:48 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/net bpf.c
Log:
MFC: Set D_TRACKCLOSE to avoid a race in devfs that could lead to orphaned
bpf devices never getting fully closed.
RevisionChangesPath
jhb 2008-05-19 18:18:58 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
sys/net bpf.c
Log:
MFC: Set D_TRACKCLOSE to avoid a race in devfs that could lead to orphaned
bpf devices never getting fully closed.
Revision ChangesPath
jhb 2008-05-09 19:29:08 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Set D_TRACKCLOSE to avoid a race in devfs that could lead to orphaned bpf
devices never getting fully closed.
MFC after: 3 days
Revision ChangesPath
1.19
On Thursday 14 June 2007 10:53:51 pm Christian S.J. Peron wrote:
> csjp2007-06-15 02:53:51 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/net bpf.c
> Log:
> - Conditionally pickup Giant around the network interface
> ioctl routines if we are running
jkim2008-05-05 15:07:07 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
sys/net bpf.c
Log:
MFC:1.194
Check packet directions more properly instead of just checking received
interface is null.
Revision ChangesPath
1.181
jkim2008-04-28 19:42:11 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Check packet directions more properly instead of just checking received
interface is null.
PR: kern/123138
Submitted by: Dmitry (hanabana at mail dot ru)
jkim2008-04-22 15:53:07 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
sys/net bpf.c
Log:
Fix a mis-merge in the previous commit.
Revision ChangesPath
1.181.2.3 +2 -0 src/sys/net/bpf.c
_
jkim2008-04-22 15:45:53 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
sys/net bpf.c
Log:
MFC:1.192, 1.193
Remove M_SKIP_FIREWALL abuse and add more appropriate check.
Revision ChangesPath
1.181.2.2 +13 -15src/sys/
jkim2008-04-15 17:08:24 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Revert the previous commit and use M_PROMISC flag instead.
It is safer because it will never be used for outgoing packets.
Revision ChangesPath
1.193 +17 -8
jkim2008-04-15 00:50:01 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Remove M_SKIP_FIREWALL abuse and add more appropriate check.
Pointyhat to: jkim
Reported by:Eugene Grosbein (eugen at kuzbass dot ru)
MFC after: 3 days
rwatson 2008-04-07 02:51:00 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c bpf_zerocopy.c bpf_zerocopy.h
share/man/man4 bpf.4
Log:
Maintain and observe a ZBUF_FLAG_IMMUTABLE flag on zero-copy BPF
buffer kernel descriptors, which is used to allo
rwatson 2008-03-25 07:41:33 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Check for a NULL free buffer pointer in BPF before invoking
bpf_canfreebuf() in order to avoid potentially calling a non-inlinable
but trivial function in zero-copy buffer m
On Mon, Mar 24, 2008 at 01:49:18PM +, Christian S.J. Peron wrote:
[..]
>
> Changes to libpcap will be made available as a patch for the time being,
> and further refinements to the implementation are expected.
>
Here is a patch that people can use to test:
http://people.freebsd.org
csjp2008-03-24 13:49:18 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c bpf.h bpfdesc.h
share/man/man4 bpf.4
sys/conf files
Added files:
sys/net bpf_buffer.c bpf_buffer.h bpf_zerocopy.c
rwatson 2008-03-01 11:38:26 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/net bpf.c bpf.h
Log:
Merge bpf.c:184, bpf.h:1.49 from HEAD to RELENG_6:
Remove trailing whitespace from lines in BPF.
Minor tweaks to account for minor ch
rwatson 2008-02-02 20:35:05 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Add comment that bpfread() has multi-threading issues.
Fix minor white space nit.
Revision ChangesPath
1.186 +4 -1 src/sys/net/bpf.c
__
rwatson 2007-12-25 13:24:02 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c bpf_filter.c
Log:
Use __FBSDID() in the kernel BPF implementation.
MFC after: 3 days
Revision ChangesPath
1.185 +3 -2 src/sys/net/bpf.c
1.29 +3
rwatson 2007-12-23 14:10:34 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c bpf.h
Log:
Remove trailing whitespace from lines in BPF.
MFC after: 3 days
Revision ChangesPath
1.184 +3 -3 src/sys/net/bpf.c
1.49 +4 -4 sr
csjp2007-11-03 17:13:16 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/net bpf.c
Log:
MFC revision 1.182
Fix PID portion of stats in scenarios where the peer forks
RevisionChangesPath
1.153.2.12 +2 -0 src/sys/ne
thompsa 2007-10-24 21:15:55 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/net bpf.c
Log:
MFC r1.181
Check for multicast destination on bpf injected packets.
RevisionChangesPath
1.153.2.11 +19 -4 src/sys/net/bpf.c
___
csjp2007-10-20 15:09:24 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_7)
sys/net bpf.c
Log:
MFC bpf.c revision 1.182
Approved by:re@ (kensmith)
Revision ChangesPath
1.181.2.1 +2 -0 src/sys/net/bpf.c
csjp2007-10-12 14:58:34 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Make sure that we refresh the PID on read(2) and write(2) operations.
This fixes the process portion of the bpf(4) stats if the peer forks
into the background after it's ope
thompsa 2007-09-10 00:03:06 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Check for multicast destination on bpf injected packets and update the M_*CAST
flags, the absense of these flags causes problems in other areas such as
bridging which expect
csjp2007-06-17 21:51:44 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Silence some gcc 4 warnings. It is expected that the bpf_movein() routine
will intialize the the header length and re-initialize the mbuf pointer
to reference the mbuf that
csjp2007-06-15 02:53:51 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
- Conditionally pickup Giant around the network interface
ioctl routines if we are running with !mpsafenet
- Change un-conditional Giant acquisition around ifpromisc
t
csjp2007-02-17 20:52:55 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/net bpf.c
Log:
MFC revision 1.168
ANSI cleanup, no functional change. This should make merging a bit easier.
RevisionChangesPath
1.153.2.10 +48 -
rwatson 2007-01-28 16:38:44 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Remove slightly dubious comment; add descriptive strings for several
sysctls.
MFC after: 3 days
Revision ChangesPath
1.175 +2 -5 src/sys/net/bpf
dwmalone2006-08-21 12:42:26 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_4)
sys/net bpf.c
Log:
MFC: 1.170 Give the same timestamp for each packet to all BPF listeners.
Revision ChangesPath
1.59.2.15 +26 -13src/sys/net/bpf.c
dwmalone2006-08-21 12:28:58 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_5)
sys/net bpf.c
Log:
MFC: 1.170 Give the same timestamp for each packet to all BPF listeners.
RevisionChangesPath
1.133.2.11 +35 -8 src/sys/net/bpf.c
__
dwmalone2006-08-18 15:58:16 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/net bpf.c
Log:
MFC: Give the same timestamp for each packet to all BPF listeners.
Revision ChangesPath
1.153.2.8 +31 -6 src/sys/net/bpf.c
__
rwatson 2006-08-09 16:30:26 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Since bpf_allocbufs() uses malloc() with M_WAITOK, don't check return
values for NULL or return an error state. Assert that all three bpf
buffer pointers are NULL before st
On Tue, 25 Jul 2006, Jung-uk Kim wrote:
On Tuesday 25 July 2006 03:01 pm, David Malone wrote:
It sounds to me like a reasonable thing to do would be to pass up
a raw version of the timestamp (as returned by the hardware). We'd
also pass up the regular microtime() timestamp. You can then do any
In message: <[EMAIL PROTECTED]>
David Malone <[EMAIL PROTECTED]> writes:
: > I'm not sure I know what you mean by "trivial timecounter", but the
: > only reason we don't have a way to deregister a timecounter yet is
: > that so far I'm probably the only one who have ever need it :-)
:
On Tuesday 25 July 2006 04:12 pm, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Jung-uk Kim
writes:
> >I hit send button before I read this. :-) Yes, that's exactly
> > what I meant. BTW, what's your opinion on extending timecounter
> > API to be able to register/deregister trivial
> The first gottcha to look out for is upper/lower half rollover issues,
> if you read it as two 32 bit registers: you need to check if the
> lower part rolled over without the upper part getting updated, or
> the more pathological case: the upper part being updated before
> the lower part rolled v
In message <[EMAIL PROTECTED]>, David Malone writes:
>> I'm not sure I know what you mean by "trivial timecounter", but the
>> only reason we don't have a way to deregister a timecounter yet is
>> that so far I'm probably the only one who have ever need it :-)
>
>I was thinking about this recently
> I'm not sure I know what you mean by "trivial timecounter", but the
> only reason we don't have a way to deregister a timecounter yet is
> that so far I'm probably the only one who have ever need it :-)
I was thinking about this recently too actually, as I was going to
see how good the 64 bit co
In message <[EMAIL PROTECTED]>, Jung-uk Kim writes:
>I hit send button before I read this. :-) Yes, that's exactly what I
>meant. BTW, what's your opinion on extending timecounter API to be
>able to register/deregister trivial timecounter?
I'm not sure I know what you mean by "trivial timecou
On Tuesday 25 July 2006 03:39 pm, David Malone wrote:
> > > It sounds to me like a reasonable thing to do would be to pass
> > > up a raw version of the timestamp (as returned by the
> > > hardware). We'd also pass up the regular microtime() timestamp.
> > > You can then do any postprocessing to sy
> > It sounds to me like a reasonable thing to do would be to pass up
> > a raw version of the timestamp (as returned by the hardware). We'd
> > also pass up the regular microtime() timestamp. You can then do any
> > postprocessing to syncronise timestamps later in userland?
> Nope. In that case,
On Tuesday 25 July 2006 03:20 pm, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, David Malone
writes:
> >> > libpcap does not need to be modified; it works already for
> >> > wireless. The fact that the DLT is named DLT_IEEE802_11_RADIO
> >> > is a bit of a misnomer; it's not entirely
On Tuesday 25 July 2006 03:01 pm, David Malone wrote:
> > > libpcap does not need to be modified; it works already for
> > > wireless. The fact that the DLT is named DLT_IEEE802_11_RADIO
> > > is a bit of a misnomer; it's not entirely 802.11-specific.
> >
> > Ah, you mean we just exploit DLT_IEEE80
In message <[EMAIL PROTECTED]>, David Malone writes:
>> > libpcap does not need to be modified; it works already for
>> > wireless. The fact that the DLT is named DLT_IEEE802_11_RADIO is a
>> > bit of a misnomer; it's not entirely 802.11-specific.
>
>> Ah, you mean we just exploit DLT_IEEE802_11_RA
> > libpcap does not need to be modified; it works already for
> > wireless. The fact that the DLT is named DLT_IEEE802_11_RADIO is a
> > bit of a misnomer; it's not entirely 802.11-specific.
> Ah, you mean we just exploit DLT_IEEE802_11_RADIO. Hmm... How about
> processing overhead? Can we sy
On Tuesday 25 July 2006 12:18 pm, Sam Leffler wrote:
> Jung-uk Kim wrote:
> > On Monday 24 July 2006 08:52 pm, Sam Leffler wrote:
> >> Jung-uk Kim wrote:
> >>> On Monday 24 July 2006 01:38 pm, David Malone wrote:
> > Thanks for taking care of this! It is not very desirable for
> > the same
Jung-uk Kim wrote:
> On Monday 24 July 2006 08:52 pm, Sam Leffler wrote:
>> Jung-uk Kim wrote:
>>> On Monday 24 July 2006 01:38 pm, David Malone wrote:
> Thanks for taking care of this! It is not very desirable for
> the same packet to have different timestamps associated with it
> acro
On Monday 24 July 2006 08:52 pm, Sam Leffler wrote:
> Jung-uk Kim wrote:
> > On Monday 24 July 2006 01:38 pm, David Malone wrote:
> >>> Thanks for taking care of this! It is not very desirable for
> >>> the same packet to have different timestamps associated with it
> >>> across different bpf peers
Jung-uk Kim wrote:
> On Monday 24 July 2006 01:38 pm, David Malone wrote:
>>> Thanks for taking care of this! It is not very desirable for the
>>> same packet to have different timestamps associated with it
>>> across different bpf peers. It certainly could cause a problem if
>>> people are using t
On Monday 24 July 2006 01:38 pm, David Malone wrote:
> > Thanks for taking care of this! It is not very desirable for the
> > same packet to have different timestamps associated with it
> > across different bpf peers. It certainly could cause a problem if
> > people are using timestamps to correlat
> Thanks for taking care of this! It is not very desirable for the same
> packet to have different timestamps associated with it across different
> bpf peers. It certainly could cause a problem if people are using
> timestamps to correlate events from different programs on the same system.
Inde
David Malone wrote:
dwmalone2006-07-24 15:42:04 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Rather than calling mircotime() in catchpacket(), make catchpacket()
take a timeval indicating when the packet was captured. Move
microtime() to the c
dwmalone2006-07-24 15:42:04 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Rather than calling mircotime() in catchpacket(), make catchpacket()
take a timeval indicating when the packet was captured. Move
microtime() to the calling functions and gr
csjp2006-07-03 20:02:06 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Adjust descriptor locking to tell the kqueue subsystem that our descriptor is
already locked. The reason to do this is to avoid two lock+unlock operations
in a row. We need
csjp2006-06-15 15:39:12 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Since we are doing some bpf(4) clean up, change a couple of function
prototypes
to be consistent. Also, ANSI'fy function definitions. There is no functional
change here.
csjp2006-06-14 02:23:28 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c bpf.h
Log:
If bpf(4) has not been compiled into the kernel, initialize the bpf interface
pointer to a zeroed, statically allocated bpf_if structure. This way the
LIST_EMPTY() mac
On Tuesday 30 May 2006 03:24 pm, Ruslan Ermilov wrote:
> ru 2006-05-30 19:24:01 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/net bpf.c
> Log:
> Fix -Wundef warnings.
>
> Revision ChangesPath
> 1.165 +7 -7 src/sys/net/bpf.c
Thanks!
Ju
ru 2006-05-30 19:24:01 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Fix -Wundef warnings.
Revision ChangesPath
1.165 +7 -7 src/sys/net/bpf.c
___
cvs-all@freebsd.org mailing list
ht
csjp2006-05-17 00:07:42 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/net bpf.c
Log:
MFC revision 1.164
Pickup locks for the BPF interface structure. It's quite possible that
bpf(4) descriptors can be added and removed on this in
csjp2006-05-07 03:21:43 UTC
FreeBSD src repository
Modified files:
sys/net bpf.c
Log:
Pickup locks for the BPF interface structure. It's quite possible that
bpf(4) descriptors can be added and removed on this interface while we
are processing stats.
MFC
maxim 2006-04-14 10:38:50 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_4)
sys/net bpf.c
Log:
MFC rev. 1.112 by mdodd: bfp could be NULL.
PR: kern/76410
Revision ChangesPath
1.59.2.14 +1 -1 src/sys/net/bpf.c
_
70 matches
Mail list logo
