[ANNOUNCE] netfilter-2.6.14 git tree / TODO

[ANNOUNCE] netfilter-2.6.14 git tree / TODO

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

Hi!

As you might have noticed, the pace of netfilter development has
_slightly_ changed over the last two weeks.  For those of you who are
intrested in joining the current development efforts (or even only
testing, which is definitely required), I suggest pulling the git tree
from 

rsync://people.netfilter.org/users/laforge/scm/netfilter-2.6.14.git

It is based on David Miller's net-2.6.14.git, and only contains those
new features and fixes that I intend to push to him soon (or have
already submitted but have not yet been included).

The areas of most work are currently nfnetlink, nfnetlink_log,
nfnetlink_queue and ip_conntrack_netlink (previously called ctnetlink).
Work in the kernel should be mostly finished, but the respective
userspace counterparts definitely need some work.

I've put together a quick TODO list at 
	http://people.netfilter.org/laforge/TODO

Your help is greatly appreciated. Please contact me if you want to work
on any of these issues.

Thanks,
	Harald
-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] netfilter-2.6.14 git tree / TODO

[Eric Leblond]

Hi,

On Sun, 2005-07-31 at 10:01 +0200, Harald Welte wrote:
> Hi!
> 
> The areas of most work are currently nfnetlink, nfnetlink_log,
> nfnetlink_queue and ip_conntrack_netlink (previously called ctnetlink).
> Work in the kernel should be mostly finished, but the respective
> userspace counterparts definitely need some work.

I'm writing you as one of the NuFW developers. As you may know this
project do an intensive use of ip_queue. So, we are really interested in
userspace counterparts. In particular, our center of interest is
libnfnetlink_queue. I will do some test in the coming days to check if
NuFW is working with NFQUEUE.

> I've put together a quick TODO list at 
> 	http://people.netfilter.org/laforge/TODO

I will start from point one of libnfnetlink_queue and let you know.


I also have got one related question :
Is the userspace marking enable in NFQUEUE ?

Thanks for the work ! I can not wait to see a snort-inline, NuFW
firewall.

BR,
-- 
Eric Leblond <eric@regit.org>
NuFW, Now User Filtering Works : http://www.nufw.org

Re: [ANNOUNCE] netfilter-2.6.14 git tree / TODO

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]

Hi Christian, I'm cc'ing the list so others don't miss the explanations
below:

On Sun, Jul 31, 2005 at 05:24:22AM -0300, Christian Hentschel wrote:

> I'd like to help with some of these stuff.
> I'm thinking about the conntrack part of the TODO list.

great.  I'm currently working on libnfnetlink_{queue,log} and later
probably ulogd2, so there is no overlap.

> Anyways, i'll need some detail of what's needing to be done =).

well, when you want to do the 'conntrack' part, you first need to fix up
'libnfnetlink_conntrack' (and libct, which is part of 'conntrack'
itself).

The main changes on the kernel side have been:

1) everything inside a 'struct nfattr' (But not itself!) is now always
   int network byte order.  So the userspace code needs ntohl(),
   ntohs(), .. all over the place.  Special care needs to be taken for
   64bit values, since at least I am not aware of any standard/portable
   'ntohll' like functions.  So my idea was to implement them once and
   put them into libnfnetlink.

2) the _FLUSH messages have been removed.  sending a _DEL message with
   no further specification will match all entries and  therefore _is_ a
   flush.

3) the tuples are now built by nested attributes.  This means that we
   don't pass any kernel structures to userspace, but rather encapsulate
   every value in it's own attribute.  userspace needs to correctly
   parse this and put it into some userspace structures.  None of the 
   library and application code should include anything from the kernel
   but include/linux/netfilter/nfnetlink*.h

4) some other messages have been renamed (RPLY -> REPLY). Mostly
   cosmetic.

After all this has been implemented, we can think of cleaning up the
layering between conntrack/libct/libnfnetlink_conntrack, but that's more
of a cleanup issue.  Let's make it functional first.

TIA,
	Harald

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] netfilter-2.6.14 git tree / TODO

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 3481 bytes --]

