headers
Harald Welte | 1 Aug 2004 18:46
Favicon

Re: [PATCH]: 1st step to remove skb_linearize() in ip6_tables.c and optimization

On Thu, Jul 29, 2004 at 03:09:02PM +0900, Yasuyuki Kozakai wrote:
> I got time to implement your idea. How about this ? (not tested)
>
> 	struct tcphdr hdr;
> 	struct tcphdr *tcph
> 
> 	tcph = skb_get_bits(skb, &hdr, skb->nh.iph->ihl*4, sizeof(hdr));
> 
> If skb is neither shared nor cloned, this function linearize up to tcp header
> and returns the pointer to tcp header in skb.
> 
> Otherwise, copies tcp header to "hdr" and return the pointer to it.
> If error, return NULL.

This sounds like a very sane approach to me.  

Since we don't have stable API's in 2.6.x anymore (kernel summit
decision), we could even put this in our pending queue of patches for
something like 2.6.10/2.6.11

What does eveybody else think?  Comments?

--

-- 
- Harald Welte <laforge <at> netfilter.org>             http://www.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
Permalink | Reply | 5 comments |
headers
Harald Welte | 1 Aug 2004 18:50
Favicon

Re: sctp conntrack

On Tue, Jul 27, 2004 at 01:48:34PM +0530, Kiran Kumar Immidi wrote:
> On Friday 23 July 2004 12:46 am, Harald Welte wrote:
> 
> > I was about to include the SCTP conntrack patch into my set of pending
> > patches for 2.6.9 but then discovered that you don't export the timeouts
> > via /proc (similar to what recent versions of ip_conntrack_tcp do).
> >
> > Would you please include suport for /proc tuning of the timeouts and
> > submit a patch against current CVS?
> 
>   The attached patch adds this support. It is a diff against current cvs pom 
> sctp-conntrack-nat module, the following doubt remains:

thanks, applied.

> 
> - The type of these timeouts in case of TCP is unsigned long, though the code 
> in ip_conntrack_standalone.c treats them as unsigned int. I am not sure of 
> the working, but I suspect something wrong here. I have followed the same 
> pattern however.

yes, indeed. on 64bit archs this is going to cause trouble :(

> Regards,
> Kiran Kumar Immidi
--

-- 
- Harald Welte <laforge <at> netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
(Continue reading)

Permalink | Reply | 6 comments |
headers
Harald Welte | 1 Aug 2004 18:59
Favicon

Re: Looking for IPtables developers - Need help at core of iptables (not configuration)

On Tue, Jul 27, 2004 at 11:59:38AM -0700, Leon Bene wrote:
> I am using iptables in Redhats' release (ES) of Linux. In version 7.1 of 
> Redhat (iptables 1.2.1a) it forwarded packets just fine. Now with iptables 
> 1.2.8 the outbound traffic hangs for about 5 seconds on rapid small packet 
> transmissions.

iptables-1.2.1a/1.2.8 are the userspace programs only, they never see or
touch a single packet - all happens in the kernel.

Please describe more detailed what particular problem you seem to be
encountering.

--

-- 
- Harald Welte <laforge <at> netfilter.org>             http://www.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
Permalink | Reply | 0 comments |
headers
Harald Welte | 1 Aug 2004 19:01
Favicon

Re: Logging NAT translations?

On Wed, Jul 28, 2004 at 05:07:41PM -0400, Chris Green wrote:

> The closest I've found is nfnetlink-ctnetlink.  

Yes, this should provide you with all information you need.

> Anyone know what the status of this is?  I know it doesn't work with
> 2.6 and I've been told it doesn't work with recent 2.4s either.

then someone needs to do some porting/merging work... patches
appreciated ;)

This is still not in the mainline kernel, because the netlink message
format is still not stable.

> Cheers,
> Chris

--

-- 
- Harald Welte <laforge <at> netfilter.org>             http://www.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
Permalink | Reply | 4 comments |
headers
Patrick McHardy | 1 Aug 2004 19:08
Favicon

Re: [PATCH]: 1st step to remove skb_linearize() in ip6_tables.c and optimization

Harald Welte wrote:

>On Thu, Jul 29, 2004 at 03:09:02PM +0900, Yasuyuki Kozakai wrote:
>  
>
>>I got time to implement your idea. How about this ? (not tested)
>>
>>	struct tcphdr hdr;
>>	struct tcphdr *tcph
>>
>>	tcph = skb_get_bits(skb, &hdr, skb->nh.iph->ihl*4, sizeof(hdr));
>>
>>If skb is neither shared nor cloned, this function linearize up to tcp header
>>and returns the pointer to tcp header in skb.
>>
>>Otherwise, copies tcp header to "hdr" and return the pointer to it.
>>If error, return NULL.
>>    
>>
>
>This sounds like a very sane approach to me.  
>
>Since we don't have stable API's in 2.6.x anymore (kernel summit
>decision), we could even put this in our pending queue of patches for
>something like 2.6.10/2.6.11
>
>What does eveybody else think?  Comments?
>  
>
The number of copies will still depend on the ruleset with non-linear skbs.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Harald Welte | 1 Aug 2004 19:19
Favicon

