Linux Netfilter discussions
 help / color / mirror / Atom feed
From: "per j" <perj8@hotmail.com>
To: sfrost@snowman.net
Cc: netfilter@lists.netfilter.org, ipt_recent@snowman.net
Subject: ipt_recent 0.3.0 --rttl still doesn't work  (I made a patch instead, can't wait)
Date: Mon, 03 Mar 2003 13:20:12 +0000	[thread overview]
Message-ID: <F208OXC80dFvgSFVA4R00035c2a@hotmail.com> (raw)

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

I've played around with -j TTL and no it doesn't have to do with the TTL 
mangled in the FORWARD chain because all my rules with -m recent are in 
INPUT chain or the beginning of the FORWARD chain before ACCEPT.

I tried out the ipt_recent-0.3.0 release and the problem still exists.  I 
turned on debug and found out r_list[location].ttl is always the same and 
doesn't even come close to the ttl value stored in the recent list.

I got pretty fussed up patching and re-patching my kernel and your latest 
release still didn't fix the --rttl problem.  Finally I spend quite some 
time reviewing your source code.  Your code on the IPT_RECENT_TTL section 
doesn't do a single thing because the location variable in r_list[location] 
doesn't change when hash_result is incremented.  I tried adding location = 
hash_table[hash_result] in the while loop, but that caused kernel panic.  I 
rewrote the whole IPT_RECENT_TTL code and now my tests for TTL matching 
works.  I fixed it!

Also I fixed the (unreported) problem with ttl not being set zero when 
manually adding ip addresses into the recent list with a for loop in a bash 
script - eg. for blah_ip in bleh; do echo blah_ip > recentlist; done.  
Somehow the ttl value is non-zero but all the entires added into the recent 
list have that same non-zero ttl value.  However, doing echo xx.xx.xx.xx > 
recentlist in the command-line does properly set ttl zero.  I wonder why it 
behaves well when not in a script.

After some tests, I am confident that the following patch to the 
ipt_recent-0.3.0 source code will fix the --rttl and non-zero ttl problem in 
userctl.  It works for me.

Apologies for posting code here as I've not yet signed up at the 
developer-list, but let me know if you see any errors.

------------------------------------------------
--- ipt_recent.c.orig	2003-03-03 00:27:47.000000000 -0500
+++ ipt_recent.c	2003-03-03 07:19:16.000000000 -0500
@@ -266,6 +266,7 @@

	skb.nh.iph->saddr = addr;
	skb.nh.iph->daddr = addr;
+	skb.nh.iph->ttl = 0;	// ttl happens to be randomly assigned, make sure it 
is 0.
	match(&skb,NULL,NULL,&info,0,NULL,sizeof(info),NULL);
	kfree(skb.nh.iph);

@@ -354,21 +355,9 @@

	orig_hash_result = hash_result = hash_func(addr,ip_list_hash_size);
	/* Hash entry at this result used */
-	/* Check for TTL match if requested.  If TTL is zero then a match would 
never
-	 * happen, so match regardless of existing TTL in that case.  Zero means 
the
-	 * entry was added via the /proc interface anyway, so we will just use the
-	 * first TTL we get for that IP address. */
-	if(info->check_set & IPT_RECENT_TTL) {
-		while(hash_table[hash_result] != -1 && 
!(r_list[hash_table[hash_result]].addr == addr &&
-			(!r_list[location].ttl || r_list[location].ttl == ttl))) {
-			/* Collision in hash table */
-			hash_result = (hash_result + 1) % ip_list_hash_size;
-		}
-	} else {
-		while(hash_table[hash_result] != -1 && 
r_list[hash_table[hash_result]].addr != addr) {
-			/* Collision in hash table */
-			hash_result = (hash_result + 1) % ip_list_hash_size;
-		}
+	while(hash_table[hash_result] != -1 && 
r_list[hash_table[hash_result]].addr != addr) {
+		/* Collision in hash table */
+		hash_result = (hash_result + 1) % ip_list_hash_size;
	}

	if(hash_table[hash_result] == -1 && !(info->check_set & IPT_RECENT_SET)) {
@@ -459,6 +448,20 @@
				if(hits_found >= info->hit_count) ans = !info->invert; else ans = 
info->invert;
			}
		}
+	/* Check for TTL match if requested.  If TTL is zero then a match would 
never
+	 * happen, so match regardless of existing TTL in that case.  Zero means 
the
+	 * entry was added via the /proc interface anyway, so we will just use the
+	 * first TTL we get for that IP address. */
+		/* IPT_RECENT_TTL -> !ttl match -> ans = info->invert
+		 * TTL match section fix by bluecloud <cloudatcu teydotseeohem>
+		 * [aka perj8AThotmailDOTcom on the mailing list] */
+		if(info->check_set & IPT_RECENT_TTL && r_list[location].ttl && 
r_list[location].ttl != ttl) {
+			// TTL did not match
+			ans = info->invert;
+		}
+		if(debug && IPT_RECENT_TTL) printk(KERN_INFO "RECENT_TTL: match(): 
rttl:%u,ttl:%u \n",
+				r_list[location].ttl,
+				ttl);
		if(debug) {
			if(ans)
				printk(KERN_INFO "RECENT_NAME: match(): match addr: %u\n",addr);
---------------------------------------------------

>* per j (perj8@hotmail.com) wrote:
> > Have you got any luck fixing the --rttl bug?   It's already been a 
>couple
> > weeks since the last post.  I tried to go around this problem with no
> > success.  I don't want to put all my rules into one chain, the INPUT 
>chain,
> > to get it to work and prefer separate chains to make my firewall rules
> > easier to maintain.  Apparently --rttl doesn't work when --set is on a
> > different chain on the filter table.  That's the problem.
>
>Ok, coming back to this issue I'm pretty sure I have an idea as to what
>the problem is.  It's pretty simple, really, the TTL is going to change
>somewhere while in the kernel.  Probably in the routing logic.  This
>means that in PREROUTING the TTL is one thing but in FORWARD (after
>being routed) it's been decremented by one.
>
>The 'solution' to this problem would really be for the recent module to
>always go with the initial TTL and detect if the routing logic has been
>called or not to decide if it needs to increment the TTL to get back to
>the original TTL.  Unfortunately at the moment I'm not sure if that will
>be very easy or not but I'll look around and see if I can't make this
>work.
>
>	Stephen
><< attach3 >>


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

[-- Attachment #2: patch-ctl-rtt-ipt_recent.c-0.3.0.bz2 --]
[-- Type: application/octet-stream, Size: 1106 bytes --]

[-- Attachment #3: patch-ctl-rtt-ipt_recent.c-0.3.0.bz2.md5sum --]
[-- Type: text/plain, Size: 72 bytes --]

707719e9ad9c64d30c8273e9c9a405ba  patch-ctl-rtt-ipt_recent.c-0.3.0.bz2


             reply	other threads:[~2003-03-03 13:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-03 13:20 per j [this message]
2003-03-03 16:24 ` ipt_recent 0.3.0 --rttl still doesn't work (I made a patch instead, can't wait) Stephen Frost
  -- strict thread matches above, loose matches on Subject: below --
2003-03-03 22:01 per j
2003-03-04  0:48 ` Stephen Frost
2003-03-03 22:14 per j
2003-03-04  0:49 ` Stephen Frost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F208OXC80dFvgSFVA4R00035c2a@hotmail.com \
    --to=perj8@hotmail.com \
    --cc=ipt_recent@snowman.net \
    --cc=netfilter@lists.netfilter.org \
    --cc=sfrost@snowman.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox