* RE: [PATCH] big endian patch against netfilter after PPTP NAT pat ch
@ 2003-02-03 17:56 Chris Poon
2003-02-06 0:09 ` Philip Craig
2003-02-09 9:26 ` Harald Welte
0 siblings, 2 replies; 8+ messages in thread
From: Chris Poon @ 2003-02-03 17:56 UTC (permalink / raw)
To: 'netfilter-devel@lists.netfilter.org'
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
Padding was the first way I think of how to solve it, but now that I look at it
again, the problem is actually the size assumption of the mask - almost
all helpers assumes a 16 bit mask. The PPTP patch breaks that assumption,
and because of the nature of the patches, I wouldn't have modified all the
places where the mask is filled out. Maybe the correct way is solve this is to
make the field size change permanent in ip_conntrack_manip_proto and
ip_conntrack_tuple, and change all the places that fill out the mask to use
the right sized mask instead of 0xffff, which happens to break the big-endian
machines but not the little endian machines. What do you think?
-----Original Message-----
From: Harald Welte [mailto:laforge@gnumonks.org]
Sent: Monday, February 03, 2003 7:44 AM
To: Chris Poon
Cc: 'netfilter-devel@lists.netfilter.org'
Subject: Re: [PATCH] big endian patch against netfilter after PPTP NAT patch
I don't like this patch because:
1) there are non-64bit big endian machines, that don't need the padding
2) we should be able to have those structures and the respective
functions working in a portable way, with no #ifdef's all over the place.
Why is this so difficult? If all empty (padding) space is initialized
to zero, and the fields addressed only by the member names, the mask
compare should still work. Or am I missing something?
I have now added this whole issue to the bugtracking system, see
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=41
> Enjoy
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: text/html, Size: 3258 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] big endian patch against netfilter after PPTP NAT pat ch
2003-02-03 17:56 [PATCH] big endian patch against netfilter after PPTP NAT pat ch Chris Poon
@ 2003-02-06 0:09 ` Philip Craig
2003-02-09 9:29 ` Harald Welte
2003-02-09 9:26 ` Harald Welte
1 sibling, 1 reply; 8+ messages in thread
From: Philip Craig @ 2003-02-06 0:09 UTC (permalink / raw)
To: Chris Poon; +Cc: 'netfilter-devel@lists.netfilter.org'
Chris Poon wrote:
> Padding was the first way I think of how to solve it, but now that I look at it
> again, the problem is actually the size assumption of the mask - almost
> all helpers assumes a 16 bit mask. The PPTP patch breaks that assumption,
> and because of the nature of the patches, I wouldn't have modified all the
> places where the mask is filled out. Maybe the correct way is solve this is to
> make the field size change permanent in ip_conntrack_manip_proto and
> ip_conntrack_tuple, and change all the places that fill out the mask to use
> the right sized mask instead of 0xffff, which happens to break the big-endian
> machines but not the little endian machines. What do you think?
No, the masks the helpers currently use are the correct mask
for what they need. For example, the ftp helper wants the
mask to cover the IP address and the TCP port. The TCP port
is still only 16 bits regardless of what changes are made to
the structure, so the mask must still be 0xffff.
The problem is that they are storing the mask in the u.all
member of the union, rather than the specific member that
they are interested in. So if the total size of union
changes, the mask getting stored will no longer match up
with the appropriate member, depending on endianness and
padding.
The proper fix is what Harald said: zero out the structure, and
store the mask in the specific member, rather than u.all.
Once they are fixed properly, they will also work for any
future changes to the tuple structure.
Paul Mielke posted a patch a few weeks ago that fixed the ftp
helper and the SO_ORIGINAL_DST ioctl.
--
Philip Craig - philipc@snapgear.com - http://www.SnapGear.com
SnapGear - Custom Embedded Solutions and Security Appliances
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] big endian patch against netfilter after PPTP NAT pat ch
2003-02-03 17:56 [PATCH] big endian patch against netfilter after PPTP NAT pat ch Chris Poon
2003-02-06 0:09 ` Philip Craig
@ 2003-02-09 9:26 ` Harald Welte
1 sibling, 0 replies; 8+ messages in thread
From: Harald Welte @ 2003-02-09 9:26 UTC (permalink / raw)
To: Chris Poon; +Cc: 'netfilter-devel@lists.netfilter.org'
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]
On Mon, Feb 03, 2003 at 10:56:09AM -0700, Chris Poon wrote:
> Padding was the first way I think of how to solve it, but now that I
> look at it again, the problem is actually the size assumption of the
> mask - almost all helpers assumes a 16 bit mask.
Yes, this is correct.
> The PPTP patch breaks that assumption, and because of the nature of
> the patches, I wouldn't have modified all the places where the mask is
> filled out. Maybe the correct way is solve this is to make the field
> size change permanent in ip_conntrack_manip_proto and
> ip_conntrack_tuple, and change all the places that fill out the mask
> to use the right sized mask instead of 0xffff, which happens to break
> the big-endian machines but not the little endian machines. What do
> you think?
Yes, this is definitely the way to go. If you want to provide me a
patch for this (against a plain 2.4.20 or 2.4.21-preX kernel), it would
be really great. Otherwise I'll just put it on my TODO list, and I
don't know how long it will take...
> -----Original Message-----
Please stop full quoting on a mailinglist. This is a very basic
netiquette rule... if people want to read the original posting, they
will use a mailreader that supports threading - or alternatively go to
the list archives and read the old postings.
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] big endian patch against netfilter after PPTP NAT pat ch
2003-02-06 0:09 ` Philip Craig
@ 2003-02-09 9:29 ` Harald Welte
2003-02-09 16:53 ` Patrick Schaaf
0 siblings, 1 reply; 8+ messages in thread
From: Harald Welte @ 2003-02-09 9:29 UTC (permalink / raw)
To: Philip Craig; +Cc: Chris Poon, 'netfilter-devel@lists.netfilter.org'
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
On Thu, Feb 06, 2003 at 10:09:32AM +1000, Philip Craig wrote:
> No, the masks the helpers currently use are the correct mask
> for what they need. For example, the ftp helper wants the
> mask to cover the IP address and the TCP port. The TCP port
> is still only 16 bits regardless of what changes are made to
> the structure, so the mask must still be 0xffff.
>
> The problem is that they are storing the mask in the u.all
> member of the union, rather than the specific member that
> they are interested in. So if the total size of union
> changes, the mask getting stored will no longer match up
> with the appropriate member, depending on endianness and
> padding.
>
> The proper fix is what Harald said: zero out the structure, and
> store the mask in the specific member, rather than u.all.
> Once they are fixed properly, they will also work for any
> future changes to the tuple structure.
yes. David Miller has indicated that he wants us to use
individual-member initialization instead of our '{{{{ }}, }}' stuff.
So maybe this is the time to do the change - or at least use named
initializers like '{ asdf: 0xffff, }'
> Paul Mielke posted a patch a few weeks ago that fixed the ftp
> helper and the SO_ORIGINAL_DST ioctl.
I'll try to find it in the folder, I seem to have overlooked it, thanks.
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] big endian patch against netfilter after PPTP NAT pat ch
2003-02-09 9:29 ` Harald Welte
@ 2003-02-09 16:53 ` Patrick Schaaf
2003-02-10 11:01 ` Harald Welte
0 siblings, 1 reply; 8+ messages in thread
From: Patrick Schaaf @ 2003-02-09 16:53 UTC (permalink / raw)
To: netfilter-devel
> yes. David Miller has indicated that he wants us to use
> individual-member initialization instead of our '{{{{ }}, }}' stuff.
> So maybe this is the time to do the change - or at least use named
> initializers like '{ asdf: 0xffff, }'
Nowaways, we'd rather use the C99 syntax: { .asdf = 0xffff, }.
I'm all for a change towards such initializers; the current stuff
is completely opaque.
best regards
Patrick
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] big endian patch against netfilter after PPTP NAT pat ch
2003-02-09 16:53 ` Patrick Schaaf
@ 2003-02-10 11:01 ` Harald Welte
[not found] ` <20030210123142.GA8730@rave.iinet.net.au>
0 siblings, 1 reply; 8+ messages in thread
From: Harald Welte @ 2003-02-10 11:01 UTC (permalink / raw)
To: Patrick Schaaf; +Cc: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
On Sun, Feb 09, 2003 at 05:53:47PM +0100, Patrick Schaaf wrote:
> > yes. David Miller has indicated that he wants us to use
> > individual-member initialization instead of our '{{{{ }}, }}' stuff.
> > So maybe this is the time to do the change - or at least use named
> > initializers like '{ asdf: 0xffff, }'
>
> Nowaways, we'd rather use the C99 syntax: { .asdf = 0xffff, }.
Yes, Iforgot about that.
> I'm all for a change towards such initializers; the current stuff
> is completely opaque.
Anybody volunteering to make a patch? It's very easy, you don't even
need to know how to program ;)
If nobody raises his hand, I'll put it on my todo list [and you know,
it is long...]
> best regards
> Patrick
--
- Harald Welte <laforge@gnumonks.org> http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] big endian patch against netfilter after PPTP NAT pat ch
[not found] ` <20030210123142.GA8730@rave.iinet.net.au>
@ 2003-02-10 13:29 ` Harald Welte
0 siblings, 0 replies; 8+ messages in thread
From: Harald Welte @ 2003-02-10 13:29 UTC (permalink / raw)
To: levsky; +Cc: Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On Mon, Feb 10, 2003 at 08:31:42PM +0800, levsky@rave.iinet.net.au wrote:
> > Anybody volunteering to make a patch? It's very easy, you don't even
> > need to know how to program ;)
>
> If you don't mind an offer from a complete unknown, I'd be happy
> to take it on as a learning experience.
Sure, no problem. Just send me the patch and I'll review it to make
sure it's correct.
I have now converted (as an example) the pptp conntrack/nat helper, see
the 'line 392/416' hook in
http://cvs.netfilter.org/netfilter-extensions/helpers/pptp/ip_nat_pptp.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=u
Please use the latest 2.4.21-preX kernel for your patch and try to catch
all places within net/{ipv4,ipv6}/netfilter/*.c where this kind of
structure initialization is used.
Thanks in advance
> Cheers
> Mark
--
- Harald Welte <laforge@gnumonks.org> http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH] big endian patch against netfilter after PPTP NAT pat ch
@ 2003-02-10 17:39 Chris Poon
0 siblings, 0 replies; 8+ messages in thread
From: Chris Poon @ 2003-02-10 17:39 UTC (permalink / raw)
To: 'Harald Welte'; +Cc: 'netfilter-devel@lists.netfilter.org'
[-- Attachment #1.1: Type: text/plain, Size: 81 bytes --]
Here is the patch for changing most of the initializers to use qualified fields
[-- Attachment #1.2: Type: text/html, Size: 494 bytes --]
[-- Attachment #2: linux-netfilter-mask.patch --]
[-- Type: application/octet-stream, Size: 19629 bytes --]
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_amanda.c linux-2.4.20/net/ipv4/netfilter/ip_conntrack_amanda.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_amanda.c Thu Feb 6 09:40:14 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_conntrack_amanda.c Thu Feb 6 10:32:04 2003
@@ -154,11 +154,11 @@
{ { ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip,
{ 0 } },
{ ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.ip,
- { htons(exp_amanda_info->port) },
+ { tcp: { port: htons(exp_amanda_info->port) } },
IPPROTO_TCP }});
expect.mask = ((struct ip_conntrack_tuple)
{ { 0, { 0 } },
- { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
+ { 0xFFFFFFFF, { tcp: { port: 0xFFFF } }, 0xFFFF }});
expect.expectfn = NULL;
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_core.c linux-2.4.20/net/ipv4/netfilter/ip_conntrack_core.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_core.c Thu Feb 6 09:40:30 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_conntrack_core.c Thu Feb 6 11:43:44 2003
@@ -1328,8 +1328,8 @@
getorigdst(struct sock *sk, int optval, void *user, int *len)
{
struct ip_conntrack_tuple_hash *h;
- struct ip_conntrack_tuple tuple = { { sk->rcv_saddr, { sk->sport } },
- { sk->daddr, { sk->dport },
+ struct ip_conntrack_tuple tuple = { { sk->rcv_saddr, { tcp: { port: sk->sport } } },
+ { sk->daddr, { tcp: { port: sk->dport },
IPPROTO_TCP } };
/* We only do TCP at the moment: is there a better way? */
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_ftp.c linux-2.4.20/net/ipv4/netfilter/ip_conntrack_ftp.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_ftp.c Thu Nov 28 15:53:15 2002
+++ linux-2.4.20/net/ipv4/netfilter/ip_conntrack_ftp.c Thu Feb 6 10:34:48 2003
@@ -366,11 +366,11 @@
{ 0 } },
{ htonl((array[0] << 24) | (array[1] << 16)
| (array[2] << 8) | array[3]),
- { htons(array[4] << 8 | array[5]) },
+ { tcp: { port: htons(array[4] << 8 | array[5]) } },
IPPROTO_TCP }});
exp->mask = ((struct ip_conntrack_tuple)
{ { 0xFFFFFFFF, { 0 } },
- { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
+ { 0xFFFFFFFF, { tcp: { port: 0xFFFF } }, 0xFFFF }});
exp->expectfn = NULL;
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_h323.c linux-2.4.20/net/ipv4/netfilter/ip_conntrack_h323.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_h323.c Thu Feb 6 09:40:30 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_conntrack_h323.c Thu Feb 6 11:07:37 2003
@@ -108,11 +108,11 @@
{ { ct->tuplehash[!dir].tuple.src.ip,
{ 0 } },
{ data_ip,
- { data_port },
+ { udp: { port: data_port } },
IPPROTO_UDP }});
exp->mask = ((struct ip_conntrack_tuple)
{ { 0xFFFFFFFF, { 0 } },
- { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
+ { 0xFFFFFFFF, { udp: { port: 0xFFFF } }, 0xFFFF }});
exp->expectfn = NULL;
@@ -137,7 +137,7 @@
240, /* timeout */
{ { 0, { 0 } }, /* tuple */
{ 0, { 0 }, IPPROTO_TCP } },
- { { 0, { 0xFFFF } }, /* mask */
+ { { 0, { tcp: { port: 0xFFFF } } }, /* mask */
{ 0, { 0 }, 0xFFFF } },
h245_help /* helper */
};
@@ -237,11 +237,11 @@
{ { ct->tuplehash[!dir].tuple.src.ip,
{ 0 } },
{ data_ip,
- { data_port },
+ { tcp: { port: data_port } },
IPPROTO_TCP }});
exp->mask = ((struct ip_conntrack_tuple)
{ { 0xFFFFFFFF, { 0 } },
- { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
+ { 0xFFFFFFFF, { tcp: { port: 0xFFFF } }, 0xFFFF }});
exp->expectfn = h225_expect;
@@ -284,9 +284,9 @@
THIS_MODULE, /* module */
2, /* max_expected */
240, /* timeout */
- { { 0, { __constant_htons(H225_PORT) } }, /* tuple */
+ { { 0, { tcp: { port: __constant_htons(H225_PORT) } } }, /* tuple */
{ 0, { 0 }, IPPROTO_TCP } },
- { { 0, { 0xFFFF } }, /* mask */
+ { { 0, { tcp: { port: 0xFFFF } } }, /* mask */
{ 0, { 0 }, 0xFFFF } },
h225_help /* helper */
};
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_irc.c linux-2.4.20/net/ipv4/netfilter/ip_conntrack_irc.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_irc.c Thu Feb 6 09:40:30 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_conntrack_irc.c Thu Feb 6 11:07:37 2003
@@ -209,11 +209,11 @@
exp->tuple = ((struct ip_conntrack_tuple)
{ { 0, { 0 } },
- { htonl(dcc_ip), { htons(dcc_port) },
+ { htonl(dcc_ip), { tcp: { port: htons(dcc_port) } },
IPPROTO_TCP }});
exp->mask = ((struct ip_conntrack_tuple)
{ { 0, { 0 } },
- { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
+ { 0xFFFFFFFF, { tcp: { port: 0xFFFF } }, 0xFFFF }});
exp->expectfn = NULL;
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_mms.c linux-2.4.20/net/ipv4/netfilter/ip_conntrack_mms.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_mms.c Thu Feb 6 09:40:45 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_conntrack_mms.c Thu Feb 6 11:12:49 2003
@@ -238,12 +238,12 @@
exp->tuple = ((struct ip_conntrack_tuple)
{ { ct->tuplehash[!dir].tuple.src.ip, { 0 } },
{ mms_ip,
- { (__u16) ntohs(mms_port) },
+ { tcp: { port: (__u16) ntohs(mms_port) } },
mms_proto } }
);
exp->mask = ((struct ip_conntrack_tuple)
{ { 0xFFFFFFFF, { 0 } },
- { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
+ { 0xFFFFFFFF, { tcp: { port: 0xFFFF } }, 0xFFFF }});
exp->expectfn = NULL;
ip_conntrack_expect_related(ct, &expect);
UNLOCK_BH(&ip_mms_lock);
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_quake3.c linux-2.4.20/net/ipv4/netfilter/ip_conntrack_quake3.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_quake3.c Thu Feb 6 09:41:03 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_conntrack_quake3.c Thu Feb 6 11:15:53 2003
@@ -82,12 +82,12 @@
exp.tuple = ((struct ip_conntrack_tuple)
{ { ct->tuplehash[!dir].tuple.src.ip, { 0 } },
{ (u_int32_t) *((u_int32_t *)((int)udph + i)),
- { (__u16) *((__u16 *)((int)udph+i+4)) },
+ { udp: { port : (__u16) *((__u16 *)((int)udph+i+4)) } },
IPPROTO_UDP } }
);
exp.mask = ((struct ip_conntrack_tuple)
{ { 0xFFFFFFFF, { 0 } },
- { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
+ { 0xFFFFFFFF, { udp: { port: 0xFFFF } }, 0xFFFF }});
exp.expectfn = NULL;
ip_conntrack_expect_related(ct, &exp);
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_talk.c linux-2.4.20/net/ipv4/netfilter/ip_conntrack_talk.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_conntrack_talk.c Thu Feb 6 09:41:26 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_conntrack_talk.c Thu Feb 6 11:27:18 2003
@@ -119,11 +119,11 @@
{ { ct->tuplehash[dir].tuple.src.ip,
{ 0 } },
{ ct->tuplehash[dir].tuple.dst.ip,
- { htons(talk_port) },
+ { udp: { port: htons(talk_port) } },
IPPROTO_UDP }});
exp->mask = ((struct ip_conntrack_tuple)
{ { 0xFFFFFFFF, { 0 } },
- { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
+ { 0xFFFFFFFF, { udp: { port: 0xFFFF } }, 0xFFFF }});
exp->expectfn = talk_expectfn[talk_port - TALK_PORT];
@@ -148,11 +148,11 @@
{ { ct->tuplehash[!dir].tuple.src.ip,
{ 0 } },
{ addr->ta_addr,
- { addr->ta_port },
+ { tcp: { port: addr->ta_port } },
IPPROTO_TCP }});
exp->mask = ((struct ip_conntrack_tuple)
{ { 0xFFFFFFFF, { 0 } },
- { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
+ { 0xFFFFFFFF, { tcp: { port: 0xFFFF } }, 0xFFFF }});
exp->expectfn = NULL;
@@ -261,9 +261,9 @@
NULL, /* module */
1, /* max_expected */
240, /* timeout */
- { { 0, { __constant_htons(TALK_PORT) } }, /* tuple */
+ { { 0, { udp: { port: __constant_htons(TALK_PORT) } } }, /* tuple */
{ 0, { 0 }, IPPROTO_UDP } },
- { { 0, { 0xFFFF } }, /* mask */
+ { { 0, { udp: { port: 0xFFFF } } }, /* mask */
{ 0, { 0 }, 0xFFFF } },
lookup_help }, /* helper */
{ { NULL, NULL },
@@ -272,9 +272,9 @@
NULL, /* module */
1, /* max_expected */
240, /* timeout */
- { { 0, { __constant_htons(NTALK_PORT) } }, /* tuple */
+ { { 0, { udp: { port: __constant_htons(NTALK_PORT) } } }, /* tuple */
{ 0, { 0 }, IPPROTO_UDP } },
- { { 0, { 0xFFFF } }, /* mask */
+ { { 0, { udp: { port: 0xFFFF } } }, /* mask */
{ 0, { 0 }, 0xFFFF } },
lookup_nhelp } /* helper */
};
@@ -318,9 +318,9 @@
THIS_MODULE, /* module */
1, /* max_expected */
240, /* timeout */
- { { 0, { __constant_htons(TALK_PORT) } }, /* tuple */
+ { { 0, { udp: { port: __constant_htons(TALK_PORT) } } }, /* tuple */
{ 0, { 0 }, IPPROTO_UDP } },
- { { 0, { 0xFFFF } }, /* mask */
+ { { 0, { udp: { port: 0xFFFF } } }, /* mask */
{ 0, { 0 }, 0xFFFF } },
help }, /* helper */
{ { NULL, NULL },
@@ -329,9 +329,9 @@
THIS_MODULE, /* module */
1, /* max_expected */
240, /* timeout */
- { { 0, { __constant_htons(NTALK_PORT) } }, /* tuple */
+ { { 0, { udp: { port: __constant_htons(NTALK_PORT) } } }, /* tuple */
{ 0, { 0 }, IPPROTO_UDP } },
- { { 0, { 0xFFFF } }, /* mask */
+ { { 0, { udp: { port: 0xFFFF } } }, /* mask */
{ 0, { 0 }, 0xFFFF } },
nhelp } /* helper */
};
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_amanda.c linux-2.4.20/net/ipv4/netfilter/ip_nat_amanda.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_amanda.c Thu Feb 6 09:40:30 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_nat_amanda.c Thu Feb 6 11:43:44 2003
@@ -60,6 +60,7 @@
DEBUGP("nat_expected: We have a connection!\n");
exp_info = &ct->master->help.exp_amanda_info;
+ memset((void *)&mr, 0, sizeof (struct ip_nat_multi_range));
newdstip = ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.ip;
newsrcip = master->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip;
@@ -82,9 +83,8 @@
if (HOOK2MANIP(hooknum) == IP_NAT_MANIP_DST) {
mr.range[0].flags |= IP_NAT_RANGE_PROTO_SPECIFIED;
- mr.range[0].min = mr.range[0].max
- = ((union ip_conntrack_manip_proto)
- { htons(port) });
+ mr.range[0].min.tcp.port = mr.range[0].max.tcp.port
+ = htons(port);
}
return ip_nat_setup_info(ct, &mr, hooknum);
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_ftp.c linux-2.4.20/net/ipv4/netfilter/ip_nat_ftp.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_ftp.c Thu Feb 6 09:40:30 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_nat_ftp.c Thu Feb 6 11:43:44 2003
@@ -47,6 +47,7 @@
DEBUGP("nat_expected: We have a connection!\n");
exp_ftp_info = &ct->master->help.exp_ftp_info;
+ memset((void *)&mr, 0, sizeof (struct ip_nat_multi_range));
LOCK_BH(&ip_ftp_lock);
@@ -82,9 +83,8 @@
sure we map to the correct port */
if (HOOK2MANIP(hooknum) == IP_NAT_MANIP_DST) {
mr.range[0].flags |= IP_NAT_RANGE_PROTO_SPECIFIED;
- mr.range[0].min = mr.range[0].max
- = ((union ip_conntrack_manip_proto)
- { htons(exp_ftp_info->port) });
+ mr.range[0].min.tcp.port = mr.range[0].max.tcp.port
+ = htons(exp_ftp_info->port);
}
return ip_nat_setup_info(ct, &mr, hooknum);
}
@@ -182,6 +182,7 @@
DEBUGP("FTP_NAT: seq %u + %u in %u\n",
expect->seq, ct_ftp_info->len,
ntohl(tcph->seq));
+ memset((void *)&newtuple, 0, sizeof(struct ip_conntrack_tuple));
/* Change address inside packet to match way we're mapping
this connection. */
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_h323.c linux-2.4.20/net/ipv4/netfilter/ip_nat_h323.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_h323.c Thu Feb 6 09:40:30 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_nat_h323.c Thu Feb 6 11:43:44 2003
@@ -58,7 +58,7 @@
NULL, /* module */
{ { 0, { 0 } }, /* tuple */
{ 0, { 0 }, IPPROTO_TCP } },
- { { 0, { 0xFFFF } }, /* mask */
+ { { 0, { tcp: { port: 0xFFFF } } }, /* mask */
{ 0, { 0 }, 0xFFFF } },
h225_nat_help, /* helper */
h225_nat_expected /* expectfn */
@@ -86,6 +86,7 @@
DEBUGP("h225_nat_expected: We have a connection!\n");
master_info = &ct->master->expectant->help.ct_h225_info;
exp_info = &ct->master->help.exp_h225_info;
+ memset((void *)&mr, 0, sizeof (struct ip_nat_multi_range));
LOCK_BH(&ip_h323_lock);
@@ -127,9 +128,8 @@
sure we map to the correct port */
if (HOOK2MANIP(hooknum) == IP_NAT_MANIP_DST) {
mr.range[0].flags |= IP_NAT_RANGE_PROTO_SPECIFIED;
- mr.range[0].min = mr.range[0].max
- = ((union ip_conntrack_manip_proto)
- { port });
+ mr.range[0].min.tcp.port = mr.range[0].max.tcp.port
+ = port;
}
ret = ip_nat_setup_info(ct, &mr, hooknum);
@@ -252,6 +252,7 @@
DEBUGP("h323_data_fixup: offset %u + 6 in %u\n", info->offset, tcplen);
DUMP_TUPLE(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
DUMP_TUPLE(&ct->tuplehash[IP_CT_DIR_REPLY].tuple);
+ memset((void *)&newtuple, 0, sizeof(struct ip_conntrack_tuple));
if (!between(expect->seq + 6, ntohl(tcph->seq),
ntohl(tcph->seq) + tcplen - tcph->doff * 4)) {
@@ -390,9 +391,9 @@
"H.225", /* name */
IP_NAT_HELPER_F_ALWAYS, /* flags */
THIS_MODULE, /* module */
- { { 0, { __constant_htons(H225_PORT) } }, /* tuple */
+ { { 0, { tcp: { port: __constant_htons(H225_PORT) } } }, /* tuple */
{ 0, { 0 }, IPPROTO_TCP } },
- { { 0, { 0xFFFF } }, /* mask */
+ { { 0, { tcp: { port: 0xFFFF } } }, /* mask */
{ 0, { 0 }, 0xFFFF } },
h225_nat_help, /* helper */
h225_nat_expected /* expectfn */
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_irc.c linux-2.4.20/net/ipv4/netfilter/ip_nat_irc.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_irc.c Thu Feb 6 09:40:30 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_nat_irc.c Thu Feb 6 11:43:44 2003
@@ -68,6 +68,7 @@
IP_NF_ASSERT(!(info->initialized & (1 << HOOK2MANIP(hooknum))));
DEBUGP("nat_expected: We have a connection!\n");
+ memset((void *)&mr, 0, sizeof (struct ip_nat_multi_range));
newdstip = master->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip;
newsrcip = ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip;
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_mms.c linux-2.4.20/net/ipv4/netfilter/ip_nat_mms.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_mms.c Thu Feb 6 09:40:30 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_nat_mms.c Thu Feb 6 11:43:44 2003
@@ -194,6 +194,7 @@
IP_NF_ASSERT(!(info->initialized & (1 << HOOK2MANIP(hooknum))));
DEBUGP("ip_nat_mms: mms_nat_expected: We have a connection!\n");
+ memset((void *)&mr, 0, sizeof (struct ip_nat_multi_range));
newdstip = master->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip;
newsrcip = ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip;
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_pptp.c linux-2.4.20/net/ipv4/netfilter/ip_nat_pptp.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_pptp.c Thu Feb 6 09:40:30 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_nat_pptp.c Thu Feb 6 11:43:44 2003
@@ -65,6 +65,7 @@
IP_NF_ASSERT(!(info->initialized & (1 << HOOK2MANIP(hooknum))));
DEBUGP("we have a connection!\n");
+ memset((void *)&mr, 0, sizeof (struct ip_nat_multi_range));
LOCK_BH(&ip_pptp_lock);
ct_pptp_info = &master->help.ct_pptp_info;
@@ -101,8 +102,7 @@
mr.rangesize = 1;
mr.range[0].flags = IP_NAT_RANGE_MAP_IPS | IP_NAT_RANGE_PROTO_SPECIFIED;
mr.range[0].min_ip = mr.range[0].max_ip = newdstip;
- mr.range[0].min = mr.range[0].max =
- ((union ip_conntrack_manip_proto ) { newcid });
+ mr.range[0].min.gre.key = mr.range[0].max.gre.key = newcid;
DEBUGP("change dest ip to %u.%u.%u.%u\n",
NIPQUAD(newdstip));
DEBUGP("change dest key to 0x%x\n", ntohl(newcid));
@@ -117,8 +117,7 @@
mr.range[0].flags = IP_NAT_RANGE_MAP_IPS
|IP_NAT_RANGE_PROTO_SPECIFIED;
mr.range[0].min_ip = mr.range[0].max_ip = newsrcip;
- mr.range[0].min = mr.range[0].max =
- ((union ip_conntrack_manip_proto ) { newcid });
+ mr.range[0].min.gre.key = mr.range[0].max.gre.key = newcid;
DEBUGP("change src ip to %u.%u.%u.%u\n",
NIPQUAD(newsrcip));
DEBUGP("change 'src' key to 0x%x\n", ntohl(newcid));
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_quake3.c linux-2.4.20/net/ipv4/netfilter/ip_nat_quake3.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_quake3.c Thu Feb 6 09:40:30 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_nat_quake3.c Thu Feb 6 11:43:44 2003
@@ -152,6 +152,7 @@
DEBUGP("ip_nat_quake3: quake3_nat_expected: here we are\n");
DUMP_TUPLE(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
+ memset((void *)&mr, 0, sizeof (struct ip_nat_multi_range));
IP_NF_ASSERT(info);
IP_NF_ASSERT(master);
diff -urbw linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_talk.c linux-2.4.20/net/ipv4/netfilter/ip_nat_talk.c
--- linux-2.4.20.orig/net/ipv4/netfilter/ip_nat_talk.c Thu Feb 6 09:40:30 2003
+++ linux-2.4.20/net/ipv4/netfilter/ip_nat_talk.c Thu Feb 6 11:43:44 2003
@@ -335,9 +335,9 @@
"talk", /* name */
IP_NAT_HELPER_F_ALWAYS, /* flags */
THIS_MODULE, /* module */
- { { 0, { __constant_htons(TALK_PORT) } }, /* tuple */
+ { { 0, { udp: { port: __constant_htons(TALK_PORT) } } }, /* tuple */
{ 0, { 0 }, IPPROTO_UDP } },
- { { 0, { 0xFFFF } }, /* mask */
+ { { 0, { udp: { port: 0xFFFF } } }, /* mask */
{ 0, { 0 }, 0xFFFF } },
help, /* helper */
talk_nat_expected }, /* expectfn */
@@ -345,9 +345,9 @@
"ntalk", /* name */
IP_NAT_HELPER_F_ALWAYS, /* flags */
THIS_MODULE, /* module */
- { { 0, { __constant_htons(NTALK_PORT) } }, /* tuple */
+ { { 0, { udp: { port: __constant_htons(NTALK_PORT) } } }, /* tuple */
{ 0, { 0 }, IPPROTO_UDP } },
- { { 0, { 0xFFFF } }, /* mask */
+ { { 0, { udp: { port: 0xFFFF } } }, /* mask */
{ 0, { 0 }, 0xFFFF } },
nhelp, /* helper */
talk_nat_expected } /* expectfn */
@@ -372,6 +372,7 @@
IP_NF_ASSERT(!(info->initialized & (1<<HOOK2MANIP(hooknum))));
DEBUGP("ip_nat_talk_expected: We have a connection!\n");
+ memset((void *)&mr, 0, sizeof (struct ip_nat_multi_range));
LOCK_BH(&ip_talk_lock);
port = ct->master->help.exp_talk_info.port;
@@ -429,9 +430,8 @@
sure we map to the correct port */
if (HOOK2MANIP(hooknum) == IP_NAT_MANIP_DST) {
mr.range[0].flags |= IP_NAT_RANGE_PROTO_SPECIFIED;
- mr.range[0].min = mr.range[0].max
- = ((union ip_conntrack_manip_proto)
- { port });
+ mr.range[0].min.udp.port = mr.range[0].max.udp.port
+ = port;
}
ret = ip_nat_setup_info(ct, &mr, hooknum);
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-02-10 17:39 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-02-03 17:56 [PATCH] big endian patch against netfilter after PPTP NAT pat ch Chris Poon
2003-02-06 0:09 ` Philip Craig
2003-02-09 9:29 ` Harald Welte
2003-02-09 16:53 ` Patrick Schaaf
2003-02-10 11:01 ` Harald Welte
[not found] ` <20030210123142.GA8730@rave.iinet.net.au>
2003-02-10 13:29 ` Harald Welte
2003-02-09 9:26 ` Harald Welte
-- strict thread matches above, loose matches on Subject: below --
2003-02-10 17:39 Chris Poon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.