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

2006-05-23 Thread 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

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

2006-05-22 Thread Vlad Yasevich
On Sat, 2006-05-20 at 14:04 -0700, Andrew Morton wrote: Paul P Komkoff Jr [EMAIL PROTECTED] 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.

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

2006-05-22 Thread 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

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

2006-05-22 Thread 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

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

2006-05-22 Thread 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

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

2006-05-22 Thread 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

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

2006-05-22 Thread 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,

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

2006-05-22 Thread 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

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

2006-05-20 Thread Alexey Dobriyan
- Forwarded message from Paul P Komkoff Jr [EMAIL PROTECTED] - From: Paul P Komkoff Jr [EMAIL PROTECTED] To: Linux Kernel Mailing List linux-kernel@vger.kernel.org Subject: Was change to ip_push_pending_frames intended to break udp (more specifically, WCCP?) Hello! I have a userspace

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

2006-05-20 Thread Andrew Morton
Paul P Komkoff Jr [EMAIL PROTECTED] 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)