"David S. Miller" <davem@redhat.com> writes:
>
> The last drop was the accident with CommuniGatePRO. It has high preformance
> DNS resolver, using not-connected sockets concurrently and at some level
> of load it fails to resolve names even for local 100% reliable DNS services.
> I ridiculed its vendor for long time, but had to explain, why only
> Linux fails yet. The source appered clear, sockets get ICMPs from slow remote
> servers, which match new innocent sockets. It was the _end_, I shot
> the feature the same day when found that it is real.
Another possibility would be to check the IP-ID of the echoed packet header.
Save the current IPID counter when the socket is created. Ignore the ICMP
when the ID is older than the socket or wrapped. This gives an "ICMP window"
of 2^31 packets, which should be more than enough.
With the per destination IDs in 2.3 it is a bit more tricky, but not
impossible. One way would be to go back to the global counter again
and just use the inetpeer secret as unique offset (so that you can
get back to the global counter with just a subtraction)
The strange optimization of not using an IPID for DF packets would have
to go though. The global counter would not be slower than the current
inet_peer_idlock (same bus traffic)
Does this make sense?
-Andi
-
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 : Wed Feb 23 2000 - 21:00:27 EST