Re: conntrack hash function
On Tue, Jun 25, 2002 at 12:10:44PM -0700, Don Cohen wrote: A few questions here: - Why make the two halves of the connection hash to different buckets? I'd think you'd want to consider the two halves to be the same connection. So you want them to hash the same. It would make the comparison a little more expensive, but save half the space. so what happens in case of NAT? The tuples are not the same in this case... -- 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+(*)
Re: possible race in init_conntrack()?
On Tue, Jul 02, 2002 at 11:14:51AM +0200, Patrick Schaaf wrote: Hi devel, Did I overlook something? Making drop_next atomic_t should be a good fix. no, you didn't. I'm not going to submit a patch for this, since we've never had a single bug report and it is very theoretic [whatever reason has to become true], and we are currently redesigning the conntrack hash anyway so I'd expect the new conntrack hash code including the limit-number-of-entries-per-chain code to fix this issue as well :) best regards Patrick -- 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+(*)
Re: [CRAP] Some patches
On Mon, Jun 17, 2002 at 12:02:39AM +0400, Paul P Komkoff Jr wrote:
This is the result of make allyesconfig
Actually, make allyesconfig won't link vmlinux due to netfilter p-o-m
additions. While conntrack_egg part isn't very clean (I'll resend
cleaner version later), and conntrack_rpc bombing out the kernel to panic,
and needs a big rewrite just because _tcp and _udp files ARE just a
copypaste results (Harald, so please move it to b0rken suite for now).
ok, I'll move conntrack_rpc.
But ipv6 stuff seems awful :( it just duplicating one function already
present in ipv6 code :( and doing it without static keyword ...
I think kisza has dealt with this..
diff -Nur --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet
a/net/ipv4/netfilter/ip_conntrack_egg.c
linux-2.4.19-pre10-ac2-s3/net/ipv4/netfilter/ip_conntrack_egg.c
ok, applied this one...
diff -Nur --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet
a/net/ipv4/netfilter/ipt_ah.c linux-2.4.19-pre10-ac2-s3/net/ipv4/netfilter/ipt_ah.c
--- a/net/ipv4/netfilter/ipt_ah.c Sat Jun 15 12:51:20 2002
+++ linux-2.4.19-pre10-ac2-s3/net/ipv4/netfilter/ipt_ah.c Fri Jun 14 12:31:05
2002
@@ -91,12 +91,12 @@
static struct ipt_match ah_match
= { { NULL, NULL }, ah, match, checkentry, NULL, THIS_MODULE };
-int __init init(void)
+static int __init init(void)
{
return ipt_register_match(ah_match);
}
-void __exit cleanup(void)
+static void __exit cleanup(void)
{
ipt_unregister_match(ah_match);
}
this one is now pending for kernel inclusion... (though it will be
post-2.4.19)
Paul P 'Stingray' Komkoff 'Greatest' Jr /// (icq)23200764 /// (http)stingr.net
--
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+(*)
Re: [PATCH}: Make MARK target terminate (resend)
On Fri, Jul 05, 2002 at 12:01:21PM +0800, Fabrice MARIE wrote: Hello Harald, On Friday 05 July 2002 07:58, Harald Welte wrote: [...] yes. But then, how do we distinguish between terminating targets [where we can have only one per rule] and non-terminating targets AKA actions, where we can have multiple. You could just add a boolean field 'terminating' to the iptables_target. Then, make sure iptables abort and complains if it sees more than one terminating target being requested in a single rule. no, it's not about how to distinguish it internally. It was more like: How does the user know which targets terminate and which don't [just by looking at the name or it's usage] But now, if you don't want to use the match piggybacking trick that Jozsef Henrik mentionned, then we can't implement that right now. no. There is no reason in implementing it right now anyway. A change like this would not appeear in 2.4.x anyway... Do you think multiple targets is worth including in the design of the next netfilter framework ? it's not a big issue anyway. Instead of a fixed single target entry, there is a linked list. I'm already working on that code.. I bielieve we should do that, multiple actions for one condition is very natural, and I believe the usage of a custom chain for each of theses rules is a bit overkill.. yes, it helps in some cases, but not in all. Any thoughts ? Fabrice. -- 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+(*)
Re: cttest-0.1
Hi, I've also done some plotting. about 400 student-machines behind router, it's summer now so there's not as much traffic as the rest of the year, only ~28k entries. hashsize is 16384 with default ip_conntrack_max of 131072. http://gandalf.hjorten.nu/kna-gw/ I added 16384 as size in ctreport as this is what's currently used. There's a huge diffrence between 16384 and 1638[35], from a maximum length of 181 down to 9. -- /Martin Never argue with an idiot. They drag you down to their level, then beat you with experience.
Re: cttest-0.1
2002-07-03 06:15:02+0200, Joakim Axelsson [EMAIL PROTECTED] - I collected this data 5am during absolut low time. I'll try again later at primetime :-) Here is a new stat with about 85K entries: http://aaricia.hemmet.chalmers.se/~gozem/cttest-2002-07-05_1739/ Look at the 131072 original hash (which we are running until i dare reboot the router :-) maximum bucket list length: 9471 -- /Joakim Axelsson A.K.A Gozem@EFnet OPN
Re: cttest-0.1
2002-07-05 18:54:15+0200, Patrick Schaaf [EMAIL PROTECTED] - - make the hash bucket count at least individible by 2. This should go as a strong suggestion into the documentation, and should be implemented in the default initialization code. Anybody volunteering for one or the other? I'll do the code part, but I won't do the docs. Well, I think we even can force people to use an odd count. if (hashsize%2 == 0) hashsize--; -- /Joakim Axelsson A.K.A Gozem@EFnet OPN
iptables -L command and other sugestions.
Hi all,
Firstly awesome job on iptables/netfilter..
1st Request/Suggestion: I would like to know if it's at all possible that
the same/similar code you guys use to track and delete a rule iptables -D
INPUT {options} can also be used when listing a rule instead of listing the
WHOLE table?
I am currently using a PHP script to do this.. ie.
php -q /root/bin/mrtg-iptables.php --ifout eth0 --prot tcp --dest
10.10.0.130 --sport 3128 --table HOSTS
But embedded would be great and much faster to search as I know no other way
than filtering it out which is slow and cpu chewy..
2nd Request/Suggestion: If there is any way to make the tables save their
byte/packet count to a DB file and reread back again for the sake of
rerunning the rules.. it checks if the rule exists in the DB and reads the
count.. if none there, set it to 0. If a special iptables switch is sent
it'll clear any rules not added/matched incase some rules where removed
previously.
This would be great as I use the byte count for download checks and I can't
rerun the rules and have to manually -I or -D them because -F and then -A
just resets the count. This would be great for ISPs I would guess.
Again at the moment I'm using PHP scripts to save all rules (-L-v-x-n) to a
/var/log/iptables.db file on stop/start and when adding it checks it against
the file and adds to it until I reset the DB.. a real pain but it's in the
works so far..
3rd Request/Suggestion: Last one, trust me ;) Sounds a bit script if too
many fired off but is it possible to fire off a command on matched rules? Of
course this could kill a server if nmap was used or something but with
careful planning using --limit etc.. this would make some things easy.. I
only know of doing something like`tail -f /var/log/kernel | grep
IPTINPUT | myscript` which handles search rules..
Sorry if this isn't the right place or the suggestions are pretty lame..
it'll just help me a sh$ load..
thanks,
George Vieira
Systems Manager
Citadel Computer Systems P/L
http://www.citadelcomputer.com.au
Re: [PATCH}: Make MARK target terminate (resend)
Hi Harald, On Fri, Jul 05, 2002 at 04:21:27PM +0200, Harald Welte wrote: You could just add a boolean field 'terminating' to the iptables_target. Then, make sure iptables abort and complains if it sees more than one terminating target being requested in a single rule. no, it's not about how to distinguish it internally. It was more like: How does the user know which targets terminate and which don't [just by looking at the name or it's usage] Random notice: the same question waits for the user who wants to understand the action of some previous user defined chain he just sees. Does that user defined chain terminate in any case? My point? iptables rulesets tend to become sufficiently complex in a short time so that vague inspection won't make a given ruleset easily understandable. IMHO that's a tribute to the flexibility we have with iptables. Engage brain before making modifications. have a nice weekend Patrick
Re: FYI: QUEUE ipqmpd bugs
On Fri, 2002-07-05 at 20:15, Harald Welte wrote: On Fri, Jul 05, 2002 at 04:08:54PM +0200, Jean-Michel Hemstedt wrote: FYI, I upgraded to iptables-1.2.6a (user kernel-2.4.18 patches) and got the following (maybe known) problems: - QUEUE target is NOK with kernel compiled with CONFIG_IP_NF_QUEUE=m = the packets are queued, but ipq_create_handle() returns can't create netlink socket ERROR: Unable to create netlink socket: Connection refused (problem with exported symbols?) =quick fix: compile kernel with CONFIG_IP_NF_QUEUE=y I think james should be able to answer that. The problem is that the ip_queue module isn't loaded automagically when a program requires it. I have no idea if this can be fixed or not but the problem is known and can easily be corrected by simply insmod ip_queue - ipqmpd-0.3: default verdict NF_ACCEPT is not applied when no process has attached to it. In fact ipqmpd starts, but it seems that it never receives any packet (in ipq_inp). When one process attaches to it, with a mark different from the queued packet, then the default NF_ACCEPT is applied correctly. When all processes have detached from ipqmpd, the default NF_ACCEPT continues to be applied correctly. ever looked at the CVS repository? http://www.gnumonks.org/cgi-bin/cvsweb.cgi/ipqmpd/ None of that code has been touched since 22 months... I wrote ipqmpd for fun, and nobody really seemed to use it. Feel free to submit patches or take over maintainership of ipqmpd :) kr, -jmhe- He who expects nothing shall never be disappointed -- 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+(*) -- Iain Barnes [EMAIL PROTECTED]
TCP tracking states
The recent discussions and Oskar Andreassons work on a iptables tutorial made me take a closer look into the TCP tracking states, and I notices a couple of odd things that looks like they may be bugs.. 1. What is the use of LAST_ACK? From what I can tell this state can only be reached if the connection is already in the LAST_ACK state.. 2. The support for half-closed connections is very poor, and differs a lot depending on which side closed first. To deal with 2, may I propose that the following symmetric FIN state machine is used instead of the odd assymetric one used today: ESTABLISHED / FIN - FIN_WAIT FIN_WAIT / ACK(R) - CLOSE_WAIT CLOSE_WAIT / FIN(R) - TIME_WAIT (or a new FIN_WAIT2 state) TIME_WAIT / ACK - TIME_WAIT And for completeness FIN_WAIT / FIN(R) - TIME_WAIT (or a new FIN_WAIT2 state) Regards Henrik
Re: Is it possible
iptables will only see the ip address - if it is http(s) traffic, apache(-ssl) can deal with virtual host-names using the same ip address. Darrell On Sat, Jul 06, 2002 at 01:25:41AM +0200, Peter Gosens wrote: Is it possible to make iptables forward packets based on hostname. I've one.cc.com and two.cc.com three.cc.com pointing to 213.93.43.28 . And I want that traffic with one.cc.com is going to 213.93.43.84. But the two.cc.com and three.cc.com traffic need to be forwarded to an internal network ip (suchs as 192.168.100.2). Is this possible with iptables. Or do I have to add an loadbalancer or use an proxy. I also thought about using ipv6, but it has an lack of supporting program's. If you have any other idea's about this matter. Please tell me. Peter Gosens
Hi to all
Hi, I'm a newbie. I'm using libiptc for my bachelor and I have some questions for you. (sorry :-.)) Ciao, Gino [EMAIL PROTECTED] Artificial intelligence is no match for natural stupidity.
[very long] libiptc and Java Native Interface
Hi to everyone,
I'm trying to use your libiptc by java native Interface, but I encounter
some problems.
I wrote two little programs in C (ehm, I copied the one you wrote...:-)
to add or delete a rule in the input chain. The programs work fine, but
if I compile them making two shared libs (and after I use their methods
by JNI), only the deleting one works (so I compiled well the shared
libraries).
The other one notify me an Invalid Argument on the iptc_commit().
Can You help me ? (I know that my English is very ugly, sorry)
I use linux 2.4.2, libiptc 0.1 (I guess), iptables 1.2.5 and java2 vers.
1.3.1_02.
I acclude the source code of the C program and the output of the shell -
I have setted on the dump_entry option - (you can see the output that
I get using the C program and the outputs I get using the shared library
by the JNI program; I have used different version of this shared lib,
changing the method to add an entry: I used iptc_append_entry,
iptc_insert_entry and iptc_replace_entry).
I discovered some differences between the output that I get using the C
code and the output that I get using the shared library: Interface,
flags and invflags are not null. Why ?
P.S.: to change the C program in a JNI-ready shared lib, I uncomment the
2 # include and change the int main() into JNIEXPORT void.,
after i compile it using gcc -o libaddrule.so Add.c -liptc
-I/usr/java/jdk1.3.1._02/include and after I copy the libaddrule.so in
the right directory.
Thanx for your time.
I hope you can help me (otherways I've to shift my bachelor).
// sample code appending a new rule to the FORWARD chain in the filter table
//#include Add.h
//#include jni.h
#include libiptc/libiptc.h
#include errno.h
#include stdio.h
#include stdlib.h
#include linux/netfilter.h
int main()
//JNIEXPORT void JNICALL
//Java_Add_AddRule(JNIEnv *env, jobject obj)
{
long result = 0;
iptc_handle_t handle;
struct ipt_standard_target target;
struct ipt_entry *chain_entry;
ipt_chainlabel labelit;
long size=0;
/* configuring the entry we'll make:
we want to append a rule to the forward chain in the filter table
this rule is simple: accept everything that reaches this point in the chain
*/
printf(size of standard target: %d\n, sizeof(target));
chain_entry = NULL;
/* the target of this rule is ACCEPT */
strncpy(target.target.u.user.name[0], DROP, 30); // other std rules would
include DROP etc
/* set the target size!! */
target.target.u.user.target_size=sizeof(target);
chain_entry = malloc(sizeof(struct ipt_entry) + sizeof(target));
memset(chain_entry, 0, sizeof(chain_entry)); /* zero it out */
// these could be used to specify ip addresses to be matched for the target,
here the src address is being matched
chain_entry-ip.src.s_addr=inet_addr(143.225.229.6); /* src address */
chain_entry-ip.smsk.s_addr=inet_addr(255.255.255.255); /* mask */
chain_entry-ip.dst.s_addr=inet_addr(143.225.229.6); /* dst address */
chain_entry-ip.dmsk.s_addr=inet_addr(255.255.255.255); /* mask */
chain_entry-ip.proto=0; /* any protocol */
printf(ok);
chain_entry-ip.iniface=;
printf(ok);
chain_entry-ip.outiface=;
printf(ok);
/* assuming
matches do not need to be taken into account, as we are matching everything! */
size=sizeof(struct ipt_entry);
Re: conntrack performance/DoS formula
Henrik Nordstrom writes: The TCP tracking states are approximations of RFC793. However, conntrack_tcp does not implement TCP, it only tries to derive the states of the involved TCP endpoints by looking at the transmitted packets. I understand that there are limits to what conntrack can do. However, someone has taken the trouble to compute assured, and this seems like a *much* better approximation to tcp established than what is actually presented as the intended approximation. I guess now that you can match on assured the right functionality is there, but the current tcp established still seems like false advertising. While I'm at it, so what happens in case of NAT? The tuples are not the same in this case... Yep, that's what I realized later.
FYI: QUEUE ipqmpd bugs
FYI, I upgraded to iptables-1.2.6a (user kernel-2.4.18 patches) and got the following (maybe known) problems: - QUEUE target is NOK with kernel compiled with CONFIG_IP_NF_QUEUE=m = the packets are queued, but ipq_create_handle() returns can't create netlink socket ERROR: Unable to create netlink socket: Connection refused (problem with exported symbols?) =quick fix: compile kernel with CONFIG_IP_NF_QUEUE=y - ipqmpd-0.3: default verdict NF_ACCEPT is not applied when no process has attached to it. In fact ipqmpd starts, but it seems that it never receives any packet (in ipq_inp). When one process attaches to it, with a mark different from the queued packet, then the default NF_ACCEPT is applied correctly. When all processes have detached from ipqmpd, the default NF_ACCEPT continues to be applied correctly. kr, ___ -jmhe- He who expects nothing shall never be disappointed
Re: FYI: QUEUE ipqmpd bugs
On Fri, 5 Jul 2002, Jean-Michel Hemstedt wrote: FYI, I upgraded to iptables-1.2.6a (user kernel-2.4.18 patches) and got the following (maybe known) problems: - QUEUE target is NOK with kernel compiled with CONFIG_IP_NF_QUEUE=m = the packets are queued, but ipq_create_handle() returns can't create netlink socket ERROR: Unable to create netlink socket: Connection refused (problem with exported symbols?) =quick fix: compile kernel with CONFIG_IP_NF_QUEUE=y You need to explicitly load the ip_queue module. - James -- James Morris [EMAIL PROTECTED]
Re: FYI: QUEUE ipqmpd bugs
On Fri, Jul 05, 2002 at 04:08:54PM +0200, Jean-Michel Hemstedt wrote: FYI, I upgraded to iptables-1.2.6a (user kernel-2.4.18 patches) and got the following (maybe known) problems: - QUEUE target is NOK with kernel compiled with CONFIG_IP_NF_QUEUE=m = the packets are queued, but ipq_create_handle() returns can't create netlink socket ERROR: Unable to create netlink socket: Connection refused (problem with exported symbols?) =quick fix: compile kernel with CONFIG_IP_NF_QUEUE=y I think james should be able to answer that. - ipqmpd-0.3: default verdict NF_ACCEPT is not applied when no process has attached to it. In fact ipqmpd starts, but it seems that it never receives any packet (in ipq_inp). When one process attaches to it, with a mark different from the queued packet, then the default NF_ACCEPT is applied correctly. When all processes have detached from ipqmpd, the default NF_ACCEPT continues to be applied correctly. ever looked at the CVS repository? http://www.gnumonks.org/cgi-bin/cvsweb.cgi/ipqmpd/ None of that code has been touched since 22 months... I wrote ipqmpd for fun, and nobody really seemed to use it. Feel free to submit patches or take over maintainership of ipqmpd :) kr, -jmhe- He who expects nothing shall never be disappointed -- 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+(*)
Re: cttest-0.1
2002-07-05 18:54:15+0200, Patrick Schaaf [EMAIL PROTECTED] - - make the hash bucket count at least individible by 2. This should go as a strong suggestion into the documentation, and should be implemented in the default initialization code. Anybody volunteering for one or the other? I'll do the code part, but I won't do the docs. Well, I think we even can force people to use an odd count. if (hashsize%2 == 0) hashsize--; -- /Joakim Axelsson A.K.A Gozem@EFnet OPN Just so you don't underestimate a requirement ... :-) if ((hashsize 1) == 0) hashsize++; (assume we are checking positive numbers ;-) -- -Cheers -Andrew MS ... if only he hadn't been hang gliding!
