/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! /* ALSO: Don't quote this header. It makes you look lame :-) */ 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". 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. > > 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... -- John Hardin KA7OHZ ICQ#15735746 http://www.wolfenet.com/~jhardin/ [EMAIL PROTECTED] pgpk -a finger://gonzo.wolfenet.com/jhardin 768: 0x41EA94F5 - A3 0C 5B C2 EF 0D 2C E5 E9 BF C8 33 A7 A9 CE 76 1024: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 ----------------------------------------------------------------------- The question of whether people should be allowed to harm themselves is simple. They *must*. -- Charles Murray ----------------------------------------------------------------------- 19 days until she returns _______________________________________________ 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.
