Re: introduction

[Rene Schickbauer]

Hi, James!

> I'm working on the embedded FreeBSD project; I find embedded development to
> be difficult and extremely enjoyable. It covers a lot of bases, while also
> hearkening back to days when there were fewer resources available on any
> system, so that I feel like I'm working in an environment from the late
> seventies or early eighties. Which means I feel retro cool without actually
> being limited in resources in the real world.

Welcome! Just the project i need (having multiple Soekris-Boxes myself ;-)

I'm currently hacking around on my Soekris-Box to use the Error-Led for
displaying fault conditions (which is much more usefull than using it to
send more code). It's currently only a proof-of-concept at the moment, but
if it can aid your project, send me an email :-)

LLAP & LG
Rene

-- 
-- OmniCode 0.1.6 ---
sxy cm169 esO sp= Ag1976 anE hda ZoS Rl! Kd! MBINTJ UFGreg&Sid IN10 AdC&N
PrPerl(8)&C(7)&C++(7)&LUA(8)&PHP(8)&C#(4)&SQL(8)&BSLUA(9)
--- Omnicode http://www.gadgeteer.net/omnicode/ ---
-BEGIN GEEK CODE BLOCK-
Version: 3.1  Visit  to decode
GCS/CM d--(-) s:- a C++(+++)$> UBLAHC*+++()$>
P+++()$>+ L+(++)>$ !E---(-) W+++$ N+(++)@ o+(++)@
K? w+++(++)$>--- !O- M++>$ V-(--) PS+ PE Y+ PGP+ t+ 5 X-
R- tv-- b++(+++) DI-- D+ G++ e- h r? y+
--END GEEK CODE BLOCK--
Hackerkey: http://tinyurl.com/2qtnbq

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Introduction

[Yoshihiro Ota]

On Thu, 24 Apr 2008 19:46:02 -0400
David Forsythe <[EMAIL PROTECTED]> wrote:

> Hello everybody,
> 
> My name is David Forsythe and I'll be working on allowing parallel builds in 
> the
> ports collection for Summer of Code this year.  I'm a second year student at 
> the
> University of Maryland, College Park studying computer science.
> 
> I'm extremely excited to work on this project over the summer and I hope my 
> work
> is beneficial to the FreeBSD community.  I was already planning on devoting a
> bunch of my free time this summer to working on this type of thing, so an
> @freebsd.org alias, a t-shirt, and a bit of cash are just icing on the cake 
> (no
> seriously, getting a FreeBSD mail alias excited me so much I'm a little bit
> embarrassed...)
> 
> I hope that my project turns out well and I can continue to work with the 
> FreeBSD development
> community far into the future.  Working with you guys is really a dream come
> true!
> 
> 
> Dave

Welcome.

I have once implemented a tool to support parallel builds in the port system, 
indeed.
There were a couple of designs and I chose to write a wrapper program to the 
existing ports infrastructure such that the wrapper such that every build and 
run-time dependencies are built in parallel prior to target packages.  You can 
find more about it at http://uyota.asablo.jp/blog/cat/portsplus/

I would like to participate to the project as another adviser as it is also my 
interest.
I believe that I can provide good comments and feedback to this project from my 
experiences.

Thanks.
Hiro
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Introduction

[Wilko Bulte]

Quoting David Forsythe, who wrote on Thu, Apr 24, 2008 at 07:46:02PM -0400 ..
> Hello everybody,
> 
> My name is David Forsythe and I'll be working on allowing parallel builds in 
> the
> ports collection for Summer of Code this year.  I'm a second year student at 
> the
> University of Maryland, College Park studying computer science.
> 
> I'm extremely excited to work on this project over the summer and I hope my 
> work
> is beneficial to the FreeBSD community.  I was already planning on devoting a
> bunch of my free time this summer to working on this type of thing, so an
> @freebsd.org alias, a t-shirt, and a bit of cash are just icing on the cake 
> (no
> seriously, getting a FreeBSD mail alias excited me so much I'm a little bit
> embarrassed...)

Heh.. you will get used to that ;-)

-- 
Wilko Bulte [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Introduction

[Gary Jennejohn]

On Thu, 24 Apr 2008 19:46:02 -0400
David Forsythe <[EMAIL PROTECTED]> wrote:

> My name is David Forsythe and I'll be working on allowing parallel builds in 
> the
> ports collection for Summer of Code this year.
> 

This would definitely be of benefit!  Good luck.

---
Gary Jennejohn
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Introduction

[Martin Wilke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Apr 25, 2008 at 06:47:08AM +0900, Johannes Maximilian K wrote:
> Hello everyone,
> 
> I'm one of the GSoC students. My name is Johannes Maximilian Kuehn and
> my project is the reference implementation of the SNTP protocol.
> 
> I was exposed to FreeBSD about 6 years ago and I'm using it since
> then as my primary operating system. Similar to Anders I started with
> Linux and then got introduced to FreeBSD by a good friend. After that I
> found my favorite operating system and wanted to get involved with it,
> too. I think GSoC is a great opportunity to do that! :)
> 
> I'm a first year student studying computer science and Japanese Studies
> at the "Eberhard Karls Universität Tübingen" (Eberhard Karls university
> in Tuebingen, Germany).
> 
> I'm happy to be aboard!

Welcome and Good Luck!

> 
> 
> Max
> 
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 

- -- 

+---+---+
|  PGP: 0x05682353  |  Jabber : miwi(at)BSDCrew.de  |
|  ICQ: 169139903   |  Mail   : miwi(at)FreeBSD.org |
+---+---+
|   Mess with the Best, Die like the Rest!  |
+---+---+
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFIERc1FwpycAVoI1MRAgqXAKCOwX3ZtKOJBoanOHUDVUGwOLJ+qgCgikuw
uLcEt8acYvKCQUpJQ3kMyiQ=
=Vgbt
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Introduction

[rae l]

On Thu, Apr 24, 2008 at 3:30 PM, Anders Nore <[EMAIL PROTECTED]> wrote:
>
>  Hello everyone,
>
>  my name is Anders Nore, I'm in my second year studying Computer Science at
> the Norwegian University of Science and Technology. I've been selected to
> work on adding .db support to the pkg_* tools.
>
>  The first time I was introduced to FreeBSD was on an irc channel called
> #htmlhelp believe it or not, I were using Linux at the time and found out
> that I had chosen completely wrong and FreeBSD would become my weapon of
> choice. Becoming a FreeBSD developer has been dream for a long time, and
> just the FreeBSD mail alias is enough payment for me ;-)
great!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: introduction