On Sun, Jul 31, 2005 at 11:29:53AM +0200, Eric Leblond wrote:
> Hi,
> 
> On Sun, 2005-07-31 at 10:01 +0200, Harald Welte wrote:
> > Hi!
> > 
> > The areas of most work are currently nfnetlink, nfnetlink_log,
> > nfnetlink_queue and ip_conntrack_netlink (previously called ctnetlink).
> > Work in the kernel should be mostly finished, but the respective
> > userspace counterparts definitely need some work.
> 
> I'm writing you as one of the NuFW developers. As you may know this
> project do an intensive use of ip_queue. 

Yes, it's a good candidate for testing nfnetlink_queue.

> So, we are really interested in userspace counterparts. In particular,
> our center of interest is libnfnetlink_queue. I will do some test in
> the coming days to check if NuFW is working with NFQUEUE.

great.  Please consider supporting nfnetlink_queue natively, rather than
using the (still incomplete) compat_libipq interface.  The latter has to
do one additional copy of every packet (to build the fake
ipq_packet_msg_t), which you definitely want to avoid.

> > I've put together a quick TODO list at 
> > 	http://people.netfilter.org/laforge/TODO
> 
> I will start from point one of libnfnetlink_queue and let you know.

Ok.  Please be aware that it doesn't currently implement any parsing of
the incoming messages.  I'm not really sure how a good api would look
like.  Maybe you can tell me what would work best from NuFW point of
view.  

The problem are the optional attributes.  A packet from the kernel could
optionally contain
	PAYLOAD
	MARK
	TIMESTAMP
	IFINDEX_IN
	IFINDEX_OUT
	...
and this may change from packet to packet.  so we cannot just pass a
fixed structure to the application program like libipq did.  OTOTH, I
don't want the applications have to do their own netlink message parsing
(with NFA_... macros), since that would violate the layering. Any ideas?

> I also have got one related question :
> Is the userspace marking enable in NFQUEUE ?

yes, it's all based on optional attributes. So if userspace sends a
NFQA_MARK attribute, the mark will be set by the kernel.  IF not, no
mark is set.

> Thanks for the work ! I can not wait to see a snort-inline, NuFW
> firewall.

Well, it should be pretty easy now - since you can have 65535 different
queues (and corresponding userspace processes).   One userspace process
can even tell the kernel to put a packet directly into another queue (by
sending a verdict "(group_num << 16) | NF_QUEUE".  I didn't test it, but
the code is designed to make this work.  Obviously in the normal case
the userspace apps wouldn't do that, since they don't know of each
other.

One problem that might become apparent now, is that the iptables QUEUE
target terminates execution of iptables, and the packets don't reappear
in the chain, but rather continue at the next function at the netfilter
hookfn with next priority.  NF_REPEAT might be an option, but I'm not
sure how stuff like conntrack and nat would deal with packets
reappearing at the same hook.  Feedback welcome.

Cheers,
	Harald

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] netfilter-2.6.14 git tree / TODO

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On Sun, 2005-07-31 at 12:38 +0200, Harald Welte wrote:
> On Sun, Jul 31, 2005 at 11:29:53AM +0200, Eric Leblond wrote:
> > Hi,
> > 
> > On Sun, 2005-07-31 at 10:01 +0200, Harald Welte wrote:
> > > Hi!

> > So, we are really interested in userspace counterparts. In particular,
> > our center of interest is libnfnetlink_queue. I will do some test in
> > the coming days to check if NuFW is working with NFQUEUE.
> 
> great.  Please consider supporting nfnetlink_queue natively, rather than
> using the (still incomplete) compat_libipq interface.  The latter has to
> do one additional copy of every packet (to build the fake
> ipq_packet_msg_t), which you definitely want to avoid.

Ok, I will work in that direction.


> The problem are the optional attributes.  A packet from the kernel could
> optionally contain
> 	PAYLOAD
> 	MARK
> 	TIMESTAMP
> 	IFINDEX_IN
> 	IFINDEX_OUT
> 	...
> and this may change from packet to packet.  so we cannot just pass a
> fixed structure to the application program like libipq did.  OTOTH, I
> don't want the applications have to do their own netlink message parsing
> (with NFA_... macros), since that would violate the layering. Any ideas?