Re: adding field into conntrack

On Thu, Jul 29, 2004 at 10:29:43AM +1000, Rusty Russell wrote:
> On Thu, 2004-07-29 at 05:16, sandr8 <at> crocetta.org wrote:

> > would you mind if i add two 32 bits fields to the cnntrack structure?
> > i can surround them with an ifdef to have them only if the module i
> > am writing is configured. Their aim would be to count how many bytes
> > were transmitted on each side of the connection.
> 
> 	I believe there's already a patch like that, or one in progress. 
> You're not the only one who want this.

Yes, please see the 'conntrack-acct' patch in patch-o-matic-ng CVS.

> Rusty.

--

-- 
- Harald Welte <laforge <at> netfilter.org>             http://www.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
Permalink | Reply | 3 comments |
headers
Harald Welte | 1 Aug 2004 19:23
Favicon

Re: [ot] Standard patch exclude file?

On Thu, Jul 29, 2004 at 05:14:25AM -0700, Scott MacKay wrote:
> Instead of making it from scratch, I was wondering if
> anyone had a diff exclude file for making diff -urN
> patches....

please google for 'dontdiff', which leads you to
http://www.moses.uklinux.net/patches/dontdiff

> -Scott

--

-- 
- Harald Welte <laforge <at> netfilter.org>             http://www.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
Permalink | Reply | 0 comments |
headers
Harald Welte | 1 Aug 2004 19:29
Favicon

[PATCH 2.6] fix compilation of ip_nat_snmp_basic.c

Hi Dave!

Please sumbit before 2.6.8-final, this just moves some code in order to
make gcc happy.

Thanks!

Signed-off-by: Adrian Bunk <bunk <at> fs.tum.de>
Signed-off-by: Harald Welte <laforge <at> netfilter.org>

--- linux-2.6.7-mm6-full-gcc3.4/net/ipv4/netfilter/ip_nat_snmp_basic.c.old	2004-07-09
02:18:23.000000000 +0200
+++ linux-2.6.7-mm6-full-gcc3.4/net/ipv4/netfilter/ip_nat_snmp_basic.c	2004-07-09
02:21:00.000000000 +0200
 <at>  <at>  -862,6 +862,77  <at>  <at> 
 	return 1;
 }

+/* 
+ * Fast checksum update for possibly oddly-aligned UDP byte, from the
+ * code example in the draft.
+ */
+static void fast_csum(unsigned char *csum,
+                      const unsigned char *optr,
+                      const unsigned char *nptr,
+                      int odd)
+{
+	long x, old, new;
+	
+	x = csum[0] * 256 + csum[1];
(Continue reading)

Permalink | Reply | 1 comment |
headers
Harald Welte | 1 Aug 2004 19:31
Favicon

Re: [2.6 patch] netfilter/ip_nat_snmp_basic.c: fix inlines (fwd)

On Thu, Jul 29, 2004 at 11:20:49PM +0200, Adrian Bunk wrote:
> 
> FYI:
> The patch forwarded below is still required in 2.6.8-rc2-mm1.

I've pushed your patch to DaveM now.  Apparently some gcc-3.4 specific
issue...

--

-- 
- Harald Welte <laforge <at> netfilter.org>             http://www.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
Permalink | Reply | 0 comments |
headers
Harald Welte | 1 Aug 2004 20:11
Favicon

Re: [PATCH]: 1st step to remove skb_linearize() in ip6_tables.c and optimization

On Sun, Aug 01, 2004 at 07:08:59PM +0200, Patrick McHardy wrote:

> >>	struct tcphdr hdr;
> >>	struct tcphdr *tcph
> >>
> >>	tcph = skb_get_bits(skb, &hdr, skb->nh.iph->ihl*4, sizeof(hdr));
> >>
> >>If skb is neither shared nor cloned, this function linearize up to tcp 
> >>header and returns the pointer to tcp header in skb.
> >>Otherwise, copies tcp header to "hdr" and return the pointer to it.
> >>If error, return NULL.
>
> The number of copies will still depend on the ruleset with non-linear skbs.
> skb_linearize_partial sounds like a much better idea to me.

Oh yes, indeed.  I somehow mis-interpreted Yasuyiki's approach.  We
should linearize with the first call, so that every 2nd, 3rd, ... call
do nothing but immediately return.

> Regards
> Patrick

--

-- 
- Harald Welte <laforge <at> netfilter.org>             http://www.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
Permalink | Reply | 3 comments |

Gmane