[Garrett Cooper]

On Tue, Apr 22, 2008 at 6:55 PM, James <[EMAIL PROTECTED]> wrote:

> Hi folks,
>
> my name is James Harrison; I'm a computer science student at the
> University
> of New Mexico, studying mostly at the Los Alamos branch. I'm also a Unix
> systems administrator/developer at Los Alamos National Lab, where I've
> been
> working with embedded linux for a while.
>
> I've been working with FreeBSD for a few years now; a friend introduced me
> to it as a way to get a wireless card working that was stubbornly refusing
> to cooperate with any other operating system. After spending six months
> repeatedly breaking and ignoring the system by mixing packages and ports,
> I
> finally knuckled down and started learning how the system works.
>
> I'm working on the embedded FreeBSD project; I find embedded development
> to
> be difficult and extremely enjoyable. It covers a lot of bases, while also
> hearkening back to days when there were fewer resources available on any
> system, so that I feel like I'm working in an environment from the late
> seventies or early eighties. Which means I feel retro cool without
> actually
> being limited in resources in the real world.
>
> Best
> James


Congratulations James and welcome onboard :).
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfilter (was: RE: Introduction)

[Luigi Rizzo]

> > this might ease life to those who want to replace ipfw with ipfilter
> > for dummynet or similar things, if nothing else.
> 
> Thank you, Luigi. Could you please help me with some basics?
...

what i do in dummynet is to queue the packet (wheter it comes from
ip_input() or ip_output() makes no difference) in the appropriate data
structure for further processing, and return as if the firewall deleted
the packet.

Subsequently, when processing is done (in dummynet this means some time
has passed and we get a timer interrupt, in your case i suppose your
interrupt service routine would get called in this case), reinvoke the
appropriate routine (p_input() or ip_output()) with the packet
prepended with a header so that it can distinguish the processed packet
from a new one and act differently.

> If would be nice to have another hook point in a proper place _after_
> the re-assembly stage of ip_input(). It would not cause much overhead
> if nobody has a hook installed.

i did not have this problem with dummynet -- if you need the reassembly
first, then probably you have to hook in ip_input() after the
reassembly is done, ie between IP and the upper layer i guess.

cheers
luigi
---+-
  Luigi RIZZO, lu...@iet.unipi.it  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)

  http://www.iet.unipi.it/~luigi/ngc99/
  First International Workshop on Networked Group Communication  
---+-


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

RE: ipfilter (was: RE: Introduction)

[Constantine Shkolny]

On Sunday, June 20, 1999 7:22 AM, Luigi Rizzo 
[SMTP:lu...@labinfo.iet.unipi.it] wrote:
> > This means that IP filters need to grab some of IP packets, process
> > them on a specialized prosessor and then re-inject them into the IP
> > packet stream. That is, the filter may decide to convert the packet,
> > but it doesn't have it ready-to-go when it has to return. However,
> > it may have it ready at some later time, possibly when it processes
> > a hardware interrupt and sees that the co-processor has finished its
> > work on the packet. Can ipfilter handle this?
>
> no idea about ipfilter, but i guess not -- in the case of ipfw i
> did have to implement exactly this funcionality for dummynet and i
> ended up putting it _outside_ dummynet (i.e. in the callers routines,
> ip_input(), ip_output() and bdg_forward() ) .
>
> this might ease life to those who want to replace ipfw with ipfilter
> for dummynet or similar things, if nothing else.

Thank you, Luigi. Could you please help me with some basics?

Our IPSec product intercepts outbound IP packets and usually changes
them in the way that makes them bigger. It performs the reverse
operation on the inbound packet stream. I'm not quite aware of exact
packet transformations, since my part of this port is to "hook" into
the IP packet streams and provide the base for the main package.

My first intention yesterday was to take the place of ipfilter, since
IP protocol code seemingly had necessary hooks in place. I was thinking
that, in ip_output(), I could just tsleep() in my filter, waiting for
the co-processor to encode the packet and then wakeup() from the
co-processor's ISR. (Am I right in thinking that ip_output() is always
invoked during the system call and thus can sleep?)

For inbound packets, tsleep() in ip_input() is not possible, so I was
hoping to eat packets by placing then into an internal queue and then,
in the co-processor's ISR, push them back to the IP input queue and
to schedule network interrupt for IP (like net interface drivers do).
(I was not quite sure whether the above idea was feasible, I would
have to investigate this.)

But the problem that stopped me is that, while ip_output() first
invokes the ipfilter and then fragments the packet (which is good
for me), ip_input() first invokes ipfilter and only then re-assembles
the packet. At the first glance it looked weird but I soon realized
that ipfilter is probably only interested in packet headers and
the placing hook point there can improve performance by filtering out
some packets prior re-assembly. However, this design defeats my idea
(if I don't want to re-assemble them by myself, of course).

If would be nice to have another hook point in a proper place _after_
the re-assembly stage of ip_input(). It would not cause much overhead
if nobody has a hook installed.

Please, if you've reached this place, tell me where I'm wrong.
We already have our IPSec product fully functional in NT and we
would love to port it to FreeBSD, however, despite the simplicity
of our needs, I currently don't see a clear way of plugging it into
any layer of the network stack. Between IP and network inferfaces,
as it is done in NT? Our product does handle fragmentation and
re-assembly. But the network interface drivers push packets directly
into the IP queue, I'd have to modify the ether_input() and friends
and probably meet some other unexpected implications.

Adding the additional hook point seems to be the ideal solution for
me. It would result in minimal efforts and minimal code size, and
it is clearly much cleaner then any other place. The IP protocol
driver is the ideal place for IP packet filters, after all.

Since I'm new to Unix, I'm not sure if this is Ok to put this couple
of operators directly to ip_input and tell our customers to do so
before installing our product. What is the best way? Please, forgive
me if I wrote some stupid things in this letter.

Thank you,
Stan



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: ipfilter (was: RE: Introduction)

[Luigi Rizzo]

> This means that IP filters need to grab some of IP packets, process
> them on a specialized prosessor and then re-inject them into the IP
> packet stream. That is, the filter may decide to convert the packet,
> but it doesn't have it ready-to-go when it has to return. However,
> it may have it ready at some later time, possibly when it processes
> a hardware interrupt and sees that the co-processor has finished its
> work on the packet. Can ipfilter handle this?

no idea about ipfilter, but i guess not -- in the case of ipfw i
did have to implement exactly this funcionality for dummynet and i
ended up putting it _outside_ dummynet (i.e. in the callers routines,
ip_input(), ip_output() and bdg_forward() ) .

this might ease life to those who want to replace ipfw with ipfilter
for dummynet or similar things, if nothing else.

cheers
luigi
---+-
  Luigi RIZZO, lu...@iet.unipi.it  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)

  http://www.iet.unipi.it/~luigi/ngc99/
  First International Workshop on Networked Group Communication  
