Fw: [Bug 12014] New: Incorrect Urgent Pointer in outgoing packets

Fw: [Bug 12014] New: Incorrect Urgent Pointer in outgoing packets

[Stephen Hemminger]

Begin forwarded message:

Date: Wed, 12 Nov 2008 02:16:33 -0800 (PST)
From: bugme-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 12014] New: Incorrect Urgent Pointer in outgoing packets


http://bugzilla.kernel.org/show_bug.cgi?id=12014

           Summary: Incorrect Urgent Pointer in outgoing packets
           Product: Networking
           Version: 2.5
     KernelVersion: 2.6.27
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
        AssignedTo: shemminger@linux-foundation.org
        ReportedBy: kernel@tesarici.cz


Latest working kernel version: ??? (maybe never)
Earliest failing kernel version: 2.6.27
Distribution: kernel.org
Hardware Environment: x86, x86_64
Software Environment: Oracle, testcase
Problem Description:

When urgent mode is initiated using send(..., MSG_OOB), and the current
outgoing queue is longer than MTU, several packets are sent out with the URG
flag set. However, the Urgent Pointer field in the TCP header is not updated
correctly. Instead, it stays the same.

The receiving end interprets this as a new urgent message inserted further in
the stream, sends multiple SIGURGs to the server application and reads across
the urgent data. This behaviour is correct.

Steps to reproduce:

1. Initiate a TCP connection
2. Fill the outgoing queue with some (normal) data
3. Send an urgent message (with MSG_OOB)
4. Send some more non-urgent data.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Re: Fw: [Bug 12014] New: Incorrect Urgent Pointer in outgoing packets

[Ilpo Järvinen]

On Wed, 12 Nov 2008, Stephen Hemminger wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=12014
> 
>            Summary: Incorrect Urgent Pointer in outgoing packets
>            Product: Networking
>            Version: 2.5
>      KernelVersion: 2.6.27
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: IPV4
>         AssignedTo: shemminger@linux-foundation.org
>         ReportedBy: kernel@tesarici.cz
> 
> 
> Latest working kernel version: ??? (maybe never)
> Earliest failing kernel version: 2.6.27
> Distribution: kernel.org
> Hardware Environment: x86, x86_64
> Software Environment: Oracle, testcase
> Problem Description:
> 
> When urgent mode is initiated using send(..., MSG_OOB), and the current
> outgoing queue is longer than MTU, several packets are sent out with the URG
> flag set.

This urg flag in many segments is expected to happen (the urg pointer
might not point to the current segment but something that will follow)...

> However, the Urgent Pointer field in the TCP header is not updated
> correctly. Instead, it stays the same.

...but I've hard time believing that this true since the the only place
where urg_ptr is assigned is in tcp_output.c and that's done relative
to segments seqno:

	th->urg_ptr = htons(tp->snd_up - tcb->seq);

So if what you say is true, it means that snd_up should advance equally
to the segments seqno. Which means that writes would update it.

> The receiving end interprets this as a new urgent message inserted further in
> the stream, sends multiple SIGURGs to the server application and reads across
> the urgent data. This behaviour is correct.
> 
> Steps to reproduce:
> 
> 1. Initiate a TCP connection
> 2. Fill the outgoing queue with some (normal) data
> 3. Send an urgent message (with MSG_OOB)
> 4. Send some more non-urgent data.

Can you prove that your application is doing what you describe, I suspect 
that you e.g., forget to clear MSG_OOB... Can you strace the program 
please...  Getting a tcpdump at the same time wouldn't hurt either.

I've tried with this exact sequence recently (though after the rewrite of 
urg handling for 2.6.28), and did get a nicely working urg after fixing 
the bug that got introduced by the rewrite and just a single sigurg. It 
seems that I've lost that tcpdump somewhere though. I was using sendfile 
though for the normal data while you might not be doing the same.


-- 
 i.