On 1/31/12 12:53 AM, Ermal Luçi wrote:
On Mon, Jan 30, 2012 at 10:08 PM, Vadim Goncharov
<vadim_nucli...@mail.ru> wrote:
Hi Ermal Lu?i!
On Mon, 30 Jan 2012 13:01:13 +0100; Ermal Lu?i wrote about '[PATCH] multiple
instances of ipfw(4)':
from needs on pfSense a patch for allowing multiple intances of
ipfw(4) in kernel to co-exist was developed.
It can be found here
https://raw.github.com/bsdperimeter/pfsense-tools/master/patches/RELENG_9_0/CP_multi_instance_ipfw.diff
Hmm, looking at the lines
if (oif&& !(oif->if_flags& IFF_IPFW_FILTER))
return (IP_FW_PASS);
it appears that a patch is made against somewhat private, I couldn't find that
in stock FreeBSD.
Yeah its not so polished patch, and the remaining parts are still
there in the same repo.
Though its redundant to this patch.
It is used in conjuction with this tool
https://raw.github.com/bsdperimeter/pfsense-tools/master/pfPorts/ipfw_context/files/ipfw_context.c
It allows creation of contextes/instances and assignment of specific
interfaces to specific contexts/instances.
It is not clear how to add a rule to a specific instance with this program.
Simple example:
- Create a context with members
ipfw_context -a testctx
ipfw_context -a testctx -n myiface0
ipfw_context -a testctx -n myiface1
- Set the context
ipfw_context -s testctx
- Continue business as usual with ipfw/dummynet
ipfw add ....
ipfw pipe create ....
ipfw table add ....
Surely i know that this is not the best way to implement generically
but it gets the job done for us as it is, read below.
What i would like to know is if there is interest to see such
functionality in FreeBSD?
I am asking first to see if there is some consensus about this as a
feature, needed or not!
If interest is shown i will transform the patch to allow:
- ipfw(8) to manage the contextes create/destroy
- ipfw(8) to manage interface membership. Closing the race of two
parallell clients modifying different contextes.
There is another design choice to be made about storing the membership
of interfaces into contexts/instances, but i do not see that as
blocking.
It is quite handy feature, which can be exploited even to scale on SMP
machines by extending it to bind a specific instance(with its
interaces) to a specific CPU/core?!
Not so simple/straightforward questions. On the one hand, there are at least
/some/ people who need this. So the ipfw 'call'/'return' actions were already
implemented, first appearing in 9.0-R / 8.3-R. And melifaro@ has patches to
ipfw table allowing matching againt ifname, setting tablearg, which in
conjunction with 'call' or 'skipto' could be used to make essentially the same
functionality as your proposed patch, already in stock FreeBSD.
Well it tends to get messy if you do not have a smart consumer
handling the jumps.
Its almost as reprogramming in ipfw language and somehow an admin
needs to read this!
The intention was be practical and allow easy troubleshooting.
On the other hand, both ipfw contexts and ipfw 'call' are very half-measures.
The only goal was to give people something right now, and see how much this
will be demanded, what feedback they'll give, etc. It is obvious there is no
wide testing of 9.0-R (and 8.3-R too) right now.
It depends on the needs, surely and how colorful you want it to be.
What I mean here about half-measures? The ipfw 'call' is just a sketch of my
old ideas to completely reorganize ipfw to support multiple rulesets. To be
generic and Right Thing(tm), this is a HUGE work, because:
- each ipfw chain becomes independent netgraph(4) node
what about the existing netgraph ipfw node someone wrote a few years ago?
I saw it but don't know if it was sent out publicly.
- generic ng_pfil node usable not only for firewalls
- chains may be called from each other (see iptables)
- chains (actually netgraph nodes) may be bind to ifaces or any other place
- main unnamed chain is called from pfil as before
- rewrite ipfw& dummynet management from setsockopt() to netgraph messages
- completely rewrite ipfw dynamic rules to not conflict with multiple
rulesets, as now they just jump to parent static rule (need to be more like
pf or iptables states). This item is hard but essential (you'll get a mess
jumping to another ruleset), and ipfw contexts don't handle ot
- while here, do other needed things, e.g. adding support for modules in both
kernel and userland, loadable opcodes, keywords, etc.
if you write a ip/tcp/udp/... stack on netgraph than i will write this :)
Though its a matter of preference and how much work its needed to
accomplish this!
Surely ipfw has seen a lot of hacks in the past and will see in the
future but i thik usability is more of a target
rather than fancy design.
But surely nothing should stop both ways.
Even if not add something like bpf, that's ipfw_ng is probably a more major
change than both ipfw2 and ipfw3 :)
Due to various reasons in my private life, I was unable to do it in my spare
time previous years. My new employer is a provider using FreeBSD on most
machines, so I hope I could finally begin doing it at work (and for work),
but only several months later after more actual tasks.
But, all of this only makes sense to be generic for needs of broad masses of
our users. And in pfSense ipfw users are actually only it's authors (all
others see web interface), so it's better and more practical to not rely on
such complex solution, but rather on something more simple and specialized for
their needs. Such as your proposed ipfw contexts.
Surely enough you can take shortcuts in a customization but its not
the point here.
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nucli...@mail.ru
[Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