It reminds me the problem we had when we had to define the NuFW
protocols. We take the idea from radius protocol which can contains an
arbitrary number of fields. This works as follow : 
start of the message contains the type of the message and its length
(calculate from the content). Then we have fields all optional
containing their type, option and length

Decomposition is the following :
MSG type | option | length
field type | option | length
DATA of field
field type | option | length
DATA of field
...
field type | option | length
DATA of field

It can easily be extended for any new fields as long as there is room in
the field type interval.

Hope this can help.

BR,
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] netfilter-2.6.14 git tree / TODO

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

On Sun, Jul 31, 2005 at 08:04:44PM +0200, Eric Leblond wrote:
> > The problem are the optional attributes.  A packet from the kernel could
> > optionally contain
> > 	PAYLOAD
> > 	MARK
> > 	TIMESTAMP
> > 	IFINDEX_IN
> > 	IFINDEX_OUT
> > 	...
> > and this may change from packet to packet.  so we cannot just pass a
> > fixed structure to the application program like libipq did.  OTOTH, I
> > don't want the applications have to do their own netlink message parsing
> > (with NFA_... macros), since that would violate the layering. Any ideas?
> 
> It reminds me the problem we had when we had to define the NuFW
> protocols. We take the idea from radius protocol which can contains an
> arbitrary number of fields. This works as follow : 
> start of the message contains the type of the message and its length
> (calculate from the content). Then we have fields all optional
> containing their type, option and length

The problem is not the protocol.  This is already implemented on the
kernel side, and there are accessor macros on the userspace side.  No
worries about that.

The problem is: How would your application like to interface with those
optional attributes.  The library should hide protocol details from
the application, but how would a sane API for that look like?

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] netfilter-2.6.14 git tree / TODO

[Samir Bellabes]

Harald Welte <laforge@netfilter.org> writes:

> I suggest pulling the git tree from 
>
> rsync://people.netfilter.org/users/laforge/scm/netfilter-2.6.14.git
>
> It is based on David Miller's net-2.6.14.git, and only contains those
> new features and fixes that I intend to push to him soon (or have
> already submitted but have not yet been included).
>

I started a tree for extensions in the p-o-m.
The git tree has already around 30 extensions, and is based on davem's
net-2.6.git

you can dowload the tarball of this tree here:
http://people.mandriva.com/~sbellabes/nf-2.6.git.tar.gz
http://people.mandriva.com/~sbellabes/git/nf-2.6.git/

Yes, i know, a rsync should be better, but the only server i got which
can host a rsync server, has a DSL link :/ 
Harald, can you provide hosting ? 

TODO:
  - updating patch for being sync with svn, but for now, we got a
structured tree.
  - add more extensions (sip, ..)

Here is the changelog against davem's tree for each branches
(main updates are kill lockhelp.h and fix compile problems, the branches
mdv is the merge branches of all extensions)

new targets:
  - ROUTE 
    o [NETFILTER] IPv{4,6} ROUTE target from svn-netfilter rev 3983
    o [NETFILTER] kill nf_debug for ROUTE
    o [NETFILTER] fix prototype function match for ROUTE
    o [NETFILTER] Need to export symbol nd_tbl for ROUTE IPv6

  - HOPLIMIT
    o [NETFILTER] IPv6 HOPLIMIT target from svn-netfilter rev 3983
    o [NETFILTER] fix prototype function match for HOPLIMIT

  - TARPIT
    o [NETFILTER] IPv4 TARPIT target from svn-netfilter rev 3983
    o [NETFILTER] kill nf_debug for TARPIT

  - IPV4OPTSSTRIP
    o [NETFILTER] IPv4 IPV4OPTSSTRIP target match from svn-netfilter rev 3983

  - IPMARK
    o [NETFILTER] IPv4 IPMARK target from svn-netfilter rev 3983

  - XOR
    o [NETFILTER] IPv4 XOR target from svn-netfilter rev 3983
    o [NETFILTER] XOR Makefile + Kconfig (svn rev 3983)

  - TTL
    o [NETFILTER] IPv4 TTL target from svn-netfilter rev 3983

