Look, if you're going to appeal to core to approve changes for
committing then don't bother posting them to tech-net or any other list
because it is quite clear that you are not interested in feedback, only
people to rubber-stamp your ideas.
All of which to say is that I'm sorry I bothered replyin
On Thu, Aug 29, 2013, at 05:27 PM, Mindaugas Rasiukevicius wrote:
> Darren Reed wrote:
> > Mindaugas Rasiukevicius wrote:
> > > Hi,
> > >
> > > OK, to summarise what has been discussed:
> > >
> > > - Problem
> > >
> > >
Mindaugas Rasiukevicius wrote:
Hi,
OK, to summarise what has been discussed:
- Problem
There is a need to perform more complex operations from the BPF program.
Currently, there is no (practical) way to do that from the byte-code.
Such functionality is useful for the packet filters or other com
On 10/08/2013 7:23 AM, Matt Thomas wrote:
> ...
> The possibility of the COP/COPX functions doing bad things is over wrought.
> It makes the assumption of avoiding BPF and then coding everything is safer
> than using BPF and COP/COPX functions.
Depends on what you mean by "bad things."
Thus fa
On 9/08/2013 12:17 AM, Mindaugas Rasiukevicius wrote:
> Darren Reed wrote:
>> On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote:
>>> Darren Reed wrote:
>>>>>
>>>>> You do not have to use it.
>>>>
>>>> I get no c
On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote:
> Darren Reed wrote:
>>>
>>> You do not have to use it.
>>
>> I get no choice - it is in the kernel by default.
>>
>
> There is no default coprocessor. Here is your choice: do not call
> bpf_se
On 8/08/2013 3:55 AM, Mindaugas Rasiukevicius wrote:
> Darren Reed wrote:
>>>
>>> I would like propose new BPF instructions for the misc category: BPF_COP
>>> and BPF_COPX. It would provide a capability of calling an external
>>> function - think of BPF
On 5/08/2013 5:12 AM, Mindaugas Rasiukevicius wrote:
> Hello,
>
> I would like propose new BPF instructions for the misc category: BPF_COP
> and BPF_COPX. It would provide a capability of calling an external
> function - think of BPF "coprocessor".
No.
A BPF program is an entity that can be veri
Andre Oppermann wrote:
On 03.04.2012 17:38, Darren Reed wrote:
On 3/04/2012 11:45 PM, Andre Oppermann wrote:
On 01.04.2012 09:27, Darren Reed wrote:
The problem here is that it only tracks the window size as
it grows, not as it shrinks. Thus the remote end setting its
window size to 0 is
David Duchscher wrote:
On Jun 5, 2012, at 3:29 PM, Darren Reed wrote:
In IPFilter, the "map-block" ipnat rule serves exactly the
purpose that you are looking for. It provides address
translation of network addresses for N:M and uses ports
to multiplex them in.
Thus a /16 can be nat
In IPFilter, the "map-block" ipnat rule serves exactly the
purpose that you are looking for. It provides address
translation of network addresses for N:M and uses ports
to multiplex them in.
Thus a /16 can be nat'd to a /8 with the other 8 bits
used in the port number.
The results of the NAT'd pa
The problem is that you have a port range of 0 in an
ipnat.conf line. Quick solution is to ensure that all
ipnat.conf lines specify a range of ports of greater than 0.
Otherwise patch below applies.
Darren
--- /tmp/ip_nat.c.orig 2012-06-06 04:31:31.0 +1000
+++ /tmp/ip_nat.c 2012-0
> Quoting from pfil(9)
>
> When a filter is invoked, the packet appears just as if it ``came off the
> wire''. That is, all protocol fields are in network byte order. [...]
pfil(9) is already out of date with respect to FreeBSD as
FreeBSD passes both ip_len and ip_off through in host byte
or
To echo comments made on tech-net for NetBSD...
---
As much as I dislike the patch you created, I can't see any other way
to elegantly solve the problem. The reason that I don't like the change
is that it seems silly to have to put the packet in two different mbufs
after having put it all in one.
On 3/06/2012 5:11 AM, Bjoern A. Zeeb wrote:
>
> On 2. Jun 2012, at 15:53 , Darren Reed wrote:
>
>> Is there any reason that this patch hasn't been applied
>> to -current? I've just run into this and I can't believe
>> that it still exists, given th
Is there any reason that this patch hasn't been applied
to -current? I've just run into this and I can't believe
that it still exists, given that it falls into the "low
hanging fruit" category. I'll note that if it wasn't for
subversion, I'd be doing a commit rather than an email.
Darren
On 29/05/2012 9:56 AM, Julian Elischer wrote:
> On 5/28/12 7:14 AM, Darren Reed wrote:
>> On 28/05/2012 11:45 PM, Nikos Vassiliadis wrote:
>>> On 5/28/2012 1:37 PM, Darren Reed wrote:
>>>> I've looked through the list of network interfaces that are
>>>&g
On 28/05/2012 11:45 PM, Nikos Vassiliadis wrote:
> On 5/28/2012 1:37 PM, Darren Reed wrote:
>> I've looked through the list of network interfaces that are
>> supported with FreeBSD and none seem to meet my needs. What
>> I want is a network interface that I can conf
I've looked through the list of network interfaces that are
supported with FreeBSD and none seem to meet my needs. What
I want is a network interface that I can configure up in
jail A with address 10.1.1.1 and for which I can configure
a mate in jail B with the address 10.2.2.2 and use the
network
It would seem that setting $RSH to "rsh" is the cause
of my problem and that rcmd(3) cannot deal with RSH
pointing to itself.
I've filed a PR on this (possibly duplicate) but the
email with the PR# is taking its time.
Darren
___
freebsd-net@freebsd.org
I've run into a rather strange problem with rsh on FreeBSD 9.0
where rsh seems to become a fork bomb.
How or why this happens, I do not know. If I run it from the
command line with a shell, it behaves perfectly normal. Even
inside $() with pdksh. But when I put it in my script...
What does the pr
Andre Oppermann wrote:
On 03.04.2012 17:38, Darren Reed wrote:
On 3/04/2012 11:45 PM, Andre Oppermann wrote:
On 01.04.2012 09:27, Darren Reed wrote:
The problem here is that it only tracks the window size as
it grows, not as it shrinks. Thus the remote end setting its
window size to 0 is
On 4/04/2012 3:17 AM, Andre Oppermann wrote:
> On 03.04.2012 17:38, Darren Reed wrote:
>> On 3/04/2012 11:45 PM, Andre Oppermann wrote:
>>> It's the other way around. remote.ssh is sending old data
>>> which freebsd82.62922 has already ack'ed. The ses
On 4/04/2012 3:17 AM, Andre Oppermann wrote:
> On 03.04.2012 17:38, Darren Reed wrote:
>> On 3/04/2012 11:45 PM, Andre Oppermann wrote:
>>> It's the other way around. remote.ssh is sending old data
>>> which freebsd82.62922 has already ack'ed. The ses
On 3/04/2012 11:45 PM, Andre Oppermann wrote:
> On 01.04.2012 09:27, Darren Reed wrote:
>> Andre,
>>
>> Your changes bring it closer to working correctly with a
>> small change: rather than "tiwin > tp->snd_wnd", it should
>> be "tiwin != tp
Andre,
Your changes bring it closer to working correctly with a
small change: rather than "tiwin > tp->snd_wnd", it should
be "tiwin != tp->snd_wnd". In this trace, the remote end
has set a window scale factor of 5 during connection
establishment.
The same change should be made in the if() a few
Darren Reed wrote:
Andre Oppermann wrote:
On 30.03.2012 16:22, Darren Reed wrote:
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection
Andre Oppermann wrote:
On 30.03.2012 16:22, Darren Reed wrote:
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection that has a moderate d
Jason Hellenthal wrote:
On Sat, Mar 31, 2012 at 01:22:27AM +1100, Darren Reed wrote:
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection that has a moderate delay in it, FreeBSD's
TCP ignores the other end telling it that the window size
is n
Max Laier wrote:
On Sunday 25 November 2007, Darren Reed wrote:
> Max Laier wrote:
> > On Sunday 25 November 2007, Darren Reed wrote:
> > > Max Laier wrote:
> > > > On Friday 23 November 2007, Robert Watson wrote:
> > > > > On Fri, 23 Nov 2007, Max L
Max Laier wrote:
On Sunday 25 November 2007, Darren Reed wrote:
> Max Laier wrote:
> > On Friday 23 November 2007, Robert Watson wrote:
> > > On Fri, 23 Nov 2007, Max Laier wrote:
> > > > attached is a diff to switch the pfil(9) subsystem to rmlocks,
> > &g
Max Laier wrote:
On Friday 23 November 2007, Robert Watson wrote:
> On Fri, 23 Nov 2007, Max Laier wrote:
> > attached is a diff to switch the pfil(9) subsystem to rmlocks, which
> > are more suited for the task. I'd like some exposure before doing
> > the switch, but I don't expect any fallout.
ue pair for ssh.
Maybe I want to dedicate a tx/rx queue pair for my web server.
etc.
Darren
Of course, if the transmit path through the network stack isn't enabling
concurrency, a bottleneck there won't be an issue.
Louis Mamakos
Just something else to consider..
On Sep 23, 2007, a
Kip Macy wrote:
My ethng branch supports multiple rx and tx queues.
-Kip
What are your plans for how we use/manage/interact with the mutiple
rx/tx queues?
Darren
On 9/22/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
> Our newest E1000 nic, the 82575, and the Oplin 10G hardware are capabl
A project I'm looking to do in my spare time at Sun is to
create a library that provides access to some of the
more useful ioctls supported by IPFilter. The problem
with relying on ioctls is that if the data structures passed
through change then often everything needs to be
recompiled.
I current
Hi,
So i've been implementing some new features in ipfilter, whether
or not they make it a 5.0, I'm not sure...maybe a few people can
let me know what they think about that..
So what are these new features?
There are 3 new commands for ipnat.conf:
rewrite - change both source and address fields
In some email I received from Guy Harris, sie wrote:
> On Sep 8, 2004, at 2:26 AM, Bruce M Simpson wrote:
>
> > Here's a patch against 5.3 to add a per-instance switch which allows
> > the user to specify if captured packets should be timestamped (and,
> > if so, whether microtime() or the faster
In some mail from Baldur Gislason, sie said:
>
> ipfw is in no way related to the linux firewalls (ipfwadm, ipchains or
> iptables). It is a specially designed firewall for FreeBSD. It isn't
> dependent on ipf, it has it's own in-kernel mechanism. It has a totally
> different syntax. Why FreeBS
I think this is getting absurd/stupid.
What do we have 3 firewalls for in FreeBSD if people are going to
add knobs like this that just duplicate that behaviour ?
Is there something lacking in all of those firewalls that make
this necessary ?
Are they all too hard to use ?
Do they all impact per
In some email I received from Jason R Thorpe, sie wrote:
> On Thu, May 03, 2001 at 10:01:18AM +1000, Darren Reed wrote:
>
> > > BPF "expressions" are literally BPF bytecodes.
> >
> > Well, one of the goals of IPFilter is it can parse (as rules) a
In some email I received from Jason R Thorpe, sie wrote:
> On Thu, May 03, 2001 at 08:30:55AM +1000, Darren Reed wrote:
>
> > IPFilter 4.0 will, as part of its general increase in kernel bloat,
> > let you use BPF expressions for matching. There are other things
>
>
In some email I received from Gunther Schadow, sie wrote:
[...]
> I am just completely amazed about how many things there are that
> basically do very similar jobs, like packet filtering/classifying.
> While in general diversity is good, it is also a problem for the
> developers and users of the *
In some email I received from Julian Elischer, sie wrote:
[Charset iso-8859-2 unsupported, filtering to ASCII...]
> Darren Reed wrote:
> >
> > In some email I received from Gunther Schadow, sie wrote:
> > > Gunther Schadow wrote:
> > > [snip]
> > >
>
In some email I received from Gunther Schadow, sie wrote:
> Gunther Schadow wrote:
> [snip]
>
> to make things even more complicated, we also have the
> berkeley packet filter (BPF) mechanism. Heck! How could
> so many things evolve that all do essentially the same
> thing? The interesting
In some email I received from Gunther Schadow, sie wrote:
[...]
> As an added benefit, the two network interfaces tun0 and fxp0 allow
> me to cope with the limited power of IPFILTER's NAT rules (as compared
> to IPFW).
What is so limiting about NAT in IPFilter ?
AFAIK, apart from packet matchi
In some mail from Jason DiCioccio, sie said:
>
> From: "Darren Reed" <[EMAIL PROTECTED]>
> Subject: Re: non-random IP IDs
>
>
> > How long has your box been up ? How many changes to the system config
> > have been made since then ? If you&
In some mail from Alfred Perlstein, sie said:
>
> * Rodney W. Grimes <[EMAIL PROTECTED]> [010417 10:37] wrote:
> > > * Darren Reed <[EMAIL PROTECTED]> [010417 04:29] wrote:
> > > > In some mail from Julian Elischer, sie said:
> > > > >
&
In some mail from Julian Elischer, sie said:
>
> Darren Reed wrote:
> >
> > In some mail from Kris Kennaway, sie said:
> > >
> > >
> > > --rwEMma7ioTxnRzrJ
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Dispos
In some mail from Kris Kennaway, sie said:
>
>
> --TYecfFk8j8mZq+dy
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Tue, Apr 17, 2001 at 04:36:15AM +1000, Darren Reed wrote:
>
> > You should optimize it for mod being 2^n
In some mail from Kris Kennaway, sie said:
>
> Surely that can't work since the purpose of that field is for received
> packet ordering (unless I'm wrong, I'm not an IPv4 guru and only
> skimmed the RFC), and what's ordered in network order isn't ordered in
> host order.
It is not used by the re
In some mail from Kris Kennaway, sie said:
>
>
> --rwEMma7ioTxnRzrJ
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, Apr 16, 2001 at 02:03:11AM -0700, Kris Kennaway wrote:
>
> > Here's a patch ported from OpenB
In some mail from Wes Peters, sie said:
>
> Kris Kennaway wrote:
> >
> > On Thu, Apr 12, 2001 at 12:40:32AM -0500, Mike Silbersack wrote:
> >
> > > Each IP packet sent has with it a 16-bit ID. The numbers must remain
> > > unique over a short period of time so fragmentation can work properly.
53 matches
Mail list logo
