Re: Was change to ip_push_pending_frames intended to break udp (more specifically, WCCP?)

Re: Was change to ip_push_pending_frames intended to break udp (more specifically, WCCP?)

[Andrew Morton]

Paul P Komkoff Jr <i@stingr.net> wrote:
>
> Hello!
> 
> I have a userspace application, which talks WCCP2 with cisco routers.
> It sends and receives UDP packets on port 2048. After I've updated my
> server to 2.6.16, it stopped working.
> 
> Examining logs and packet dumps of previous (2.6.15 kernel) vs.
> current, I found, that cisco will not understand packets generated by
> 2.6.16. The only difference in that packets was IP id field, which was
> increasing (1, 2, ...) with old kernel, and always 0 with 2.6.16.
> 
> Looking thru the changelog, I've found a suspect. It was this commit:
> http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1a55d57b107c3e06935763905dc0fb235214569d
> 
> Reverting this patch fixes my problems - the router understands
> packets again.
> 
> I took a look through the code and ip_select_ident codepath but still
> don't understand why it setting id to 0.

(netdev cc added)

Re: Was change to ip_push_pending_frames intended to break udp (more specifically, WCCP?)

[Vlad Yasevich]

On Sat, 2006-05-20 at 14:04 -0700, Andrew Morton wrote:
> Paul P Komkoff Jr <i@stingr.net> wrote:
> >
> > Hello!
> > 
> > I have a userspace application, which talks WCCP2 with cisco routers.
> > It sends and receives UDP packets on port 2048. After I've updated my
> > server to 2.6.16, it stopped working.
> > 
> > Examining logs and packet dumps of previous (2.6.15 kernel) vs.
> > current, I found, that cisco will not understand packets generated by
> > 2.6.16. The only difference in that packets was IP id field, which was
> > increasing (1, 2, ...) with old kernel, and always 0 with 2.6.16.
> > 
> > Looking thru the changelog, I've found a suspect. It was this commit:
> > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1a55d57b107c3e06935763905dc0fb235214569d
> > 
> > Reverting this patch fixes my problems - the router understands
> > packets again.
> > 
> > I took a look through the code and ip_select_ident codepath but still
> > don't understand why it setting id to 0.

IP id is set to 0 on unconnected sockets when the DF bit is set (path
mtu discovery is enabled).  Try issuing a connect() in your application
and see if the ids are increasing again.

-vlad

Re: Was change to ip_push_pending_frames intended to break udp (more specifically, WCCP?)

[Rick Jones]

> IP id is set to 0 on unconnected sockets when the DF bit is set (path
> mtu discovery is enabled).  Try issuing a connect() in your application
> and see if the ids are increasing again.

ID of zero again?  I thought that went away years ago?  Anyway, given 
the number of "helpful" devices out there willing to clear the DF bit, 
fragment and forward, perhaps always setting the IP ID to 0, even if DF 
is set, isn't such a good idea?

rick jones

Re: Was change to ip_push_pending_frames intended to break udp (more specifically, WCCP?)

[Vlad Yasevich]

On Mon, 2006-05-22 at 11:48 -0700, Rick Jones wrote:
> > IP id is set to 0 on unconnected sockets when the DF bit is set (path
> > mtu discovery is enabled).  Try issuing a connect() in your application
> > and see if the ids are increasing again.
> 
> ID of zero again?  I thought that went away years ago?  Anyway, given 
> the number of "helpful" devices out there willing to clear the DF bit, 
> fragment and forward, perhaps always setting the IP ID to 0, even if DF 
> is set, isn't such a good idea?

Hey... I just report what I find... ;)

I had to look at this code a bit for some SCTP cases as well and this
seems to be how it works.  Here a comment from the code for the case
of the DF bit being set
    /* This is only to work around buggy Windows95/2000
     * VJ compression implementations.  If the ID field
     * does not change, they drop every other packet in
     * a TCP stream using header compression.
     */