matchs:
  - connrate :
    o [NETFILTER] IPv4 connrate match from svn-netfilter rev 3983
    o [NETFILTER] Kill lockhelp.h for connrate
    o [NETFILTER] Missing include for SMP (connrate)

  - nf_conntrack
    o [NETFILTER] IPv{4,6} nf_conntrack from svn-netfilter rev 3983
    o [NETFILTER] kill lockhelp.h for nf_conntrack
    o [NETFILTER] kill nf_debug for nf_conntrack
    o [NETFILTER] Fix compiling error with inline function nf_ct_put
    o [NETFILTER] dst_pmtu is no longer used for kernel >= 2.6.12
    o [NETFILTER] fix typo and missing lock for nf_conntrack

  - nth
    o [NETFILTER] IPv{4,6} nth match from svn-netfilter rev 3983
    o [NETFILTER] fix prototype function match for nth ipv6

  - random
    o [NETFILTER] IPv{4,6} random match from svn-netfilter rev 3983
    o [NETFILTER] Fix struct ipt_match ipt_rand_reg
    o [NETFILTER] fix prototype function match for random ipv4
    o [NETFILTER] fix prototype function match for random ipv6

  - pptp-conntrack-nat
    o [NETFILTER] IPv4 pptp-conntrack-nat from svn-netfilter rev 4096
    o [NETFILTER] Kill lockhelp.h for pptp-conntrack-nat
    o [NETFILTER] Fix missing ip_nat_pptp.h
    o [NETFILTER] kill lockhelp.h for pptp-conntrack-nat part 2
    o [NETFILTER] kill lockhelp.h for proto_gre
    o [NETFILTER] Define macros for pptp-conntrack-nat
 
  - fuzzy
    o [NETFILTER] IPv{4,6} fuzzy match from svn-netfilter rev 3983
    o [NETFILTER] fix prototype function match for fuzzy

  - condition
    o [NETFILTER] IPv{4,6} condition match from svn-netfilter rev 3983
    o [NETFILTER] Fix prototype function 'match'
    o [NETFILTER] fix compiling warnings in ip6t_condition

  - ipset
    o [NETFILTER] IPv4 ipset match/TARGET from svn-netfilter rev 3983
    o [NETFILTER] kill lockhelp.h for ipset

  - rsh-conntrack
    o [NETFILTER] IPv4 rsh-conntrack from svn-netfilter rev 4096
    o [NETFILTER] Kill lockhelp.h for rsh-conntrack
    o [NETFILTER] kill lockhelp.h for rsh part 2

  - rtsp_conntrack
    o [NETFILTER] IPv4 rtsp_conntrack from svn-netfilter rev 3983
    o [NETFILTER] Kill lockhelp.h for rtsp_conntrack
    o [NETFILTER] Introduce ip_ct_rtsp_master

  - ipv4options
    o [NETFILTER] IPv4 ipv4options match from svn-netfilter rev 3983

  - string (not enabled in configs)
    o [NETFILTER] IPv4 string match from svn-netfilter rev 3983

  - quota : [NETFILTER] IPv4 quota match from svn-netfilter rev 3983
  - mport : [NETFILTER] IPv4 mport match from svn-netfilter rev 3983
  - connlimit : [NETFILTER] IPv4 connlimit match from svn-netfilter rev 3983
  - time : [NETFILTER] IPv4 time match from svn-netfilter rev 3983
  - psd : [NETFILTER] IPv4 psd match from svn-netfilter rev 3983
  - osf : [NETFILTER] IPv4 osf match from svn-netfilter rev 3983
  - ipp2p : [NETFILTER] IPv4 ipp2p match from svn-netfilter rev 3983

others:
  - ip_queue_vwmark : [NETFILTER] ip_queue_vwmark from svn-netfilter rev 3983


-- 
Samir Bellabes
Mandriva

Re: [ANNOUNCE] netfilter-2.6.14 git tree / TODO

