Hello,
On Wed, 5 Dec 2001, Michael Richardson wrote:
> Julian> Yes, this is true. But this reassembling will disappear soon
>
> "soon" means 2.5/2.6, I hope. Not 2.4 series.
I don't know, there are other people that take the decision.
It seems Netfilter is the last thing that stops this change.
> When various systems screw up PMTU, (outside of our control, we have
> re-enabled generation of ICMP messages after turning it off a couple of
> releases ago) we get lots of 1500 byte packets that we need to prepend 48
> bytes to (IP + ESP) header. So, we wind up fragmenting the outgoing ESP.
>
> (We do not copy DF to the outer header at this time, since we can not cope
> with the unauthenticated ICMPs that would result).
>
> So, we get ESP fragments to reassemble.
>
> Once nice thing about seeing the fragments is that we might decide to
> implement a proposal for doing authenticated PMTU for tunnels by observing
> the size of the largest fragment.
Yes, it is interesting but ... not in my area
> I think you are missing what I am saying.
> Yes, it was called in the local delivery code, but is no longer.
> Our experience is that some aspect of compiling netfilter into a kernel
> (not necessarily with conntrack on) causes ip_defrag() to get called before
> local delivery.
I don't see where is the problem. There is always someone that
calls ip_defrag before the protocols, the last one is
ip_input.c:ip_local_deliver() if it is still not called. So, remains
the issue with the linearization and the checksums.
> Julian> will disappear soon. So, be warned. This is the reason we to talk
> Julian> for using these 2 lines. TCP is just ready for these changes (no
> Julian> surprises here).
>
> It would have been better if the transport protocol registration code had
> taken a flag (that TCP would set) that said "I can handle fragments".
Hm, there is such flag for IP but for the IP protocols I
don't see such flag, can't comment here. It seems all protocols in
the kernel already know what to do.
> What has happened is that you have changed the interface between network
> and transport code unilaterally causing a subtle incompatibility. This causes
> us to add code to compensate. This is BAD.
Not me but I see that some changes are for good, it is
difficult to follow them in some places but you can always return
to the old handling with some calls. My question to all: when the checksums
will be loosed? The same function in netfilter.c still touches the
checksum fields. So, make sure you deal with checksums too (probably
after the linearization).
> I would be happy to write a patch that implemented the above.
you can clear this issue with the maintainers ...
> We need to decrypt it. We need it linear.
> Yes, defragment is the wrong term if you like. Linearize is better.
>
> >> we will do this after we have checked for COW on the SKB.
>
> Julian> Instead of cow may be you have to look for another
> Julian> function (but it will be 2.4 specific). skb_cow copies data,
> Julian> although valid for 2.2, you must be sure that you need to copy
> Julian> the skb data (if you need write access) in 2.4. The other variant
> Julian> is to use function that expands the header if only that is the
> goal.
>
> We need to write (we decrypt in place).
OK, you need write access to the first fragment. It seems the
code is same in 2.2 and 2.4 for this but I'm not sure.
> We do:
>
> #ifdef NET_21
...
Regards
--
Julian Anastasov <ja@xxxxxx>
|