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.
--
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
This message represents the official view of the voices in my head
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) 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)
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.
> >
> > 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
> 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
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
>
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
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
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
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
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