[Samir Bellabes]

Harald Welte <laforge@netfilter.org> writes:

> I suggest pulling the git tree from 
>
> rsync://people.netfilter.org/users/laforge/scm/netfilter-2.6.14.git
>
> It is based on David Miller's net-2.6.14.git, and only contains those
> new features and fixes that I intend to push to him soon (or have
> already submitted but have not yet been included).
>

I started a tree for extensions in the p-o-m.
The git tree has already around 30 extensions, and is based on davem's
net-2.6.git

you can dowload the tarball of this tree here:
http://people.mandriva.com/~sbellabes/nf-2.6.git.tar.gz
http://people.mandriva.com/~sbellabes/git/nf-2.6.git/

Yes, i know, a rsync should be better, but the only server i got which
can host a rsync server, has a DSL link :/ 
Harald, can you provide hosting ? 

TODO:
  - updating patch for being sync with svn, but for now, we got a
structured tree.
  - add more extensions (sip, ..)

Here is the changelog against davem's tree for each branches
(main updates are kill lockhelp.h and fix compile problems, the branches
mdv is the merge branches of all extensions)

new targets:
  - ROUTE 
    o [NETFILTER] IPv{4,6} ROUTE target from svn-netfilter rev 3983
    o [NETFILTER] kill nf_debug for ROUTE
    o [NETFILTER] fix prototype function match for ROUTE
    o [NETFILTER] Need to export symbol nd_tbl for ROUTE IPv6

  - HOPLIMIT
    o [NETFILTER] IPv6 HOPLIMIT target from svn-netfilter rev 3983
    o [NETFILTER] fix prototype function match for HOPLIMIT

  - TARPIT
    o [NETFILTER] IPv4 TARPIT target from svn-netfilter rev 3983
    o [NETFILTER] kill nf_debug for TARPIT

  - IPV4OPTSSTRIP
    o [NETFILTER] IPv4 IPV4OPTSSTRIP target match from svn-netfilter rev 3983

  - IPMARK
    o [NETFILTER] IPv4 IPMARK target from svn-netfilter rev 3983

  - XOR
    o [NETFILTER] IPv4 XOR target from svn-netfilter rev 3983
    o [NETFILTER] XOR Makefile + Kconfig (svn rev 3983)

  - TTL
    o [NETFILTER] IPv4 TTL target from svn-netfilter rev 3983

matchs:
  - connrate :
    o [NETFILTER] IPv4 connrate match from svn-netfilter rev 3983
    o [NETFILTER] Kill lockhelp.h for connrate
    o [NETFILTER] Missing include for SMP (connrate)

  - nf_conntrack
    o [NETFILTER] IPv{4,6} nf_conntrack from svn-netfilter rev 3983
    o [NETFILTER] kill lockhelp.h for nf_conntrack
    o [NETFILTER] kill nf_debug for nf_conntrack
    o [NETFILTER] Fix compiling error with inline function nf_ct_put
    o [NETFILTER] dst_pmtu is no longer used for kernel >= 2.6.12
    o [NETFILTER] fix typo and missing lock for nf_conntrack

  - nth
    o [NETFILTER] IPv{4,6} nth match from svn-netfilter rev 3983
    o [NETFILTER] fix prototype function match for nth ipv6

  - random
    o [NETFILTER] IPv{4,6} random match from svn-netfilter rev 3983
    o [NETFILTER] Fix struct ipt_match ipt_rand_reg
    o [NETFILTER] fix prototype function match for random ipv4
    o [NETFILTER] fix prototype function match for random ipv6

  - pptp-conntrack-nat
    o [NETFILTER] IPv4 pptp-conntrack-nat from svn-netfilter rev 4096
    o [NETFILTER] Kill lockhelp.h for pptp-conntrack-nat
    o [NETFILTER] Fix missing ip_nat_pptp.h
    o [NETFILTER] kill lockhelp.h for pptp-conntrack-nat part 2
    o [NETFILTER] kill lockhelp.h for proto_gre
    o [NETFILTER] Define macros for pptp-conntrack-nat
 
  - fuzzy
    o [NETFILTER] IPv{4,6} fuzzy match from svn-netfilter rev 3983
    o [NETFILTER] fix prototype function match for fuzzy

  - condition
    o [NETFILTER] IPv{4,6} condition match from svn-netfilter rev 3983
    o [NETFILTER] Fix prototype function 'match'
    o [NETFILTER] fix compiling warnings in ip6t_condition

  - ipset
    o [NETFILTER] IPv4 ipset match/TARGET from svn-netfilter rev 3983
    o [NETFILTER] kill lockhelp.h for ipset

  - rsh-conntrack
    o [NETFILTER] IPv4 rsh-conntrack from svn-netfilter rev 4096
    o [NETFILTER] Kill lockhelp.h for rsh-conntrack
    o [NETFILTER] kill lockhelp.h for rsh part 2

  - rtsp_conntrack
    o [NETFILTER] IPv4 rtsp_conntrack from svn-netfilter rev 3983
    o [NETFILTER] Kill lockhelp.h for rtsp_conntrack
    o [NETFILTER] Introduce ip_ct_rtsp_master

  - ipv4options
    o [NETFILTER] IPv4 ipv4options match from svn-netfilter rev 3983

  - string (not enabled in configs)
    o [NETFILTER] IPv4 string match from svn-netfilter rev 3983

  - quota : [NETFILTER] IPv4 quota match from svn-netfilter rev 3983
  - mport : [NETFILTER] IPv4 mport match from svn-netfilter rev 3983
  - connlimit : [NETFILTER] IPv4 connlimit match from svn-netfilter rev 3983
  - time : [NETFILTER] IPv4 time match from svn-netfilter rev 3983
  - psd : [NETFILTER] IPv4 psd match from svn-netfilter rev 3983
  - osf : [NETFILTER] IPv4 osf match from svn-netfilter rev 3983
  - ipp2p : [NETFILTER] IPv4 ipp2p match from svn-netfilter rev 3983

others:
  - ip_queue_vwmark : [NETFILTER] ip_queue_vwmark from svn-netfilter rev 3983


-- 
Samir Bellabes
Mandriva

Re: [ANNOUNCE] netfilter-2.6.14 git tree / TODO

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 232 bytes --]



On Tue, 2 Aug 2005, Samir Bellabes wrote:
<CIACH>
>  - mport : [NETFILTER] IPv4 mport match from svn-netfilter rev 3983

Why do we need this? We have multiport with ranges in 2.6.11.

Best regards,

 			Krzysztof Olędzki

Re: [ANNOUNCE] netfilter-2.6.14 git tree / TODO

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

On Tue, Aug 02, 2005 at 01:14:54PM +0200, Samir Bellabes wrote:
> Harald Welte <laforge@netfilter.org> writes:
> 
> > I suggest pulling the git tree from 
> >
> > rsync://people.netfilter.org/users/laforge/scm/netfilter-2.6.14.git
> >
> > It is based on David Miller's net-2.6.14.git, and only contains those
> > new features and fixes that I intend to push to him soon (or have
> > already submitted but have not yet been included).
> >
> 
> I started a tree for extensions in the p-o-m.
> The git tree has already around 30 extensions, and is based on davem's
> net-2.6.git
> 
> you can dowload the tarball of this tree here:
> http://people.mandriva.com/~sbellabes/nf-2.6.git.tar.gz
> http://people.mandriva.com/~sbellabes/git/nf-2.6.git/
> 
> Yes, i know, a rsync should be better, but the only server i got which
> can host a rsync server, has a DSL link :/ 

> Harald, can you provide hosting ? 

sure, you can get a people.netfilter.org account.   Please send me your
sshv2 public key and the preferred username.

>   - updating patch for being sync with svn, but for now, we got a
> structured tree.
>   - add more extensions (sip, ..)
> 
> Here is the changelog against davem's tree for each branches
> (main updates are kill lockhelp.h and fix compile problems, the branches
> mdv is the merge branches of all extensions)

ok, so you have one local branch per extension?  makes a lot of sense...

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]