/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! /* ALSO: Don't quote this header. It makes you look lame :-) */ John D. Hardin wrote: > On Wed, 10 Jan 2001, raf wrote: > > > > Okay, after a brief look at the 2.2.17 source, here's what I find. The > > > ip_always_defrag parameter gets incremented whenever a new transparent > > > proxy or masq connection comes through. I would assume this is done to > > > ensure a masquerade gateway defragments (for security reasons), but > > > incrementing instead of just setting it to 1 is odd - maybe somebody > > > wants a counter for those events. If so, this is a strange place to > > > put it. > > > > it's not strange and it's not for security reasons. subsequent fragments > > could not possibly be demasqueraded without defragmentation because the > > complete tcp/udp headers aren't present in any but the first fragment. > > I understand the need for defragmentation when masq is used. What I > don't understand is why it isn't just "sysctl_ip_always_defrag = 1". yes, it's not obviously useful, is it? if it reflected the number of packet currently being defragmented, that would make some sense (except that that should probably live in a different sysctl variable). > I suspect the person who wrote this wants the defragmentation to be > managed intelligently (e.g. make sure it's on when masquerading, > return to the original state when no more traffic is being > masqueraded) but it's not working properly. If it was working > properly, the original poster would not have seen his defragmentation > being turned off. i thought he mentioned setting ip_always_defrag to 1 while masquerading was happening. if so, all he need do is not touch ip_always_defrag. maybe i'm remembering it wrong. > > > Which makes the next bit even odder: it *is* decremented when > > > ip_masq_new() (the get-a-masq-port-number function) fails, right next > > > to where the masq module in-use counter is decremented. This looks to > > > me like a bug, since in a specific set of circumstances it can lead to > > > ip_always_defragment being turned off unilaterally by the kernel. > > > > are you sure that it isn't incremented before the call to > > ip_masq_new(). if it is, then this wouldn't be a bug(?). > > It's incremented in two places: the beginning of ip_masq_new() and the > transparent proxy handler. It's decremented in one place: the end of > ip_masq_new() on an error exit. > > > i don't think preventing it from reaching zero is a problem. > > Preventing it from reaching zero is a problem if it was not zero > before any masq traffic was handled. I do *not* want the kernel to > unilaterally turn off defragmentation if at some point I explicitly > tell it to always defragment. > > This looks incomplete to me. What I don't understand yet is how it > could be decremented all the way to zero... by setting ip_always_defragment to 1 when it's currently > 1 ? i think these questions belong on the kernel mailing list where it's got a chance of being answered :) maybe a good idea is to change the semantics of ip_always_defragment so that is it always either 0 or 1 by setting it to 1 when masquerading starts and it isn't already 1 and never decrementing it? then, only the administrator can turn it off, not the kernel. of course, the implementers might have had good reasons for doing what they did. you'd have to ask them. raf _______________________________________________ Masq maillist - [EMAIL PROTECTED] Admin requests can be handled at http://www.indyramp.com/masq-list/ -- THIS INCLUDES UNSUBSCRIBING! or email to [EMAIL PROTECTED] PLEASE read the HOWTO and search the archives before posting. You can start your search at http://www.indyramp.com/masq/ Please keep general linux/unix/pc/internet questions off the list.
