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 <plumbum@linux.nu>
>
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:16 EST