* 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
Attachment:
pgp00355.pgp
Description: PGP signature
