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.