On the other hand, I use -j TTL --ttl-inc 1 in PREROUTING to restore the TTL of packets going through the gateway as if packets forwarded through the gateway are coming from the gateway. So this _conflicts_ with your 'if(out) ttl++;' if I were to use --rttl in POSTROUTING after -j TTL in the mangle table. I think it best not to use 'if(out) ttl++;' in ipt_recent in this case.
I see your point about making a new table entry for any different TTL from the same ip address. Valid point indeed! --rttl seems to work fine with your suggested code change to r_list[location].ttl, so I'm using the following patch instead.
I wonder why you left the ?old? bug hanging around without giving your users any notice? You should have publicly announced --rttl code is not yet done somewhere in the documentation or on your announcement pages. It's kinda a lie to publicly release ipt_recent without announcing the TODO list of _old_ bugs. Before this patch, --rttl worked only in extremely rare condition when r_list[location].addr==addr and location==0. and u knew this was an old bug for a year or so? (sigh)
Patched against ipt_recent-0.3.0
--- linux/net/ipv4/netfilter/ipt_recent.c.orig 2003-03-03 00:27:47.000000000 -0500
+++ linux/net/ipv4/netfilter/ipt_recent.c 2003-03-03 15:51:37.000000000 -0500
@@ -266,6 +266,7 @@
skb.nh.iph->saddr = addr;
skb.nh.iph->daddr = addr;
+ skb.nh.iph->ttl = 0;
match(&skb,NULL,NULL,&info,0,NULL,sizeof(info),NULL);
kfree(skb.nh.iph);
@@ -360,7 +361,7 @@
* 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))) {
+ (!r_list[hash_table[hash_result]].ttl || r_list[hash_table[hash_result]].ttl == ttl))) {
/* Collision in hash table */
hash_result = (hash_result + 1) % ip_list_hash_size;
}
* per j (perj8@hotmail.com) wrote:
> 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.
If your patch is against 0.3.0 then it may very well matter since your
patch doesn't remove the 'if(out) ttl++;' line from 0.3.0. Could you
check for that?
> 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.
Yeah, that's an old bug from when I switched to using hash tables
apparently. I believe that *should* read:
while(hash_table[hash_result] != -1 && !(r_list[hash_table[hash_result]].addr == addr &&
(!r_list[hash_table[hash_result]].ttl || r_list[hash_table[hash_result]].ttl != ttl))) {
Instead. Note that I also had to invert the ttl check, it should be
considered a collision when the ttl doesn't match and matching ttl has
been requested.
> 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!
Unfortunately what you did doesn't really work. The goal of doing the
TTL match is to differentiate between IP addresses based on their TTL so
that they are really considered two seperate entities. What you've done
is to only allow one TTL value per IP address, whichever TTL came first.
So, for example:
10.10.0.1 sends to router, TTL == 32
10.10.0.1 gets added to recent list with ttl == 32
10.10.0.1 sends to router, TTL == 25
10.10.0.1 gets 'found' in the hash table but then fails the TTL match
10.10.0.1 with TTL of 25 will therefore never make it into the recent
list, which is wrong. Instead of just picking the first TTL and going
with that these two need to be treated seperately as if they were two
different IP addresses.
If you could try the above changes I'd like to hear if they work for you
or not. I'll try and find some time to really test the TTL code soon.
> 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
Thanks, added that into my local version.
Stephen
<< attach3 >>
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
