Re: [PATCH] Compile fixes
On Sun, Jun 02, 2002 at 04:01:04PM +0200, Marcus Sundberg wrote: Hi, some fixes to make current CVS compile properly. thanks, applied. //Marcus -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ 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+(*) msg01144/pgp0.pgp Description: PGP signature
Re: ECN target in cvs broken?
On Sun, Jun 02, 2002 at 10:38:07PM -0400, Dave Hawkes wrote: I think there may be a typo in the ECN code recently commited to CVS line 12 in ipt_ecn.h yes, this has been fixed now. Dave Hawkes -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ 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+(*) msg01145/pgp0.pgp Description: PGP signature
Re: Dependence issue on today cvs
On Tue, Jun 04, 2002 at 12:33:46AM -0300, Thomas T. Soares wrote: Hi all packets hackers... This is just to inform that the today CVS of netfilter is giving this to me: typo is fixed now, should work again. | Thomas Tschoepke Soares | // En brujas no -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ 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+(*) msg01147/pgp0.pgp Description: PGP signature
[PATCH] NAT for unreplied connections
Hi,
The nat table is only used for the first packet in each
connection. This poses a problem if the events such as the
following occur:
1. TCP SYN packet sent, but no reply received.
2. iptables rules change or routing table changes such that
the TCP SYN packet should be NATed differently.
3. TCP SYN packet resent, but is NATed using the conntrack
created by the initial conntrack, and so it never reaches its
destination, or the reply is never received.
Currently, the only solution for this is to create a new
connection, often requiring the application to be killed and
restarted. This can happen for UDP connections and pings
too.
I searched in the list archives and found one other person
has noticed this problem too, but there were no replies:
http://lists.samba.org/pipermail/netfilter-devel/2002-January/003166.html
I've included a patch which changes the IP conntracking such
that the conntrack is recreated if a packet is sent in the
original direction before any replies are seen.
This solves my current problems, but my testing is fairly
minimal so far. Can anyone see any problems with this patch,
or have a better solution?
One problem may be that since the new conntrack may not have
the same source port as the original, UDP protocols that
don't require replies immediately after the first packet may
fail.
Regards,
Phil
--- linux-2.4.x/net/ipv4/netfilter/ip_conntrack_core.c 2 Oct 2001 09:36:12 -
1.1.1.2
+++ linux-2.4.x/net/ipv4/netfilter/ip_conntrack_core.c 4 Jun 2002 07:52:40 -
+ 1.3
-584,6 +584,16
/* look for tuple match */
h = ip_conntrack_find_get(tuple, NULL);
+
if (h !(h-ctrack-status IPS_SEEN_REPLY)
+
DIRECTION(h) == IP_CT_DIR_ORIGINAL) {
+
/* No reply yet, so recreate the conntrack in case the
+
NAT rules have changed. */
+
if (del_timer(h-ctrack-timeout)) {
+
death_by_timeout((unsigned long)h-ctrack);
+
ip_conntrack_put(h-ctrack);
+
h = NULL;
+
}
+
}
if (!h) {
h = init_conntrack(tuple, proto, skb);
if (!h)
[RFC] TCP core changes needed for transparent proxying
Hi,
Sorry to disturb you again with my transparent proxy efforts, but finally
after my third complete reorganization, things seem to work fine, without
_any_ core TCP changes.
I have a couple of problems though, which all involve core TCP code patches,
and so I would like some advice on the preferred way.
1. notification about destroyed sockets
I definitely need a notification when a socket is closed. Possible
solutions:
a) create a notifier in inet_sock_release() function, where my tproxy
module registers itself.
b) call a netfilter specific function when CONFIG_NETFILTER is defined
in a way similar to how setsockopts are delegated to netfilter.
I like the second option a bit more, as putting notifiers here and there is
IMHO ugly. Other parts in netfilter might need such a feature too, as
netfilter modules might assign state to sockets (through
setsockopt/getsockopt) which needs to be freed when the socket is closed.
2. receiving rewritten original address for datagram based protocols (UDP)
As looking up a table when a packet is received is not atomic (the way it
needs to be done when using simple NAT), I was thinking about attaching the
original address information to the packet itself, which can be queried via
an aux message with recvmsg(). As it is not possible to hook into aux
message processing, I did this with a patch to ip_sockglue.c. The important
parts of my patch is at the end of this message.
I tried to be as general as possible, and made the NAT framework to save
original addresses in IPCB(skb), which is returned in an IP_ORIGADDRS
auxillary message when recvmsg() is called on a socket with IP_RECVORIGADDRS
setsockopt enabled.
Is this solution ok for you?
3. specifying outgoing source address for datagram based protocols (UDP)
A similar problem applies to sending as well. To be atomic, I need to
specify the outgoing source address at sendmsg() time using an aux message.
The problem is again that it is difficult to hook into aux message
processing, and the skb is not created until ip_build_xmit() time, therefore
the skb cannot be used to store this information unless ip_build_xmit()
itself is patched.
Any idea to resolve this issue?
And now my current patch against ip_sockglue.c
diff -urN --exclude-from kernel-exclude linux-2.4.18-vanilla/net/ipv4/ip_sockglue.c
linux-2.4.18-cttproxy/net/ipv4/ip_sockglue.c
--- linux-2.4.18-vanilla/net/ipv4/ip_sockglue.c Wed Oct 31 00:08:12 2001
+++ linux-2.4.18-cttproxy/net/ipv4/ip_sockglue.cFri May 24 02:44:44 2002
+-48,6 +48,7
#define IP_CMSG_TOS4
#define IP_CMSG_RECVOPTS 8
#define IP_CMSG_RETOPTS16
+#define IP_CMSG_ORIGADDRS 32
/*
* SOL_IP control messages.
-107,6 +108,20
put_cmsg(msg, SOL_IP, IP_RETOPTS, opt-optlen, opt-__data);
}
+#if defined(CONFIG_IP_NF_NAT_NEEDED)
+
+void ip_cmsg_recv_origaddrs(struct msghdr *msg, struct sk_buff *skb)
+{
+struct in_origaddrs ioa;
+
+ioa.ioa_srcaddr.s_addr = IPCB(skb)-orig_srcaddr;
+ioa.ioa_srcport = IPCB(skb)-orig_srcport;
+ioa.ioa_dstaddr.s_addr = IPCB(skb)-orig_dstaddr;
+ioa.ioa_dstport = IPCB(skb)-orig_dstport;
+put_cmsg(msg, SOL_IP, IP_ORIGADDRS, sizeof(ioa), ioa);
+}
+
+#endif
void ip_cmsg_recv(struct msghdr *msg, struct sk_buff *skb)
{
-135,6 +150,12
if (flags 1)
ip_cmsg_recv_retopts(msg, skb);
+ if ((flags=1) == 0)
+ return;
+#if defined(CONFIG_IP_NF_NAT_NEEDED)
+ if (flags 1)
+ ip_cmsg_recv_origaddrs(msg, skb);
+#endif
}
int ip_cmsg_send(struct msghdr *msg, struct ipcm_cookie *ipc)
-167,6 +188,19
ipc-addr = info-ipi_spec_dst.s_addr;
break;
}
+#if defined(CONFIG_IP_NF_NAT_NEEDED)
+ case IP_ORIGADDRS:
+{
+struct in_origaddrs *ioa;
+
+if (cmsg-cmsg_len != CMSG_LEN(sizeof(struct in_origaddrs)))
+return -EINVAL;
+ioa = (struct in_origaddrs *) CMSG_DATA(cmsg);
+
+/* FIXME: where to store addresses so NAT might pick it up? */
+ break;
+ }
+#endif
default:
return -EINVAL;
}
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: [PATCH] Compile fixes
Harald Welte [EMAIL PROTECTED] writes: On Sun, Jun 02, 2002 at 04:01:04PM +0200, Marcus Sundberg wrote: Hi, some fixes to make current CVS compile properly. thanks, applied. Seems I forgot to include the patch for the POOL target in the first mail, so here it comes: Index: userspace/extensions/libipt_POOL.c === RCS file: /cvsroot/netfilter/userspace/extensions/libipt_POOL.c,v retrieving revision 1.3 diff -u -r1.3 libipt_POOL.c --- userspace/extensions/libipt_POOL.c 29 May 2002 13:08:16 - +++ userspace/extensions/libipt_POOL.c 2 Jun 2002 13:48:14 - @@ -15,6 +15,9 @@ #include libippool/ip_pool_support.h /* FIXME --RR */ +#define ip_pool_init ip_POOL_init +#define ip_pool_get_index ip_POOL_get_index +#define ip_pool_get_name ip_POOL_get_name #include ../ippool/libippool.c /* Function which prints out usage message. */ //Marcus -- ---+-- Marcus Sundberg [EMAIL PROTECTED] | Firewalls with SIP NAT Firewall Developer, Ingate Systems AB | http://www.ingate.com/
[RFC] matching tproxied packets
Hi, Suppose you have a TCP session, which is transparently redirected to a local proxy. With the current state of the tproxy framework one need to add two rules to iptables: - one to the tproxy table to actually redirect a session - one to the filter table to let the NATed traffic enter the local stack (in INPUT) I'd like to make tproxies easier to administer, so I'm thinking about a simple way of matching tproxied packets, which can be ACCEPTed from the INPUT chain. Possible solutions: * use a new state (called TPROXY), which would be applied to all TPROXYed packets (might interact badly with nat/conntrack). * have the tproxy framework mark all packets with an fwmark, and let the packets in based on the value of fwmark * have a separate match (called tproxy), which matches tproxied sessions based on some value stored in the associated conntrack entry which one do you prefer? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: [RFC] matching tproxied packets
Balazs Scheidler wrote: * use a new state (called TPROXY), which would be applied to all TPROXYed packets (might interact badly with nat/conntrack). It will in no doubt interact badly with connection tracking (and therefore NAT). * have the tproxy framework mark all packets with an fwmark, and let the packets in based on the value of fwmark Will interact badly with fwmark based routing. * have a separate match (called tproxy), which matches tproxied sessions based on some value stored in the associated conntrack entry Defenitely my preference, but I might be biased as I make heavy use of connection tracking and fwmark based routing in combination. Regards Henrik
Re: [RFC] matching tproxied packets
On Tue, Jun 04, 2002 at 05:14:47PM +0200, Henrik Nordstrom wrote: Balazs Scheidler wrote: * use a new state (called TPROXY), which would be applied to all TPROXYed packets (might interact badly with nat/conntrack). It will in no doubt interact badly with connection tracking (and therefore NAT). ok. * have the tproxy framework mark all packets with an fwmark, and let the packets in based on the value of fwmark Will interact badly with fwmark based routing. of course the mark value would be controlled by the user, and not assigned automatically. * have a separate match (called tproxy), which matches tproxied sessions based on some value stored in the associated conntrack entry Defenitely my preference, but I might be biased as I make heavy use of connection tracking and fwmark based routing in combination. This was my conclusion as well. So I'll go for this solution. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: [RFC] matching tproxied packets
Balazs Scheidler wrote: Will interact badly with fwmark based routing. of course the mark value would be controlled by the user, and not assigned automatically. As routing rules cannot mask fwmark, anything that touches the fwmark value for whatever purpose will affect your fwmark based routing. The main purpose of fwmark is to communicate state between netfilter and other kernel parts such as routing, not as a storage within netfilter. But sure, if all other uses of fmark supported masked operations then I would probably not object.. * have a separate match (called tproxy), which matches tproxied sessions based on some value stored in the associated conntrack entry Defenitely my preference, but I might be biased as I make heavy use of connection tracking and fwmark based routing in combination. This was my conclusion as well. So I'll go for this solution. Good ;-) Regards Henrik
Solution: Squid + ReiserFS + Iptables + H.323
Help required with Squid + ReiserFS + Iptables + H.323 ??? Please take a look at http://www.zedeks.com/wormhole.html Regards, tHeMiNeR
conntrack/NAT module
Hi,Harald
Thanks for your answers.
I am afraid that the conntrack module for DNAT is not correct now.my
purpose of the two module is to achieve the rule which is iptables -A
PREROUTING -t nat -p udp -d 159.226.1.1 --dport 5001 -j DNAT --to
192.168.1.2:.
The code of conntrack module is as follows:
static int foo_help(const struct iphdr *iph, size_t len,
struct ip_conntrack *ct,
enum ip_conntrack_info ctinfo)
{
struct ip_conntrack_tuple t,mask;
t = ((struct ip_conntrack_tuple)
{ { 0, { 0 } },
{ 0x0101e29f, { htons(5001) }, IPPROTO_UDP }}); //
proto=17,dst=159.226.1.1,dport=5001
mask = ((struct ip_conntrack_tuple)
{ { 0, { 0 } },
{ 0x, { 0x }, 0x }});
ip_conntrack_expect_related(ct, t, mask, NULL);
return NF_ACCEPT;
}
static struct ip_conntrack_helper foo = { { NULL, NULL },
{ { 0, { 0 } },
{ 0x0101e29f, { 0 }, IPPROTO_UDP } },
{ { 0, { 0 } },
{ 0x, { 0 }, 0x } },
foo_help }; //
proto=17,dst=159.226.1.1
int init_module(void)
{
return ip_conntrack_helper_register(foo);
}
void cleanup_module(void)
{
ip_conntrack_helper_unregister(foo);
}
After insmod the conntrack module and receiving udp packges sended to
159.226.1.1,I can see EXPECTING: proto=17 src=0.0.0.0 dst=159.226.1.1
sport=0 dport=5001in /proc/net/ip_conntrack.I don't know if my conntrack for
DNAT is correct?
The code of my nat module is as follows:
static int foo_nat_expected(struct sk_buff **pksb,
unsigned int hooknum,
struct ip_conntrack *ct,
struct ip_nat_info *info,
struct ip_conntrack *master,
struct ip_nat_info *masterinfo,
unsigned int *verdict)
{
struct ip_nat_multi_range mr;
u_int32_t newdstip;
if (HOOK2MANIP(hooknum)==IP_NAT_MANIP_DST){
newdstip = 0x0201a8c0; //192.168.1.2
mr.rangesize=1;
mr.range[0].flags |= IP_NAT_RANGE_PROTO_SPECIFIED;
mr.range[0].min = mr.range[0].max = ((union ip_conntrack_manip_proto)
{ htons() }); // forward
159.226.1.1:5001 to 192.168.1.2:,correct?
*verdict = ip_nat_setup_info(ct, mr, hooknum);
printk(### foo_nat_expected finished #\n);
return 1;
}
}
static unsigned int foo_help(struct ip_conntrack *ct,
struct ip_nat_info *info,
enum ip_conntrack_info ctinfo,
unsigned int hooknum,
struct sk_buff **pksb)
{
return NF_ACCEPT; // I don't know what I can do here
}
static struct ip_nat_expect foo_expect = { { NULL, NULL }, foo_nat_expected
};
static struct ip_nat_helper hlpr = { { NULL, NULL },
{ { 0, { 0 } },
{ 0x09050a0a, { 0 }, IPPROTO_UDP } },
{ { 0, { 0x } },
{ 0x, { 0 }, 0x } },
foo_help , test };
int init_module(void)
{
int ret;
if ((ret=ip_nat_expect_register(foo_expect))==0){
ret=ip_nat_helper_register(hlpr);
if (ret!=0)
ip_nat_expect_unregister(foo_expect);
}
return ret;
}
void cleanup_module(void)
{
ip_nat_helper_unregister(hlpr);
ip_nat_expect_unregister(foo_expect);
}
After the 159.226.1.1 received udp package to 5001 port, I can see the
### foo_nat_expected finished #imformation for each
package.But there is no DNAT happened.I copy the code from ip_conntrack_ftp.c
and ip_nat_ftp.c. where I made the mistake?
Thanks
luoqiang
Hi,all
Sorry to resend this mail,last mail is not can be seen.
I am writing a DNAT module to achieve the purpose which is identical to
iptables -A PREROUTING -t nat -p udp -d 159.226.1.1 --dport 5000 -j DNAT
--to 192.168.1.2:5000.
host A-host Bhost C
159.226.1.2---159.226.1.1/192.168.1.1---192.168.1.2
I have read the hacking howto and have finished the conntrack module,which
can be seen in proc/net/ip_conntrack
file of host B asEXPECTING : proto=17 src=0 dst=159.226.1.1 sport=0
dport=5000
But something wrong in my nat module.
Today CVS and 2.4.19-pre10 issue
Hi all... me again :-( I am trying to make work H.323... Today cvs of netfilter and 2.4.19-pre10: 1- kerner sources at /coisas/linux 2- export KERNEL_DIR=/coisas/linux 3- cd /CVSs/netfilter-cvs/userspace 4- ./runme --batch base extra ... some rejects answered with 'N' ... 5- kernel and modules compiled OK but not installed... 6- ln -s /coisas/linux /usr/src/linux just to make sure ;-) 7- at /CVSs/netfilter-cvs/userspace make ... cc -O2 -Wall -Wunused -I/coisas/linux/include -Iinclude/ -DIPTABLES_VERSION=\1.2.7\ -fPIC -o extensions/libipt_mark_sh.o -c extensions/libipt_mark.c extensions/libipt_mark.c: In function `parse': extensions/libipt_mark.c:67: structure has no member named `bit_op' extensions/libipt_mark.c:67: `IPT_MARK_BIT_OP_NONE' undeclared (first use in this function) extensions/libipt_mark.c:67: (Each undeclared identifier is reported only once extensions/libipt_mark.c:67: for each function it appears in.) extensions/libipt_mark.c:77: structure has no member named `bit_op' extensions/libipt_mark.c:77: `IPT_MARK_BIT_OP_OR' undeclared (first use in this function) extensions/libipt_mark.c:86: structure has no member named `bit_op' extensions/libipt_mark.c:86: `IPT_MARK_BIT_OP_AND' undeclared (first use in this function) extensions/libipt_mark.c: In function `print': extensions/libipt_mark.c:113: structure has no member named `bit_op' extensions/libipt_mark.c:113: `IPT_MARK_BIT_OP_AND' undeclared (first use in this function) extensions/libipt_mark.c:116: structure has no member named `bit_op' extensions/libipt_mark.c:116: `IPT_MARK_BIT_OP_OR' undeclared (first use in this function) extensions/libipt_mark.c: In function `save': extensions/libipt_mark.c:131: structure has no member named `bit_op' extensions/libipt_mark.c:133: `IPT_MARK_BIT_OP_AND' undeclared (first use in this function) extensions/libipt_mark.c:135: break statement not within loop or switch extensions/libipt_mark.c:136: `IPT_MARK_BIT_OP_OR' undeclared (first use in this function) extensions/libipt_mark.c:138: break statement not within loop or switch extensions/libipt_mark.c:139: `IPT_MARK_BIT_OP_NONE' undeclared (first use in this function) extensions/libipt_mark.c:141: break statement not within loop or switch make: *** [extensions/libipt_mark_sh.o] Error 1 What I am doing wrong here...? :-( -- | Thomas Tschoepke Soares | // En brujas no | ttsoares AT brturbo DOT com |(~~~//'~)acreo... |--UIN:961141---| \ / pero que las hay, | The fact is a secondary aspect of reality | `\_/' las hay !
Re: Today CVS and 2.4.19-pre10 issue
Hello, On Wednesday 05 June 2002 12:27, Thomas T. Soares wrote: Hi all... me again :-( I am trying to make work H.323... 4- ./runme --batch base extra cc -O2 -Wall -Wunused -I/coisas/linux/include -Iinclude/ -DIPTABLES_VERSION=\1.2.7\ -fPIC -o extensions/libipt_mark_sh.o -c extensions/libipt_mark.c extensions/libipt_mark.c: In function `parse': extensions/libipt_mark.c:67: structure has no member named `bit_op' extensions/libipt_mark.c:67: `IPT_MARK_BIT_OP_NONE' undeclared (first use in this function) extensions/libipt_mark.c:67: (Each undeclared identifier is reported only once [etc...] What I am doing wrong here...? :-( Seems like the patch extra/mark-bitwise-ops got applied only half way: the userspace part only and not the kernel header part (which would be quite unlikely). Can you check that the file /usr/include/linux points to /usr/src/linux/include/linux ? : # ls -dl /usr/include/linux lrwxrwxrwx1 root root 28 May 16 16:27 /usr/include/linux - /usr/src/linux/include/linux/ If it doesn't, then make it point to it. That's all I can think of. I've just tried, to apply the patches like you did, with pre10 and the latest netfilter cvs snapshot and libipt_mark compiles fine : ... cc -O2 -Wall -Wunused -I/usr/src/linux//include -Iinclude/ -DIPTABLES_VERSION=\1.2.7\ -fPIC -o extensions/libipt_mark_sh.o -c extensions/libipt_mark.c ld -shared -o extensions/libipt_mark.so extensions/libipt_mark_sh.o ... Have a nice day, Fabrice. -- Fabrice MARIE Senior RD Engineer Celestix Networks http://www.celestix.com/ Silly hacker, root is for administrators -Unknown
