["Mike Kenning" <mkenning@xxxxxxxx>]

Guy,

It sounds like you have the resolution method sorted out (when it works),
but I believe I am seeing a bug in resolving addresses in the Win32 version
of Ethereal 0.8.12 and it sounds like this is perhaps effecting Doug too.

Nearly every time I use Ethereal it is not doing any IP address to DNS name
resolution for Source and Destination addresses, even though I have the
"Enable name resolution" option on (both for Capture and Display).
Sometimes it will resolve an address or two by learning from a DNS response
that goes past in the trace, but it never issues its own DNS queries.

However, just a couple of times it actually has worked and resolves IP to
DNS names by issuing it's own DNS queries for each new IP address that
appears in the trace.  I'm not sure what triggers it to start working, but
one time it was after I ran the text-based version Tethereal first.  By the
way, Tethereal 0.8.12 always seems to work for me by resolving IP to names
via it's own DNS queries.  I'm sure this is what Ethereal is supposed to be
doing also, but it seems to be broken.

I'm a new Ethereal user (running on Win98) and I'm very impressed with it.
If any other details would help in tracking this bug down, please let me
know.

p.s. Once it resolves a DNS name to an IP address it also uses that name in
place of the Ethernet address on NetBEUI (NetBIOS frame) packets from the
same host, which is probably what Doug saw the couple of times it worked for
him.

p.p.s.  Sorry that I can't thread this message properly, I just joined the
mail list so I've had to copy your original message from the archive.

Mike K.



To: doug rickard <rickard@xxxxxxxxxxxxx>
Subject: Re: [Ethereal-users] Source/Destination Display?
From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Sun, 22 Oct 2000 01:55:45 -0700
Cc: ethereal-users@xxxxxxxxxxxx
Delivered-To: ethereal-users@xxxxxxxxxxxx
In-Reply-To: <000b01c03bfe$dd408920$6400a8c0@laptop>; from
rickard@xxxxxxxxxxxxx on Sun, Oct 22, 2000 at 06:04:58PM +1000
List-Archive: http://www.ethereal.com/pipermail/ethereal-users/
List-Help: <mailto:ethereal-users-request@xxxxxxxxxxxx?subject=help>
List-Id: General user support <ethereal-users.ethereal.com>
List-Post: <mailto:ethereal-users@xxxxxxxxxxxx>
List-Subscribe: <http://www.ethereal.com/mailman/listinfo/ethereal-users>,
<mailto:ethereal-users-request@xxxxxxxxxxxx?subject=subscribe>
List-Unsubscribe: <http://www.ethereal.com/mailman/listinfo/ethereal-users>,
<mailto:ethereal-users-request@xxxxxxxxxxxx?subject=unsubscribe>
References: <OF6F67E97F.68B46DB6-ON8625697D.0050C38D@xxxxxxxxxx>
<005901c03a2d$9c5f3b40$6400a8c0@laptop>
<20001019205807.A352@xxxxxxxxxxxxxxxxxxxxxx>
<000b01c03bfe$dd408920$6400a8c0@laptop>
Sender: ethereal-users-admin@xxxxxxxxxxxx
User-Agent: Mutt/1.2.4i

----------------------------------------------------------------------------
----

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.