> I was very confused because I thought tethereal was following the same
> options as tcpdump or windump, in which case then the -n option would
> keep it from doing this port name translation.
Tethereal *is* using the same options; "-n" *does* suppress the
translation of port numbers into protocol names.
*However*, it does *NOT* suppress the *dissection* of protocols with
given port numbers; that's the "this"
> But I can't figure how to stop it from doing this, even with the -n option:
>
> 2001-10-16 18:41:02.4086 x -> y NBSS Session request
> 2001-10-16 18:41:02.4091 x -> y NBSS Positive session response
> 2001-10-16 18:41:02.4095 x -> y SMB SMBnegprot Request
to which you were referring. There are no port numbers *or* port names
in that display; "NBSS" and "SMB" are *protocol* names, even though NBSS
happens to have a particular port assigned to it (139).
Tcpdump/WinDump behave the same way; even if the "-n" flag is specified,
they will still dissect packets beyond the TCP layer, if they know the
protocol and if there's enough data captured in the packet for it to
dissect.
In at least one capture with of SMB-over-NBT traffic, when tcpdump is
run with "-n", it does *NOT* say anything about TCP or UDP for those
packets. It *does* report the port number.
If you want Tethereal to report the port number, you currently have to
add "Source port" and "Destination port" columns to its output, using
the "Columns" preference in the dialog box popped up by the
"Preferences" item in the "Edit" menu. You have to add the column *and*
save preferences with the "Save" button, and then run Tethereal.
Those port numbers will be reported as numbers if you've specified the
"-n" flag. However, there will be no indication of whether the packet
is TCP or UDP, *just as there isn't any such indication with tcpdump*.