Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] where is the field of Urgent Pointer in TCP

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 23 Jul 2003 10:50:29 -0700
On Wed, Jul 23, 2003 at 09:59:59AM -0400, Jason House wrote:
>    If my understanding is correct, it isn't that the urgent pointer 
> "isn't set", but is actually set to 0.

Nope, it's that it isn't set.  From "dissect_tcp()":

  if (tcph->th_flags & TH_URG) {
    th_urp = tvb_get_ntohs(tvb, offset + 18);
    /* Export the urgent pointer, for the benefit of protocols such as
       rlogin. */   
    tcpinfo.urgent = TRUE;
    tcpinfo.urgent_pointer = th_urp;
    if (check_col(pinfo->cinfo, COL_INFO))
      col_append_fstr(pinfo->cinfo, COL_INFO, " Urg=%u", th_urp);
    if (tcp_tree != NULL)   
      proto_tree_add_uint(tcp_tree, hf_tcp_urgent_pointer, tvb, offset + 18, 2, th_urp);
  } else
    tcpinfo.urgent = FALSE;

If URG isn't set in the TCP flags field - i.e., if the "Urgent Pointer
field significant" flag (to use the name RFC 793 uses) isn't set - the
urgent pointer isn't displayed.

> If this is correct, should TCP 
> possibly display non-zero urgent pointers if the URG bit is not set?

The contents of the urgent pointer field are to be ignored by TCP
implementations if URG isn't set; from RFC 793:

  Urgent Pointer:  16 bits

    This field communicates the current value of the urgent pointer as a
    positive offset from the sequence number in this segment.  The
    urgent pointer points to the sequence number of the octet following
    the urgent data.  This field is only be interpreted in segments with
    the URG control bit set.

> Am I mistaken about all TCP implementations setting the urgent pointer to
> 0?

I haven't seen all TCP implementations, so I can't say; however, I see
no requirement in RFC 793 that it be set to zero if URG isn't set.  RFC
1122 ("Requirements for Internet Hosts -- Communication Layers") says
only

         4.2.2.4  Urgent Pointer: RFC-793 Section 3.1

            The second sentence is in error: the urgent pointer points
            to the sequence number of the LAST octet (not LAST+1) in a
            sequence of urgent data.  The description on page 56 (last
            sentence) is correct.

            A TCP MUST support a sequence of urgent data of any length.

            A TCP MUST inform the application layer asynchronously
            whenever it receives an Urgent pointer and there was
            previously no pending urgent data, or whenever the Urgent
            pointer advances in the data stream.  There MUST be a way
            for the application to learn how much urgent data remains to
            be read from the connection, or at least to determine
            whether or not more urgent data remains to be read.

            DISCUSSION:
                 Although the Urgent mechanism may be used for any
                 application, it is normally used to send "interrupt"-
                 type commands to a Telnet program (see "Using Telnet
                 Synch Sequence" section in [INTRO:1]).

                 The asynchronous or "out-of-band" notification will
                 allow the application to go into "urgent mode", reading
                 data from the TCP connection.  This allows control
                 commands to be sent to an application whose normal
                 input buffers are full of unprocessed data.

            IMPLEMENTATION:
                 The generic ERROR-REPORT() upcall described in Section
                 4.2.4.1 is a possible mechanism for informing the
                 application of the arrival of urgent data.

so it doesn't seem to require that the urgent pointer field be set to 0
if URP isn't set.