Re: sendmsg() leaves Identification field in IP header empty

[Andi Kleen <ak@suse.de>]

Vladimir Ivaschenko <hazard@francoudi.com> writes:

> Hi All,
> 
> I've been struggling to understand why an application which worked fine
> on 2.2.X stopped working on 2.4.7 (RH72) and found out that sendmsg()
> always leaves Identification field in IP header set to 0 (at least for
> UDP sockets). This confuses Cisco devices when you're doing
> WCCP negotiations with them. The application is "Oops!" proxy server -
> http://zipper.paco.net/~igor/oops.eng/

Linux does that for all sockets with DF set.  Don't ask why it is a long story;
in summary for some reason it gets rather expensive to compute ipid so it is
avoided as far as possible and it is not strictly needed for packets with 
DF set because the ipid should be only needed for defragmenting.

For TCP it caused serious problems with buggy VJ header compression functions
so a 'fake id' per socket is generated. This was not done for UDP however. 

For UDP you could get an IPID by turning path mtu discovery off; i.e.
using the IP_PMTU_DISCOVERY socket options. See ip(7) for more details.

In theory the hack from TCP could be ported to UDP too, but I'm not sure if it is
worth it for WCCP (to be honest I don't know what WCCP is so I cannot assess if 
it's important enough to add a workaround for it) 

Another way would be to switch back to traditional ipid computation, as the
'secure' ipid does not seem to be worth the effort and problems it causes.

> 
> Sorry if I'm wrong but I think this is a kernel problem because
> sendmsg() is a system call. On RH6.2 with 2.2.19 this doesn't happen,

It's strictly not a bug because the RFCs don't require an IPID for !DF.


-Andi