Hi Jozsef,

Jozsef Kadlecsik wrote:

>>>>f) Do you think that it's interesting adding fine grain locking in
>>>>tcp-window-tracking?
>>>>http://lists.netfilter.org/pipermail/netfilter-devel/2004-May/015166.html
>>>>        
>>>>
>>>First I was not quite convinced, but yes, I think it'd worth. However I
>>>believe we should introduce a generic per data locking in ip_conntrack
>>>instead of just a per TCP data locking. Thus there were no need the extra
>>>per protocol-helper locks either.
>>>
>>>      
>>>
>>yes, that would be also ok, but some other helpers like udp don't need
>>it, so is it worthy adding that field to the conntrack structure?
>>    
>>
>
>After thinking on it again, you're right, but I meant the
>application protocol-helper locks. If there is a TCP data lock, then there
>is no need for (TCP based) application protocol-helper locks.
>  
>

so you mean that we could use a single lock to protect both protocol and 
application helper private information, don't you? but in the case of 
the ftp helper the lock is protecting that global buffer, so your 
assumption would be wrong, wouldn't it?

I know that connection tracking shouldn't drop packets (in theory), but 
I think that it would be ok if we can add set an option via sysctl with 
the default return value. I mean, if we saw an unclean packet, return 
NF_DROP, just let the administrator choose how aggresive his tcp 
tracking is.

More feedback, I restructured the skeleton of the tcp_packet function, 
attached a patch. I moved up the call to the tcp_in_window function, so 
at first we check if a packets complies with Guido's four boundaries. 
Then we check if we saw a FIN packet which is out the boundaries so we 
came to the old state. And we get in the switch... I added both 
checkings which were performed after tcp_in_window (rst and set 
connection as assured) in the switch. Can you see any problem on this 
approach? if it's ok, I think it could sanitize the current structure of 
tcp_packet.

regards,
Pablo