---+-


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Firewalls (was Re: Introduction)

[Brian F. Feldman]

On Sat, 19 Jun 1999, Julian Elischer wrote:

> As a contributor to ipfw, notice that I will be sticking my oar into the
> water when it comes to deleting it unless I'm very sure that the ipf stuff
> is better. Unless you're Danish you don't just get to delete bits of the
> tree without a lot of agreement, especially from those who are working on
> it.. (in this case luigi and I would both be extrememly interested).

Deleting IPFW would be a _long_ time from now, if at all. What it looks
like now is:

1. making ipf and ipfw equivalent in functionality
2. cleaning up both
3. MAYBE starting a brand new firewall project

I wasn't planning on trying to rip something out from under anyone :)

> 
> 
> On Sat, 19 Jun 1999, Brian F. Feldman wrote:
> 
> > On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> > 
> > > "Brian F. Feldman"  writes:
> > > > It might be worth (discussion of) making ipfilter the firewall of
> > > > choice for 4.0. There would of course be rule conversion
> > > > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > > > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > > > support (currently options IPFILTER_LKM) made a non-option. It seems
> > > > that our pretty proprietary ipfw is no longer a good idea.
> > > 
> > > If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> > > and you even manage to keep an ipfw(8) command around so those who
> > > want kan keep using the old syntax still can, then I for one have no
> > > objections.
> > > 
> > > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > > simple Perl script should be sufficient.
> > 
> > Not quite as trivial as you think. ipfw and ipf are completely backwards 
> > when it comes
> > to rule order: in ipfw, the first rule matched takes effect; in ipf, the 
> > last rule matched
> > takes effect. Plus, ipf doesn't have rule numbers (but there's similar 
> > functionailty.)
> > If you think you can get used to them both enough to tackle this, I'll 
> > handle other
> > things, and we can have a working replacement for crufty old ipfw. Note 
> > that Luigi's
> > extra ipfw functionality and my extra ipfw functionality _will_ be wanted 
> > in ipf
> > before everyone is necessarily willing to switch. I have a feeling there 
> > will be some
> > holdouts that, even if ipfw is removed, they'll MFS (merge from stable) 
> > ipfw back just
> > because they want to keep the old way. Ipfw could be dead for 4.0-RELEASE, 
> > as I see it
> > now. More discussion is, however, necessary.
> > 
> > > 
> > > DES
> > > -- 
> > > Dag-Erling Smorgrav - d...@flood.ping.uio.no
> > > 
> > 
> >  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
> >  gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
> >  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
> >http://www.FreeBSD.org/  _ |___/___/___/ 
> > 
> > 
> > 
> > To Unsubscribe: send mail to majord...@freebsd.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> > 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Brian F. Feldman]

It has "fwd stuff" :)

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Firewalls (was Re: Introduction)

[Jordan K. Hubbard]

> is better. Unless you're Danish you don't just get to delete bits of the

s/Unless/Especially if/ :-)

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Firewalls (was Re: Introduction)

[Julian Elischer]

As a contributor to ipfw, notice that I will be sticking my oar into the
water when it comes to deleting it unless I'm very sure that the ipf stuff
is better. Unless you're Danish you don't just get to delete bits of the
tree without a lot of agreement, especially from those who are working on
it.. (in this case luigi and I would both be extrememly interested).


On Sat, 19 Jun 1999, Brian F. Feldman wrote:

> On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> 
> > "Brian F. Feldman"  writes:
> > > It might be worth (discussion of) making ipfilter the firewall of
> > > choice for 4.0. There would of course be rule conversion
> > > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > > support (currently options IPFILTER_LKM) made a non-option. It seems
> > > that our pretty proprietary ipfw is no longer a good idea.
> > 
> > If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> > and you even manage to keep an ipfw(8) command around so those who
> > want kan keep using the old syntax still can, then I for one have no
> > objections.
> > 
> > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > simple Perl script should be sufficient.
> 
> Not quite as trivial as you think. ipfw and ipf are completely backwards when 
> it comes
> to rule order: in ipfw, the first rule matched takes effect; in ipf, the last 
> rule matched
> takes effect. Plus, ipf doesn't have rule numbers (but there's similar 
> functionailty.)
> If you think you can get used to them both enough to tackle this, I'll handle 
> other
> things, and we can have a working replacement for crufty old ipfw. Note that 
> Luigi's
> extra ipfw functionality and my extra ipfw functionality _will_ be wanted in 
> ipf
> before everyone is necessarily willing to switch. I have a feeling there will 
> be some
> holdouts that, even if ipfw is removed, they'll MFS (merge from stable) ipfw 
> back just
> because they want to keep the old way. Ipfw could be dead for 4.0-RELEASE, as 
> I see it
> now. More discussion is, however, necessary.
> 
> > 
> > DES
> > -- 
> > Dag-Erling Smorgrav - d...@flood.ping.uio.no
> > 
> 
>  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
>  gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
>  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
>http://www.FreeBSD.org/  _ |___/___/___/ 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Julian Elischer]

On Sat, 19 Jun 1999, Brian F. Feldman wrote:

> On Sat, 19 Jun 1999, Doug Rabson wrote:
> 
> > On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> > 
> > > "Brian F. Feldman"  writes:
> > > > It might be worth (discussion of) making ipfilter the firewall of
> > > > choice for 4.0. There would of course be rule conversion
> > > > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > > > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > > > support (currently options IPFILTER_LKM) made a non-option. It seems
> > > > that our pretty proprietary ipfw is no longer a good idea.
> > > 
> > > If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> > > and you even manage to keep an ipfw(8) command around so those who
> > > want kan keep using the old syntax still can, then I for one have no
> > > objections.
> > > 
> > > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > > simple Perl script should be sufficient.
> > 
> > Does ipfilter support divert sockets?
> 
> It still needs:
>   divert sockets
>   Luigi's stuff (dummynet and bridging)
>   my stuff

fwd stuff?

> 
> > 
> > --
> > Doug Rabson Mail:  d...@nlsystems.com
> > Nonlinear Systems Ltd.  Phone: +44 181 442 9037
> > 
> > 
> > 
> 
>  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
>  gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
>  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
>http://www.FreeBSD.org/  _ |___/___/___/ 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: firewalling (Was Re: Introduction)

[Julian Elischer]

We use IPFW to great effect in the interjet

whatever we end up with had better have the same features or we can't use
it..

1/ simple to use programatic API
2/ Divert sockets are a MUST. We do a lot of our filtering in userland.
3/ The ability to branch the rules using 'skipto' (goto?) is used heavily
and the goto optimisations are very important to our performance.
4/ The 'fwd' facility is also very important.
5/ Line numbers are crucial to the way we control rules in the product.
6/ the ability to log but not halt processing of a packet is also crucial.
If you change the semantics of how rules interact, you could screw us.

Maybe you should look at what BSDI have..


A bpf based filter for link layer, and a separate IP layer filter..


Also look at the DPF code from MIT (in the exokernel).
If we are going to do a replacement we shouldn't junk ipfw for something 
of equivalent technology (ipf), but consider doing something like DPF
which is truely revolutionary. DPF generates att addition time,
Dynamically generated machine instructions for an optimal packet
classifier. When you add a rule, it re-writes the machine code..
there are ports for several architectures and it's very portable.
Making a tree of indivdually created DPF filters would lead to incredibly
high processing rates of very complicated rules.

If you are not going to go the whole hog, then better to leave things the
way they are (but with some cleaning). Security mechanisms are not the
things you want to futz with too much. WHile I agree that ipf
is "standard in NetBSD and OpenBSD, ipfw is closer to the Linux ipfw
and as such, it would be a better maketting plan to ether leave it as is
or move more towards what they do or leave it much as it is.. the others
are pretty irrelevant when it comes to market  and especially when
it comes to our share of it. After 23 years in this industry I've learned 
(it took a long time) that a working but not perfect feature is better
than a perfect one if the perfect one has marketting drawbacks.

The present system is real easy to understand and many people use it.
Think REAL HARD before removing it.
IPF can already beadded by those that want it.
Don't screw over the project in your eagerness to do good.

Having said that I know IPFW's weaknesses. Most of it comes from 
the fact that we are working "out of the correct layer" sometimes.
I'd LOVE to see a good DPF implementation

julian



On Fri, 18 Jun 1999, Brian Fundakowski Feldman wrote:

> On Sat, 19 Jun 1999, Darren Reed wrote:
> 
> > In some email I received from Brian Fundakowski Feldman, sie wrote:
> > > How do you feel about (after getting it fixed in -CURRENT) helping with
> > > converting ipfw(8) to just a front-end to ipf? I think it's worth 
> > > discussing
> > > whether it's actually worth it to rewrite IPFW or just work on improving
> > > ipfilter. (discussion moved to -hackers)
> > 
> > I imagine they might be fighting words to some ;)  As I see it, if you
> > added hooks for divert to ipfilter in FreeBSD and maybe added the rule
> > number bits (I *know* there are going to be people who'd just die without
> > it) then I can't see why you'd need ipfw.  I imagine that would be a hell
> > of a lot less work than bringing the features of ipfilter into ipfw.
> > 
> > It'd also be one of those steps forward in compatibility between the various
> > BSDs...
> 
>   Yes, and I know it might take some work. I'd like to have something good be
> the default in FreeBSD, and I feel that maybe if ipfilter can be brought
> to the foreground well and made backward compatible (i.e. ipfw(8) to translate
> (perl? /bin/sh? idunno)), it will be a winning thing. I'd of course like to
> add UID/GID support to ipfilter like I did to IPFW (but didn't commit).
>   IPFW is nearing the end of its maintainable life. It needs a pretty large
> rewrite or full replacement pretty soon. If we can get ipfilter in src/contrib
> kept up-to-date and working, supplying a replacement for ipfw(8) as a 
> front-end,
> I don't see why ipfilter can't be the "FreeBSD firewall."
> 
> 
> > 
> > Darren
> > 
> > 
> > To Unsubscribe: send mail to majord...@freebsd.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> > 
> 
>  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
>  gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
>  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
>http://www.FreeBSD.org/  _ |___/___/___/ 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Firewalls (was Re: Introduction)

[Jason Thorpe]

On 19 Jun 1999 17:30:13 +0200 
 Dag-Erling Smorgrav  wrote:

 > Divert sockets, dummynet and credential-based filtering would be
 > sorely missed if they weren't ported to ipfilter.

...but if they were ported to IP Filter, then lots of other systems could
use them, too.

-- Jason R. Thorpe 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Firewalls (was Re: Introduction)

[Brian F. Feldman]

On 19 Jun 1999, Dag-Erling Smorgrav wrote:

> "Brian F. Feldman"  writes:
> > On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> > > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > > simple Perl script should be sufficient.
> > Not quite as trivial as you think. ipfw and ipf are completely backwards 
> > when it comes
> > to rule order: in ipfw, the first rule matched takes effect; in ipf, the 
> > last rule matched
> > takes effect.
> 
> Just throw in 'quick' and ipfilter behaves just like ipfw.

I figured that out. Come to think of it, I rather like "quick" much better
than ipf's default way.

> 
> >Note 
> > that Luigi's
> > extra ipfw functionality and my extra ipfw functionality _will_ be wanted 
> > in ipf
> > before everyone is necessarily willing to switch.
> 
> Divert sockets, dummynet and credential-based filtering would be
> sorely missed if they weren't ported to ipfilter.

Definitely. Working on ipfilter is probably better than reinventing the wheel
again.

> 
> DES
> -- 
> Dag-Erling Smorgrav - d...@flood.ping.uio.no
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Firewalls (was Re: Introduction)

[Dag-Erling Smorgrav]

"Brian F. Feldman"  writes:
> On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > simple Perl script should be sufficient.
> Not quite as trivial as you think. ipfw and ipf are completely backwards when 
> it comes
> to rule order: in ipfw, the first rule matched takes effect; in ipf, the last 
> rule matched
> takes effect.

Just throw in 'quick' and ipfilter behaves just like ipfw.

>Note that 
> Luigi's
> extra ipfw functionality and my extra ipfw functionality _will_ be wanted in 
> ipf
> before everyone is necessarily willing to switch.

Divert sockets, dummynet and credential-based filtering would be
sorely missed if they weren't ported to ipfilter.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Brian F. Feldman]

On Sat, 19 Jun 1999, Doug Rabson wrote:

> On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> 
> > "Brian F. Feldman"  writes:
> > > It might be worth (discussion of) making ipfilter the firewall of
> > > choice for 4.0. There would of course be rule conversion
> > > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > > support (currently options IPFILTER_LKM) made a non-option. It seems
> > > that our pretty proprietary ipfw is no longer a good idea.
> > 
> > If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> > and you even manage to keep an ipfw(8) command around so those who
> > want kan keep using the old syntax still can, then I for one have no
> > objections.
> > 
> > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > simple Perl script should be sufficient.
> 
> Does ipfilter support divert sockets?

It still needs:
divert sockets
Luigi's stuff (dummynet and bridging)
my stuff

> 
> --
> Doug Rabson   Mail:  d...@nlsystems.com
> Nonlinear Systems Ltd.Phone: +44 181 442 9037
> 
> 
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Firewalls (was Re: Introduction)

[Ian West]

On Sat, Jun 19, 1999 at 11:12:07AM -0400, Brian F. Feldman wrote:
> On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> 
> > "Brian F. Feldman"  writes:
> > > It might be worth (discussion of) making ipfilter the firewall of
> > > choice for 4.0. There would of course be rule conversion
> > > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > > support (currently options IPFILTER_LKM) made a non-option. It seems
> > > that our pretty proprietary ipfw is no longer a good idea.
> > 
> > If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> > and you even manage to keep an ipfw(8) command around so those who
> > want kan keep using the old syntax still can, then I for one have no
> > objections.
> > 
> > Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> > simple Perl script should be sufficient.
> 
> Not quite as trivial as you think. ipfw and ipf are completely backwards when 
> it comes
> to rule order: in ipfw, the first rule matched takes effect; in ipf, the last 
> rule matched
> takes effect. Plus, ipf doesn't have rule numbers (but there's similar 
> functionailty.)
> If you think you can get used to them both enough to tackle this, I'll handle 
> other
> things, and we can have a working replacement for crufty old ipfw. Note that 
> Luigi's
> extra ipfw functionality and my extra ipfw functionality _will_ be wanted in 
> ipf
> before everyone is necessarily willing to switch. I have a feeling there will 
> be some
> holdouts that, even if ipfw is removed, they'll MFS (merge from stable) ipfw 
> back just
> because they want to keep the old way. Ipfw could be dead for 4.0-RELEASE, as 
> I see it
> now. More discussion is, however, necessary.
> 
> > 
> > DES
> > -- 
> > Dag-Erling Smorgrav - d...@flood.ping.uio.no
> > 
> 
>  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
>  gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
>  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
>http://www.FreeBSD.org/  _ |___/___/___/ 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message

Does ip filter now support per interface filtering based on an ip
address, not an interface name ? This was the limitation I encountered
last time I looked at it. Ran up against a few problems getting it to
run nicely with user-ppp. (Can't remember how long ago that was exactly
though, it may be fixed now, if so please ignore this :-)


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

ipfilter (was: RE: Introduction)

[Constantine Shkolny]

Hi All,

I'm now analyzing ipfilter in 3.2 and our goal is to port our
IPSec/firewall. I'm still in the beginning of reading the code
so, at this time, I can't yet tell how nice it fits our needs.
I just have some concerns which I'd like the people who are
going to re-design the ipfilter to hear. I wouldn't be surprised
to learn that you are already thinking about this, however, it's
nice to know it for certain :-)

The things in the IPSec field are seemingly moving to using
hardware accelerators for doing compression/encryption/authentication.
This means that IP filters need to grab some of IP packets, process
them on a specialized prosessor and then re-inject them into the IP
packet stream. That is, the filter may decide to convert the packet,
but it doesn't have it ready-to-go when it has to return. However,
it may have it ready at some later time, possibly when it processes
a hardware interrupt and sees that the co-processor has finished its
work on the packet. Can ipfilter handle this?

Thank you,
Stan



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Firewalls (was Re: Introduction)

[Brian F. Feldman]

On 19 Jun 1999, Dag-Erling Smorgrav wrote:

> "Brian F. Feldman"  writes:
> > It might be worth (discussion of) making ipfilter the firewall of
> > choice for 4.0. There would of course be rule conversion
> > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > support (currently options IPFILTER_LKM) made a non-option. It seems
> > that our pretty proprietary ipfw is no longer a good idea.
> 
> If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> and you even manage to keep an ipfw(8) command around so those who
> want kan keep using the old syntax still can, then I for one have no
> objections.
> 
> Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> simple Perl script should be sufficient.

Not quite as trivial as you think. ipfw and ipf are completely backwards when 
it comes
to rule order: in ipfw, the first rule matched takes effect; in ipf, the last 
rule matched
takes effect. Plus, ipf doesn't have rule numbers (but there's similar 
functionailty.)
If you think you can get used to them both enough to tackle this, I'll handle 
other
things, and we can have a working replacement for crufty old ipfw. Note that 
Luigi's
extra ipfw functionality and my extra ipfw functionality _will_ be wanted in ipf
before everyone is necessarily willing to switch. I have a feeling there will 
be some
holdouts that, even if ipfw is removed, they'll MFS (merge from stable) ipfw 
back just
because they want to keep the old way. Ipfw could be dead for 4.0-RELEASE, as I 
see it
now. More discussion is, however, necessary.

> 
> DES
> -- 
> Dag-Erling Smorgrav - d...@flood.ping.uio.no
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Doug Rabson]

On 19 Jun 1999, Dag-Erling Smorgrav wrote:

> "Brian F. Feldman"  writes:
> > It might be worth (discussion of) making ipfilter the firewall of
> > choice for 4.0. There would of course be rule conversion
> > scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> > a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> > support (currently options IPFILTER_LKM) made a non-option. It seems
> > that our pretty proprietary ipfw is no longer a good idea.
> 
> If ipfilter can to everything ipfw can (judging from ipf(5), it can)
> and you even manage to keep an ipfw(8) command around so those who
> want kan keep using the old syntax still can, then I for one have no
> objections.
> 
> Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
> simple Perl script should be sufficient.

Does ipfilter support divert sockets?

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Dag-Erling Smorgrav]

"Brian F. Feldman"  writes:
> It might be worth (discussion of) making ipfilter the firewall of
> choice for 4.0. There would of course be rule conversion
> scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to
> a KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> support (currently options IPFILTER_LKM) made a non-option. It seems
> that our pretty proprietary ipfw is no longer a good idea.

If ipfilter can to everything ipfw can (judging from ipf(5), it can)
and you even manage to keep an ipfw(8) command around so those who
want kan keep using the old syntax still can, then I for one have no
objections.

Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a
simple Perl script should be sufficient.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Doug Rabson]

On Sat, 19 Jun 1999, Brian F. Feldman wrote:

> On Sat, 19 Jun 1999, Doug Rabson wrote:
> 
> > On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> > 
> > > Ruslan Ermilov  writes:
> > > > * Clean the existing code (both userland and kernel) (10-20% done)
> > > > * Re-design the ipfw's API
> > > > * Port the existing functionality to the new API
> > > > * Proceed with new features
> > > 
> > > Pretty please with sugar on top, design an API that can be extended
> > > without breaking binary compatibility. We've had too much of that for
> > > no good reason (at least once between 2.2.7 and 2.2.8, and once
> > > between 3.1 and 3.2).
> > 
> > As far as possible, all new apis in the kernel should be designed with a
> > stable ABI. Its pretty simple if you follow a few simple rules:
> > 
> > 1. Hide implementation data structures. Access all information
> >outside the core implementation using function calls.
> > 2. Try to avoid using complex structures in the api. Each
> >structure in an api defines part of its ABI. Changing that
> >structure later breaks the ABI.
> > 3. Keep the external api as simple as possible. As a rule of
> >thumb, try to write manpages for each function. If you can't
> >describe the function accurately and concisely in a manpage
> >then its too complex.
> > 
> 
> It might be worth (discussion of) making ipfilter the firewall of
> choice for 4.0. There would of course be rule conversion
> scripts/programs (ipfw->ipf(5)), and ipfilter would be converted to a
> KLD, cruft removed (I'm going to work on these), and ipfilter KLD
> support (currently options IPFILTER_LKM) made a non-option. It seems
> that our pretty proprietary ipfw is no longer a good idea.
>And if Luigi ported all of his stuff to ipfilter from ipfw, and I
> did per-[ug]id support for ipfilter (which I will), we'll definitely
> be ahead. Ipfilter is a win for compatibilty/ubiquity, and seems to be
> faster than ipfw anyway. Are there any technical arguments against
> ipfilter or for ipfw? Note that: political arguments do not count, a
> conversion method will be available for ipfw users, and we should have
> anything special (DummyNet, uid/gid-based filtering) ported over to
> ipfilter.

I don't have a position on ipfw vs. ipfilter. As long as no functionality
is lost, I don't see any problems changing.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Brian F. Feldman]

On Sat, 19 Jun 1999, Doug Rabson wrote:

> On 19 Jun 1999, Dag-Erling Smorgrav wrote:
> 
> > Ruslan Ermilov  writes:
> > > * Clean the existing code (both userland and kernel) (10-20% done)
> > > * Re-design the ipfw's API
> > > * Port the existing functionality to the new API
> > > * Proceed with new features
> > 
> > Pretty please with sugar on top, design an API that can be extended
> > without breaking binary compatibility. We've had too much of that for
> > no good reason (at least once between 2.2.7 and 2.2.8, and once
> > between 3.1 and 3.2).
> 
> As far as possible, all new apis in the kernel should be designed with a
> stable ABI. Its pretty simple if you follow a few simple rules:
> 
>   1. Hide implementation data structures. Access all information
>  outside the core implementation using function calls.
>   2. Try to avoid using complex structures in the api. Each
>  structure in an api defines part of its ABI. Changing that
>  structure later breaks the ABI.
>   3. Keep the external api as simple as possible. As a rule of
>  thumb, try to write manpages for each function. If you can't
>  describe the function accurately and concisely in a manpage
>  then its too complex.
> 

It might be worth (discussion of) making ipfilter the firewall of choice for 
4.0.
There would of course be rule conversion scripts/programs (ipfw->ipf(5)), and
ipfilter would be converted to a KLD, cruft removed (I'm going to work on 
these), and
ipfilter KLD support (currently options IPFILTER_LKM) made a non-option. It 
seems
that our pretty proprietary ipfw is no longer a good idea.
   And if Luigi ported all of his stuff to ipfilter from ipfw, and I did 
per-[ug]id
support for ipfilter (which I will), we'll definitely be ahead. Ipfilter is a 
win for
compatibilty/ubiquity, and seems to be faster than ipfw anyway. Are there any 
technical
arguments against ipfilter or for ipfw? Note that: political arguments do not 
count,
a conversion method will be available for ipfw users, and we should have 
anything special
(DummyNet, uid/gid-based filtering) ported over to ipfilter.

> --
> Doug Rabson   Mail:  d...@nlsystems.com
> Nonlinear Systems Ltd.Phone: +44 181 442 9037
> 
> 
> 
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Doug Rabson]

On 19 Jun 1999, Dag-Erling Smorgrav wrote:

> Ruslan Ermilov  writes:
> > * Clean the existing code (both userland and kernel) (10-20% done)
> > * Re-design the ipfw's API
> > * Port the existing functionality to the new API
> > * Proceed with new features
> 
> Pretty please with sugar on top, design an API that can be extended
> without breaking binary compatibility. We've had too much of that for
> no good reason (at least once between 2.2.7 and 2.2.8, and once
> between 3.1 and 3.2).

As far as possible, all new apis in the kernel should be designed with a
stable ABI. Its pretty simple if you follow a few simple rules:

