Re: value of /proc/sys/net/ipv4/ip_always_defrag changing due to masquerade traffic

[Ralf Nyren]

On Mon, Jan 10, 2000 at 12:38:08PM -0800, David S. Miller wrote:
>    Date:   Sun, 9 Jan 2000 16:40:51 +0100
>    From: Ralf Nyren <[e-mail]>
> 
>    I've noticed that when ip-traffic, to be masqueraded, is sent
>    through my firewall the value of
>    /proc/sys/net/ipv4/ip_always_defrag changes up and down. Both
>    positive and negative values have been observed.
> 
> This is very peculiar because if this is true then the ip_masq
> module would see negative module reference counts as well!
> 
> We increment/decrement the value exactly at the places where
> the module reference count in incremented/decremented, which is
> where ip_masq structures are created/destroyed respectively.
> 
> The only other spot where we modify the value is in IP firewalling,
> and there we only increment it, and we only do it once, for the
> first time we see potential transparent proxy activity.
> 
> Is there some script or other entity messing with the value on
> your system?

Non but me, although that's probably the reason. ;-)
My hypothesis is as follows:
 Since ip_masq_defrag now is sysctl-controlled it is set to
zero at boot-time, i.e. not enabled. Before when it wasn't, it
was always enabled when ip-masq was compiled into the kernel.
Therefore my firewall began dropping fragments when I changed to
kernel 2.2.14. This problem was solved by a echo 1 > ip_always_defrag.
Although at this moment masqueraded connections had already been
issued through the firewall and therefore the echo 1 didn't incremented
the value from 0 to 1 but instead changed it from a greater value back
to 1. When the ip_masq-connections later were closed and the ip_masq-structures
were released, ip_always_defrag was decremented to zero or a negative value,
depending on the number of ip_masq-connections that had been active.

Thanks to the information provided by Julian Anastasov the problem
was solved by setting ip_always_defrag to a high value or simply
wait for all ip_masq-connections to time out before setting it to 1.
 Although, I think the problem should be looked over since this
approach isn't really obvious if one doesn't know it.

regards
/Ralf Nyrén