/* 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 Mon, 8 Jan 2001, D E Hammond wrote: > > > On 8 Jan, John D. Hardin wrote: > > | > > | On Mon, 8 Jan 2001, Brockhoven, Werner wrote: > > | > > | > For every new masqed connection this parameter is incremented with > > | > 1. If the masqed connection is closed/timed out , this value is > > | > decremented with 1. > > | > > | Can anybody confirm this behaviour? Has anybody else seen it on > > | earlier 2.2.x kernels? > > > > # cat /proc/sys/net/ipv4/ip_always_defrag > > 308231 > > ... > > > FWIW, since I started writing this: > > > > # cat /proc/sys/net/ipv4/ip_always_defrag > > 308244 > > 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. > 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(?). > Here's a patch that removes the decrement completely: > > *** linux/net/ipv4/ip_masq.c 2001-01-09 07:27:33-08 1.1 > --- linux/net/ipv4/ip_masq.c 2001-01-09 07:27:51-08 > *************** > *** 1075,1081 **** > mport_nono: > kfree_s(ms, sizeof(*ms)); > > - sysctl_ip_always_defrag--; > MOD_DEC_USE_COUNT; > return NULL; > } > --- 1075,1080 ---- > > > Here's another one that makes it safe: > > *** linux/net/ipv4/ip_masq.c 2001-01-09 07:27:33-08 1.1 > --- linux/net/ipv4/ip_masq.c 2001-01-09 07:34:43-08 > *************** > *** 1075,1081 **** > mport_nono: > kfree_s(ms, sizeof(*ms)); > > ! sysctl_ip_always_defrag--; > MOD_DEC_USE_COUNT; > return NULL; > } > --- 1075,1081 ---- > mport_nono: > kfree_s(ms, sizeof(*ms)); > > ! if (sysctl_ip_always_defrag > 1) sysctl_ip_always_defrag--; > MOD_DEC_USE_COUNT; > return NULL; > } > > > Alan? Does this look like a bug to you? i don't think preventing it from reaching zero is a problem. preventing it from going negative is the issue (i think). so: if (sysctl_ip_always_defrag > 0) sysctl_ip_always_defrag--; might be better. 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.
