sendmsg() leaves Identification field in IP header empty

sendmsg() leaves Identification field in IP header empty

[Vladimir Ivaschenko]

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/

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,
and Identification field in IP header is set to non-zero values. Let me
know if you need any other information, as I do not have any experience
in debugging these sort of problems.

Please CC your replies, if any, to my e-mail as I'm not subscribed to
the list.

--
Best Regards
Vladimir Ivaschenko
Certified Linux Engineer (RHCE)

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

[Andi Kleen]

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

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

[Vladimir Ivaschenko]

Andi Kleen wrote about "Re: sendmsg() leaves Identification field in IP header empty":

> 
> 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) 

Andi, thanks a lot for the insight, I will try your suggestions.  
WCCP is a Web Cache Communication Protocol; it is used by Cisco
routers to forward traffic to proxies. What is confusing is that
send() generates an ID for packets with DF set, at least when
used in a way like Squid uses it. I briefly checked Squid source
code and didn't find any places where it would disable MTU Path
discovery.

> > 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.

Ok, an intercompatibility issue. :-)

-- 
Best Regards
Vladimir Ivaschenko
Certified Linux Engineer (RHCE)