-vlad

> 
> rick jones
> 

Re: Was change to ip_push_pending_frames intended to break udp (more specifically, WCCP?)

[Paul P Komkoff Jr]

Replying to Vlad Yasevich:
>     /* This is only to work around buggy Windows95/2000
>      * VJ compression implementations.  If the ID field
>      * does not change, they drop every other packet in
>      * a TCP stream using header compression.
>      */

Unfortunately, cisco IOS also complains that packets are "duplicate".
And, regarding to your previous message on how to fix this - IIRC, if
I do connect() on this socket, it will refuse to receive datagrams
from hosts other than specified in connect(), and I will be unable to
bind another socket to the same port on my side.

That said, the only solution which is close to what been before, will
be to keep one socket for receive, and create socket for each router I
am communicating with, right?

-- 
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
 This message represents the official view of the voices in my head

Re: Was change to ip_push_pending_frames intended to break udp (more specifically, WCCP?)

[Vlad Yasevich]

On Tue, 2006-05-23 at 00:21 +0400, Paul P Komkoff Jr wrote:
> Replying to Vlad Yasevich:
> >     /* This is only to work around buggy Windows95/2000
> >      * VJ compression implementations.  If the ID field
> >      * does not change, they drop every other packet in
> >      * a TCP stream using header compression.
> >      */
> 
> Unfortunately, cisco IOS also complains that packets are "duplicate".
> And, regarding to your previous message on how to fix this - IIRC, if
> I do connect() on this socket, it will refuse to receive datagrams
> from hosts other than specified in connect(), and I will be unable to
> bind another socket to the same port on my side.
> 
> That said, the only solution which is close to what been before, will
> be to keep one socket for receive, and create socket for each router I
> am communicating with, right?

Yewwww...  I see you problem.

To me this sounds like a bug in IOS.  I hope someone else would comment.

I did previously search a bunch of RFC and nowhere did a find a
requirement that IDs should be non-zero when DF bit is set.  The only
time IP IDs are mentioned is in the fragmentation and reassembly
description. 

-vlad

Re: Was change to ip_push_pending_frames intended to break udp (more specifically, WCCP?)

[Alan Cox]

On Llu, 2006-05-22 at 11:48 -0700, Rick Jones wrote:
> ID of zero again?  I thought that went away years ago?  Anyway, given 
> the number of "helpful" devices out there willing to clear the DF bit, 
> fragment and forward, perhaps always setting the IP ID to 0, even if DF 
> is set, isn't such a good idea?

Any device that clears DF is so terminally broken that you've already
lost the battle the moment you bought it. 

Alan

Re: Was change to ip_push_pending_frames intended to break udp (more specifically, WCCP?)

[Rick Jones]

Alan Cox wrote:
> On Llu, 2006-05-22 at 11:48 -0700, Rick Jones wrote:
> 
>>ID of zero again?  I thought that went away years ago?  Anyway, given 
>>the number of "helpful" devices out there willing to clear the DF bit, 
>>fragment and forward, perhaps always setting the IP ID to 0, even if DF 
>>is set, isn't such a good idea?
> 
> 
> Any device that clears DF is so terminally broken that you've already
> lost the battle the moment you bought it. 

Perhaps, but still, always setting the IP datagram ID to the same value 
even with the DF bit set seems contrary to the "conservative in what we 
send" that is so often brought-forth as a reason a stack behaves the way 
it does.

rick jones

Re: Was change to ip_push_pending_frames intended to break udp (more specifically, WCCP?)

[Paul P Komkoff Jr]

Replying to David S. Miller:
> That's my position too and I'm pretty much going to ignore any
> request to change this behavior.

Accorind to this article, some people count this as security issue:
http://www.securityfocus.com/archive/1/427622

Well ... someone with Cisco support contract can open a TAC case on
this ?

-- 
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
 This message represents the official view of the voices in my head