Ethereal-users: Re: [Ethereal-users] Source/Destination Display?

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

From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Sun, 22 Oct 2000 01:55:45 -0700
On Sun, Oct 22, 2000 at 06:04:58PM +1000, doug rickard wrote:
> I have a test coax LAN with 1 x Linux box with Samba (name=Linux), 1 x WinME
> box (name=PC4),
> 1 x Win95A (name=Laptop), 1 x Win 3.11 (name=PC3), 2 x DOS + MS Add-on for
> DOS
> (names=PC1 and EXE1).

	...

> In most cases the display is like this -
> No Time       Source                  Destination         Protocol     Info
> ------------------------------------------------------------------
>   1 0.000000 02:60:8c:0a:3c:02 00:00:eb:c0:91:ea LLC I.(N)=30,N(S)=42,DSAP
> NetBIOS Individual, SSAP, NetBIOS
> 301 80.227990 00:00:e8:c0:91:ea 02:60:8c:0a:3c:d2 NetBIOS Session Alive
> 
> 
> As you can see, only the Ethernet addresses are displayed for Source and
> Destination.

That's because Ethereal doesn't know the names corresponding to those
Ethernet addresses.

> However about once a day and after several hundred tries (yes, I am
> persistent) the display changes
> and the Source and Destination are displayed as the actual machine names,
> e.g -
> 
> No   Time         Source     Destination Protocol  Info
> ------------------------------------------------------
> 206 59.278546 LAPTOP LINUX TCP 1044>nbsession[SYN]Seq1221868490Ack......

That's not NetBIOS Frame, that's NetBIOS-over-TCP.  (Trust me on this
one - it wouldn't say "TCP" if it weren't NetBIOS-over-TCP, and
"nbsession" is port 139, used for the NetBIOS Session Service, which is
what most SMB traffic runs over.

Given the "LINUX" in there, I'm not surprised - some company said they'd
do an open-source NetBIOS Frame implementation for Linux, and they may
even have come out with it, but I suspect most Linux systems don't have
it, and I don't know whether any version of Samba (which is probably
what you're using for SMB support on Linux) supports it.

Given that it's NetBIOS-over-TCP, there are IP addresses being used;
Ethereal will try to convert them to names, unless it's been told not to
(e.g., with the "-n" command-line flag, or with the "Enable name
resolution" checkbox in the "Display Options" dialog box).  It appears
to have succeeded.

> 244 65.759964 LAPTOP LINUX SMB TRANS2_FIND_NEXT2 Request
> 245 65.767470 LINUX LAPTOP SMB TRANS2_FIND_NEXT2 Response

I'll bet those are also NetBIOS-over-TCP.  Look at the protocol tree for
them, and you'll probably find IP and TCP and NetBIOS Session Service in
there.

> 302 85.138240 PC3     PC4        LLC    etc.
> 405 100.794385 PC3   LINUX   LLC

I'll bet that Ethereal saw ARP requests or replies for the machines in
question, and had previously seen IP packets for them.  The IP packet
caused it to try to look up the IP address, giving it the host name for
that IP address; the ARP packets caused it to conclude that the IP
address in the ARP packet corresponded to the Ethernet address in the
ARP packet, and therefore that the host name corresponding to the IP
address in question also corresponded to the Ethernet address in
question.

> plus all combinations of the names of the non-DOS machines.
> 
> Now the translated names are displayed only for the Linux, Win98ME, Win95A,
> and Win3.11 machines.
> Only the Ethernet address are still displayed for the boxes with DOS+MS Add
> Ons for DOS.

The DOS machines are probably not using NetBIOS-over-TCP; there might be
NetBIOS-over-TCP implementations for it, but they're probably add-ons. 
As such, they probably never transmit IP packets - they may not even
have IP addresses - so Ethereal can't use an IP-address-to-host-name
lookup to find their host name.

Your Linux machines probably *only* do NetBIOS-over-TCP; Windows 95 and
98 come standard with NetBIOS-over-TCP support, and you probably have it
on your Windows 3.11 (is that Windows for Workgroups?) system.  In any
case, they probably send out enough IP packets to cause Ethereal to look
up their host name.

> I can capture the displays in a file, but when I read them back all Sources
> and Destinations are in the
> Ethernet format, and not in the translated format, so it is no use trying to
> send you the capture files..

It is *extremely* unlikely that Ethereal would display an Ethernet
address for a TCP packet; you would have to have configured the Source
and Destination columns to display something other than the default
values to get that.  (The default value is "show the network-layer
address - e.g., IP - if there is one, otherwise show the link-layer
address".)  The only alternative would be a bug that overwrote the data
structure that Ethereal uses to know what to display in the columns, and
overwrote it to say "display only link-layer addresses", without doing
anything else visible, which is quite unlikely.

Are you *absolutely certain* it shows an Ethernet address, not an IP
address?  If so, then either you've set the Source and Destination
columns to always display link-layer addresses (extremely unlikely,
given that it was showing host names in one example), or there's a bug,
in which case we'd need the capture to figure out what's going on.

> Once in the name translation mode, Ethereal continues to translate Source
> and Destination until the next
> time I shut Ethereal down and restart it,

Ethereal doesn't forget host names from capture to capture, within a
given Ethereal session; it only forgets when it exits.

> at which time the display reverts to the Ethernet format.

As per the above, I suspect what it reverts to is a numeric format -
showing *IP* addresses, not *Ethernet* addresses, for IP packets.

> It seems to be completely random as to which form of display that Ethereal
> will use.

If you have never seen any IP or ARP traffic for the machines in the
capture - e.g., you have only NetBIOS Frame traffic for them - Ethereal
won't know what the names of the hosts are.

If, however, you see IP traffic for a host, so that the IP address gets
translated to a host name, all subsequent IP packets in the capture will
be able to show the host name for that IP address.  If, after the first
IP packet from or to the host, there's an ARP request or reply from it,
or an ARP reply giving its IP and Ethernet address, all subsequent
non-IP packets will be able to show the host name for that Ethernet
address.

> At the moment we are only interested in the tracking of NetBIOS packets. We
> use NetBIOS for inter-machine communication from the DOS boxes to the
> Windows boxes.

...in which case, unless the DOS boxes happen to send out IP and ARP
packets in the fashion described, Ethereal has, for better or worse, no
way of finding out the host names of the DOS boxes.  (Has Ethereal
*ever* shown their host names?  I strongly suspect not, unless they have
TCP/IP installed on them.)

The Windows boxes probably *do* have TCP/IP on them, and are probably
sending and receiving IP packets (and thus are probably doing some ARP),
so, depending on what IP traffic happens to go onto the network to or
from them, you might see their host names.

> QUESTION:-
> =========
> Can anyone please explain the random functionality of Ethereal this way,

See above.

> or can anyone please tell me how
> we can make Ethereal come up in the translation mode eevery time?

On whatever drive is the "current drive" for Ethereal when you run it,
create a file "\etc\ethers", which contains a list of the form

	<ethernet address>	<host name>

where "<ethernet address>" is the Ethernet address of a host and <host
name> is its host name - put white space between them.  The Ethernet
addresses should be in the form XX:XX:XX:XX:XX:XX.

That *might* make it work, although I can't guarantee that it'll work.