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
next 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