1. Hide implementation data structures. Access all information
   outside the core implementation using function calls.
2. Try to avoid using complex structures in the api. Each
   structure in an api defines part of its ABI. Changing that
   structure later breaks the ABI.
3. Keep the external api as simple as possible. As a rule of
   thumb, try to write manpages for each function. If you can't
   describe the function accurately and concisely in a manpage
   then its too complex.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Dag-Erling Smorgrav]

Ruslan Ermilov  writes:
> * Clean the existing code (both userland and kernel) (10-20% done)
> * Re-design the ipfw's API
> * Port the existing functionality to the new API
> * Proceed with new features

Pretty please with sugar on top, design an API that can be extended
without breaking binary compatibility. We've had too much of that for
no good reason (at least once between 2.2.7 and 2.2.8, and once
between 3.1 and 3.2).

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: firewalling (Was Re: Introduction)

[Brian Fundakowski Feldman]

On Sat, 19 Jun 1999, Darren Reed wrote:

> In some email I received from Brian Fundakowski Feldman, sie wrote:
> > How do you feel about (after getting it fixed in -CURRENT) helping with
> > converting ipfw(8) to just a front-end to ipf? I think it's worth discussing
> > whether it's actually worth it to rewrite IPFW or just work on improving
> > ipfilter. (discussion moved to -hackers)
> 
> I imagine they might be fighting words to some ;)  As I see it, if you
> added hooks for divert to ipfilter in FreeBSD and maybe added the rule
> number bits (I *know* there are going to be people who'd just die without
> it) then I can't see why you'd need ipfw.  I imagine that would be a hell
> of a lot less work than bringing the features of ipfilter into ipfw.
> 
> It'd also be one of those steps forward in compatibility between the various
> BSDs...

  Yes, and I know it might take some work. I'd like to have something good be
the default in FreeBSD, and I feel that maybe if ipfilter can be brought
to the foreground well and made backward compatible (i.e. ipfw(8) to translate
(perl? /bin/sh? idunno)), it will be a winning thing. I'd of course like to
add UID/GID support to ipfilter like I did to IPFW (but didn't commit).
  IPFW is nearing the end of its maintainable life. It needs a pretty large
rewrite or full replacement pretty soon. If we can get ipfilter in src/contrib
kept up-to-date and working, supplying a replacement for ipfw(8) as a front-end,
I don't see why ipfilter can't be the "FreeBSD firewall."


> 
> Darren
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: firewalling (Was Re: Introduction)

[Darren Reed]

In some email I received from Brian Fundakowski Feldman, sie wrote:
> How do you feel about (after getting it fixed in -CURRENT) helping with
> converting ipfw(8) to just a front-end to ipf? I think it's worth discussing
> whether it's actually worth it to rewrite IPFW or just work on improving
> ipfilter. (discussion moved to -hackers)

I imagine they might be fighting words to some ;)  As I see it, if you
added hooks for divert to ipfilter in FreeBSD and maybe added the rule
number bits (I *know* there are going to be people who'd just die without
it) then I can't see why you'd need ipfw.  I imagine that would be a hell
of a lot less work than bringing the features of ipfilter into ipfw.

It'd also be one of those steps forward in compatibility between the various
BSDs...

Darren


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

firewalling (Was Re: Introduction)

[Brian Fundakowski Feldman]

How do you feel about (after getting it fixed in -CURRENT) helping with
converting ipfw(8) to just a front-end to ipf? I think it's worth discussing
whether it's actually worth it to rewrite IPFW or just work on improving
ipfilter. (discussion moved to -hackers)

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Ugen Antsilevitch]

 Ok...i guess i would be the wrong person for cleaning the code since i
kinda
responsible for the damn thing being a mess in the first place. I can
try:)
 I however have some ideas on how to make a better API (as in more hooks
to
userland, which btw now after i have read an "FTP requests comment, migh

even make more sence).
One thing though - if we (you :) will really work on this - can we set
up some
tiny mailing list for IPFW ? Should we? (Or tell me if i have everyone
who was
interested on this e-mail "To" list and forget this request:)
--Ugen

Ruslan Ermilov wrote:

> On Thu, Jun 17, 1999 at 02:34:55PM -0400, Ugen Antsilevitch wrote:
> > The part that obviously interests me is IPFW - if you guys are
> > interested to put some effort in "real" i.e. stateful firewall
> > to be developed i'd love to offer any help i can.
> >
> Great!
>
> How we should proceed -- that's the question.  My plan:
>
> * Clean the existing code (both userland and kernel) (10-20% done)
> * Re-design the ipfw's API
> * Port the existing functionality to the new API
> * Proceed with new features
>
> --
> Ruslan Ermilov  Sysadmin and DBA of the
> r...@ucb.crimea.uaUnited Commercial Bank,
> r...@freebsd.org  FreeBSD committer,
> +380.652.247.647Simferopol, Ukraine
>
> http://www.FreeBSD.org  The Power To Serve
> http://www.oracle.com   Enabling The Information Age
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Darren Reed]

In some email I received from Nicolai Petri, sie wrote:
> On Fri, 18 Jun 1999, Brian Fundakowski Feldman wrote:
> > On Fri, 18 Jun 1999, Ruslan Ermilov wrote:
> > 
> > > Let's join our efforts in this area!
> > > IPFW code is very ugly...
> > 
> >Which is basically due to it being hacked on for years without a cleanup.
> > Now's the time (between major versions) to do this, I think. How's this:
> > let's organize a small group to bounce ideas off eachother, first of all
> > (I'm forwarding this to hackers to perhaps elicit a response of more 
> > people.)
> > We should get ideas on what people think is wrong with the current
> > implementation, what new features should be added, and where we should
> > rearchitect.
> 
> What about support for protocol verification ?? (Example : Blocking of
> malformed ftp commands.) 

Surely you jest...

> Wich layer would it be logically to implement this in ?

5 and above.

> Is a userland proxy the only way ?

With a 100% reliability, yes.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Ruslan Ermilov]

On Thu, Jun 17, 1999 at 02:34:55PM -0400, Ugen Antsilevitch wrote:
> The part that obviously interests me is IPFW - if you guys are
> interested to put some effort in "real" i.e. stateful firewall
> to be developed i'd love to offer any help i can.
> 
Great!

How we should proceed -- that's the question.  My plan:

* Clean the existing code (both userland and kernel) (10-20% done)
* Re-design the ipfw's API
* Port the existing functionality to the new API
* Proceed with new features

-- 
Ruslan Ermilov  Sysadmin and DBA of the
r...@ucb.crimea.ua  United Commercial Bank,
r...@freebsd.orgFreeBSD committer,
+380.652.247.647Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Brian Fundakowski Feldman]

On Fri, 18 Jun 1999, Nicolai Petri wrote:

> On Fri, 18 Jun 1999, Brian Fundakowski Feldman wrote:
> > On Fri, 18 Jun 1999, Ruslan Ermilov wrote:
> > 
> > > Let's join our efforts in this area!
> > > IPFW code is very ugly...
> > 
> > implementation, what new features should be added, and where we should
> > rearchitect.
> 
> What about support for protocol verification ?? (Example : Blocking of
> malformed ftp commands.) 


I don't like the idea of implementing protocols MEANT for userland in the
kernel. Doing this leads to code duplication (a LOT of it) and unnecessary
complexity. This would just lead to people wanting an entire ftpd in the kernel
(which wouldn't be a good idea, even after having built the parsers/state
machine (or worse) into the kernel). This is entirely impractical, and
without a hybrid user/kernel model impossible.

> 
> Wich layer would it be logically to implement this in ?

This should be done in the user land.

> 
> Is a userland proxy the only way ?
> 
> 
> Nicolai Petri
> WM-data BFC
> 
> 
> 
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Nicolai Petri]

On Fri, 18 Jun 1999, Brian Fundakowski Feldman wrote:
> On Fri, 18 Jun 1999, Ruslan Ermilov wrote:
> 
> > Let's join our efforts in this area!
> > IPFW code is very ugly...
> 
>Which is basically due to it being hacked on for years without a cleanup.
> Now's the time (between major versions) to do this, I think. How's this:
> let's organize a small group to bounce ideas off eachother, first of all
> (I'm forwarding this to hackers to perhaps elicit a response of more people.)
> We should get ideas on what people think is wrong with the current
> implementation, what new features should be added, and where we should
> rearchitect.

What about support for protocol verification ?? (Example : Blocking of
malformed ftp commands.) 

Wich layer would it be logically to implement this in ?

Is a userland proxy the only way ?


Nicolai Petri
WM-data BFC




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Ruslan Ermilov]

On Fri, Jun 18, 1999 at 01:50:09PM -0400, Brian Fundakowski Feldman wrote:
> On Fri, 18 Jun 1999, Ruslan Ermilov wrote:
> 
> > On Fri, Jun 18, 1999 at 12:24:16PM -0400, Brian Fundakowski Feldman wrote:
> > > Hello, I'm Brian Feldman, a new committer to the FreeBSD source tree! 
> > > Some of
> > > the things I'll be working on are:
> > >   - maintaining and improving IPFW (cleanups too, of course)
> > Let's join our efforts in this area!
> > IPFW code is very ugly...
> 
>Which is basically due to it being hacked on for years without a cleanup.
> Now's the time (between major versions) to do this, I think. How's this:
> let's organize a small group to bounce ideas off eachother, first of all
> (I'm forwarding this to hackers to perhaps elicit a response of more people.)
> We should get ideas on what people think is wrong with the current
> implementation, what new features should be added, and where we should
> rearchitect.
> 
Agreed.
So, Jonathan, could you please create  for us?

>IPFW is reasonably small enough to redesign/reimplement in a few weeks
> (with multiple intelligent people working on it, of course =), so I think
> this is a worthwhile project. So Ruslan, why don't we organize a small group
> that will be doing this (this being the rewrite, and BTW I really want the
> external interface to IPFW to be backward-compatible)? We should then look
> through any relevant PRs and make sure to have all the info we need before
> undertaking this.
> 
I've closed a number of ipfw's PRs last week, most of them were for ipfw(8).


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA of the
r...@ucb.crimea.ua  United Commercial Bank,
r...@freebsd.orgFreeBSD committer,
+380.652.247.647Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

new-IPFW (was Re: Introduction)

[Brian Fundakowski Feldman]

I also want new-IPFW to be modular. This would mean that, for instance,
DUMMYNET would be just one plug-in to IPFW. More would be created in an
extensible manner, rather than the current hack to do DUMMYNET.

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Introduction

[Brian Fundakowski Feldman]

On Fri, 18 Jun 1999, Ruslan Ermilov wrote:

> On Fri, Jun 18, 1999 at 12:24:16PM -0400, Brian Fundakowski Feldman wrote:
> > Hello, I'm Brian Feldman, a new committer to the FreeBSD source tree! Some 
> > of
> > the things I'll be working on are:
> > - maintaining and improving IPFW (cleanups too, of course)
> Let's join our efforts in this area!
> IPFW code is very ugly...

   Which is basically due to it being hacked on for years without a cleanup.
Now's the time (between major versions) to do this, I think. How's this:
let's organize a small group to bounce ideas off eachother, first of all
(I'm forwarding this to hackers to perhaps elicit a response of more people.)
We should get ideas on what people think is wrong with the current
implementation, what new features should be added, and where we should
rearchitect.
   IPFW is reasonably small enough to redesign/reimplement in a few weeks
(with multiple intelligent people working on it, of course =), so I think
this is a worthwhile project. So Ruslan, why don't we organize a small group
that will be doing this (this being the rewrite, and BTW I really want the
external interface to IPFW to be backward-compatible)? We should then look
through any relevant PRs and make sure to have all the info we need before
undertaking this.

> > I hope this is the kind of thing Jordan wanted!
> > 
> John Birrell (IIRC).

Everyone would always appreciate some introduction :)

> 
> >  Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
> >  gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
> >  FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
> >  http://www.freebsd.org _ |___/___/___/ 
> > 
> > 
> 
> -- 
> Ruslan ErmilovSysadmin and DBA of the
> r...@ucb.crimea.uaUnited Commercial Bank,
> r...@freebsd.org  FreeBSD committer,
> +380.652.247.647  Simferopol, Ukraine
> 
> http://www.FreeBSD.orgThe Power To Serve
> http://www.oracle.com Enabling The Information Age
> 
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 gr...@freebsd.org   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message