On 5/5/15 10:46 PM, Barney Cordoba wrote:
Are you NOT SHARP ENOUGH to understand that my proposal DOESN'T USE
THE NETWORK STACK? OMFG
Barney, your proposal is that we provide a framework to allow network
IP stack bypass in the case of special processing.
that framework still needs to be hooked
Are you NOT SHARP ENOUGH to understand that my proposal DOESN'T USE THE NETWORK
STACK? OMFG
Julien, perhaps if people weren't so hostile towards commercial companies
providing ideas for alternative ways of doing things you'd get more input and
more help. Why would I want to help these people?
BC
> On May 4, 2015, at 10:07 PM, Julian Elischer wrote:
>
> Jim, and Barney. I hate to sound like a broken record, but we really need
> interested people in the network stack.
> The people who make the decisions about this are the people who stand up and
> say "I have a few hours I can spend on
2015-05-04 17:29 skrev Barney Cordoba via freebsd-net:
It's not faster than "wedging" into the if_input()s. It simply can't
be. Your getting packets at interrupt time as soon as their processed
and you there's no network stack involved, and your able to receive
and transmit without a process s
> On May 4, 2015, at 11:53 AM, Barney Cordoba wrote:
>
> I'll assume you're just not that clear on specific implementation.
Thank you for your assumption. Have you noticed that you tend to argue by
insinuating that the other party is stupid, or at best, responsible for “hacks”?
> Hooking dir
I'll assume you're just not that clear on specific implementation. Hooking
directly into if_input() bypasses all of the "cruft". It basically uses the
driver "as-is", so any driver can be used and it will be as good as the driver.
The bloat starts in if_ethersubr.c, which is easily completely av
Nothing freely available. Many commercial companies have done such things. Why
limit the general community by force-feeding a really fast packet generator
into the mainstream by squashing other ideas in their infancy? Anyone who
understands how the kernel works understands what I'm saying. A pa
While it is a true statement that, "You can do anything in the kernel that you
can do in user space.”, it is not a helpful statement. Yes, the kernel is just
a program.
In a similar way, “You can just pop it into any kernel and it works.” is also
not helpful. It works, but it doesn’t work wel
On Mon, 4 May 2015 15:29:13 +, Barney Cordoba via freebsd-net wrote:
> It's not faster than "wedging" into the if_input()s. It simply can't
> be. Your getting packets at interrupt time as soon as their processed
> and you there's no network stack involved, and your able to receive
> an
It's not faster than "wedging" into the if_input()s. It simply can't be. Your
getting packets at interrupt time as soon as their processed and you there's
no network stack involved, and your able to receive and transmit without a
process switch. At worst it's the same, without the extra plumbin
On Sun, May 3, 2015 at 6:17 PM, Barney Cordoba via freebsd-net <
freebsd-net@freebsd.org> wrote:
> Frankly I'm baffled by netmap. You can easily write a loadable kernel
> module that moves packets from 1 interface to another and hook in the
> firewall; why would you want to bring them up into user
Frankly I'm baffled by netmap. You can easily write a loadable kernel module
that moves packets from 1 interface to another and hook in the firewall; why
would you want to bring them up into user space? It's 1000s of lines of
unnecessary code.
On Sunday, May 3, 2015 3:10 AM, Raimundo S
Clarifying things for the sake of documentation:
To use the host stack, append a ^ character after the name of the interface
you want to use. (Info from netmap(4) shipped with FreeBSD 10.1 RELEASE.)
Examples:
"kipfw em0" does nothing useful.
"kipfw netmap:em0" disconnects the NIC from the usual
On Mon, Nov 10, 2014 at 12:09 PM, Evandro Nunes
wrote:
> On Sun, Nov 9, 2014 at 9:23 PM, Luigi Rizzo wrote:
>
>>
>>
>> On Sun, Nov 9, 2014 at 1:17 PM, Evandro Nunes
>> wrote:
>>
>>> professor luigi
>>>
>>> where can I find the code for netmap-fwd you mentioned on usenix paper?
>>>
>>>
>> that
On Sun, Nov 9, 2014 at 9:23 PM, Luigi Rizzo wrote:
>
>
> On Sun, Nov 9, 2014 at 1:17 PM, Evandro Nunes
> wrote:
>
>> professor luigi
>>
>> where can I find the code for netmap-fwd you mentioned on usenix paper?
>>
>>
> that has been renamed to bridge.c
>
> cheers
> luigi
>
so it does not actua
On Sun, Nov 9, 2014 at 1:17 PM, Evandro Nunes
wrote:
> professor luigi
>
> where can I find the code for netmap-fwd you mentioned on usenix paper?
>
>
that has been renamed to bridge.c
cheers
luigi
>
> ** https://www.usenix.org/system/files/conference/atc12/atc12-final186.pdf
>
> On Sun, No
professor luigi
where can I find the code for netmap-fwd you mentioned on usenix paper?
** https://www.usenix.org/system/files/conference/atc12/atc12-final186.pdf
On Sun, Nov 9, 2014 at 5:31 PM, Evandro Nunes
wrote:
> hello again patrick
>
> On Sun, Nov 9, 2014 at 12:54 AM, Patrick Tracanelli
hello again patrick
On Sun, Nov 9, 2014 at 12:54 AM, Patrick Tracanelli <
eks...@freebsdbrasil.com.br> wrote:
> > (Machine-A)<-->Machine-B<--->(MachineC)
> >
> > Machine-A:
> > em0 172.16.251.3/24
> >
> > Machine-B:
> > em1: 172.16.251.1/24
> > em2: 172.16.252.1/24
> > 10.0-STABLE w/ latest netma
Dear Evandro Nunes,
You are just not reading. Ealy I mentioned the netmap:port syntax because your
previous syntax were turning out on errors opening the port that you just didnt
pay attention on ./kipfw's output.
Now you just didnt read what Mahanaz Tabeli wrote ;-) Please fo *read* below!!
:
On Sat, Nov 8, 2014 at 5:26 AM, Mahnaz Talebi wrote:
> Hi Evandro.
> I've tested netmap-ipfw on real NICs.
> Use "
>
> ./kipfw -i netmap:em0 -i netmap:em1
> " to run netmap-ipfw on em0 and em1. ipfw works as a bridge and copy
> incoming packets to em0 to em1 if they pass defined rules (and vice
Hi Evandro.
I've tested netmap-ipfw on real NICs.
Use "
./kipfw -i netmap:em0 -i netmap:em1
" to run netmap-ipfw on em0 and em1. ipfw works as a bridge and copy
incoming packets to em0 to em1 if they pass defined rules (and vice versa,
from em1 to em0).
If you still have problem with ipfw-netmap,
On Fri, Nov 7, 2014 at 4:08 PM, Luigi Rizzo wrote:
>
>
> On Fri, Nov 7, 2014 at 5:02 AM, Evandro Nunes
> wrote:
>
>> On Thu, Nov 6, 2014 at 9:24 PM, Luigi Rizzo wrote:
>>
>>> The code on code.google.com/p/netmap-ipfw/ works well for me
>>> on physical interfaces.
>>>
>>> For using the nics many
On Fri, Nov 7, 2014 at 5:02 AM, Evandro Nunes
wrote:
> On Thu, Nov 6, 2014 at 9:24 PM, Luigi Rizzo wrote:
>
>> The code on code.google.com/p/netmap-ipfw/ works well for me
>> on physical interfaces.
>>
>> For using the nics many of your examples show that you are not using the
>> various program
On Thu, Nov 6, 2014 at 9:24 PM, Luigi Rizzo wrote:
> The code on code.google.com/p/netmap-ipfw/ works well for me
> on physical interfaces.
>
> For using the nics many of your examples show that you are not using the
> various programs correctly. There is clearly a
> mismatch between what this co
The code on code.google.com/p/netmap-ipfw/ works well for me
on physical interfaces.
For using the nics many of your examples show that you are not using the
various programs correctly. There is clearly a
mismatch between what this code does and your expectations,
and there isn't much i can do to
On Wed, Nov 5, 2014 at 10:40 PM, Evandro Nunes
wrote:
> On Wed, Nov 5, 2014 at 8:44 PM, Patrick Tracanelli <
> eks...@freebsdbrasil.com.br> wrote:
>
>> Hey, what you are doing wrong is much more simple than you expect.
>>
>> > # ./kipfw em1 em2 > & /tmp/kipfw.log &
>> > [1] 66583
>>
>> Just run .
On Wed, Nov 5, 2014 at 8:44 PM, Patrick Tracanelli <
eks...@freebsdbrasil.com.br> wrote:
> Hey, what you are doing wrong is much more simple than you expect.
>
> > # ./kipfw em1 em2 > & /tmp/kipfw.log &
> > [1] 66583
>
> Just run ./kipfw netmap:em1 netmap:em2 and this will probably work.
>
> Pleas
Hey, what you are doing wrong is much more simple than you expect.
> # ./kipfw em1 em2 > & /tmp/kipfw.log &
> [1] 66583
Just run ./kipfw netmap:em1 netmap:em2 and this will probably work.
Please remember to redirect kipfw output to somewhere you are not reading only
*after* you are sure the out
dear luigi
sadly it still did not work, I have the scenario set, please see below:
On Tue, Nov 4, 2014 at 8:12 PM, Luigi Rizzo wrote:
> On Tue, Nov 04, 2014 at 05:44:43PM -0200, Evandro Nunes wrote:
> > On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote:
> ...
> > >> i gues I am missing a piece
On Tue, Nov 4, 2014 at 8:12 PM, Luigi Rizzo wrote:
> On Tue, Nov 04, 2014 at 05:44:43PM -0200, Evandro Nunes wrote:
> > On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote:
> ...
> > >> i gues I am missing a piece of the architecture...
> > >>
> > >
> > > ???probably yes :)
> > >
> > > kipfw em1 e
On Tue, Nov 04, 2014 at 05:44:43PM -0200, Evandro Nunes wrote:
> On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote:
...
> >> i gues I am missing a piece of the architecture...
> >>
> >
> > ???probably yes :)
> >
> > kipfw em1 em2 connects the two interfaces to each other, keeping the
> > rest ???
On Tue, Nov 4, 2014 at 5:52 PM, Michal Buchtík wrote:
> Dne 4.11.2014 20:44, Evandro Nunes napsal(a):
>
>> # ifconfig "em2" | grep flags
>> em2: flags=28d02
>> metric 0 mtu 1500
>>
> Hi,
> interface is OACTIVE and down.
>
> Do you try "ifconfig em2 up" ?
>
hey Michal,
strange, both NICs are ad
Dne 4.11.2014 20:44, Evandro Nunes napsal(a):
# ifconfig "em2" | grep flags
em2: flags=28d02
metric 0 mtu 1500
Hi,
interface is OACTIVE and down.
Do you try "ifconfig em2 up" ?
Michal
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org
On Tue, Nov 4, 2014 at 5:26 PM, Luigi Rizzo wrote:
>
>
> On Tue, Nov 4, 2014 at 11:09 AM, Evandro Nunes
> wrote:
>
>> so, running em1 and em2 only should work?
>>
>> because I have the same behavior:
>>
>> # ps wauxw | grep kipfw
>> root 61484 0.0 0.0 14648 1824 2 S 5:06PM
On Tue, Nov 4, 2014 at 11:09 AM, Evandro Nunes
wrote:
> so, running em1 and em2 only should work?
>
> because I have the same behavior:
>
> # ps wauxw | grep kipfw
> root 61484 0.0 0.0 14648 1824 2 S 5:06PM 0:02.95
> ./kipfw em1 em2
> root 61518 0.0 0.0 18804
so, running em1 and em2 only should work?
because I have the same behavior:
# ps wauxw | grep kipfw
root 61484 0.0 0.0 14648 1824 2 S 5:06PM 0:02.95
./kipfw em1 em2
root 61518 0.0 0.0 18804 1864 2 S+5:07PM 0:00.00
grep kipfw
# /usr/src/tools/too
the user space netmap-ipfw only supports two interfaces,
The hard problem in moving to 3+ interfaces is not much the code but
deciding where to send a packet once it has passed the filter.
Basically, passing things through the kernel stack is simple
but performance is going to be no better than
btw,
I am generating traffic via pkt-gen which I can see os received on the
other side:
# /usr/src/tools/tools/netmap/netmap-7e9e5e7602f5/examples/pkt-gen -i em1
-f tx -l 60 -d 172.16.250.10
643.417060 main [1649] interface is em1
643.417344 extract_ip_range [287] range is 10.0.0.1:0 to 10.0.0.1:
hello,
I am trying to do some basic stateless filtering with netmap-ipfw.
what i have running is:
./kipfw em1 em2 lo0
and when i do ipfw/ipfw show:
ipfw/ipfw show
connected to 127.0.0.1:
nalloc 2248 nbytes 136 ptr 0x0
00100 0 0 allow ip from any to any via lo0
65535 0 0 allow ip from any to
39 matches
Mail list logo
