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

Wireshark-users: Re: [Wireshark-users] TCP / SMB Broadcast?

From: Sake Blok <sake@xxxxxxxxxx>
Date: Tue, 14 Jul 2009 17:00:28 +0200
On Tue, Jul 14, 2009 at 02:21:03AM -0600, mv652@xxxxxxxxxxxx wrote:
>
> I'd appreciate if someone could take a look at the attached capture of 11 
> packets and explain why I am able to see the TCP & SMB negotiation 
> between these two hosts. 

Could you attach a binary capture file next time, we all love using
wireshark to look at packets more than we like to look at packets in a
text editor ;-)

(it also saves bandwidth, the textfile is 18132 bytes while the binary
capture file would have been 2098 bytes)


> My capturing device has IP Address 10.0.4.26 connected on the same 
> switch, same VLAN as the two systems in the capture (10.0.4.50 & 
> 10.0.4.6).  The capturing system's nic is in promiscious mode. 
> 
> Note - I understand why I see the ARP request as it's a broadcast to the  
> network address, what I don't understand is why I see the rest of the  
> communication between the two.  I even see an ICMP reply from one host to 
> the other, but not the original request. 
>
> These systems are running on a managed switch, not a hub. 

Well, the fact that you do see traffic on your capturing port can mean
of of a few things:

A) the switch thinks the destination mac-address is behind your
port. However this is unlikely, otherwise you would have seen the whole
communication or the TCP communication would fail if the destination was
*not* behind your port.

B) the switch does not know behind which port the destination
mac-address can be found because it is not in it's table. It will then
flood the packet out on all ports and hopes to learn the whereabout of
the host. This can be caused by asymetric routing and timed out tables,
or asymetric traffic due to teaming NIC's on separate switches, etc. It
all depends on your L2 topology. You can first start by checking the
switches forwarding tables.

C) the forwarding table of the switch is overloaded and it can therefor
not store all mac-addresses and needs to flood the ones that could not
be added to the forwarding table. Look at your switch statistics for
that.

D) Don't rule out the possibility of a bug in the switch... for which
you must first check A, B and C to learn whether the switch is behaving
in an expected manner, given the topology of your network.


Cheers,
    Sake