why am I seeing so much traffic?

[Larry Dieterich <macworks () dcn org>]

I am fairly new to Wireshark and I have a remote Wireshark installation running with which I am trying to solve a 
problem wherein a Helix database server periodically denies services to different and random clients.

I am administering the Wireshark machine via the WAN using a USB Ethernet connection with a static WAN IP and 
screensharing.

I do not have access to any of the other devices on the network; I shipped a box of gear with instructions for the 
connections and it was set up by the owner of the network.

The computer is a black MacBook with Wireshark Version 1.4.1 running on Darwin 10.8.0 (Mac OS 10.6.8), with libpcap 
version 1.1.1, with libz 1.2.5. The machine is listening to the built-in Ethernet port on the computer which has IPV4 
turned off. 

I have made provisions to "hub out" the server using an OvisLink 8 port 10-100 hub, which connects to the server, the 
built-in Ethernet port of the Wireshark machine, and the switch, which is a Cisco SGE2010P 48-Port Gigabit Switch 
(there are three of these switches).

I am expecting this arrangement to limit traffic that Wireshark sees. I expect to see broadcast traffic, and traffic 
directed to the server, (which has a reserved IPV4 address of 192.168.0.50).

I have two puzzles about which I am seeking advice.

first-
I am seeing a lot of traffic that is not to or from to the server. All sorts of things that shouldn't be, as far as I 
understand, passed by the switch to the server/hub/sniffer port.


Here are some sample mysteries in the packet list-
These list source, destination,         protocol and info.

169.254.73.47      192.168.0.112        TCP               58526 > 4242 [ACK] Seq=1 Ack=67 Win=66542 Len=0 TSV=595095964 
TSER=419853412
192.168.0.55       192.168.0.32 LANMAN    WPrintQGetInfo Request
192.168.0.202      192.168.0.113        TCP               afpovertcp > 50959 [ACK] Seq=1 Ack=1 Win=32760 Len=0 
TSV=293317725 TSER=993629410
192.168.0.213      192.168.0.114        AFP               FPFlushFork reply
74.125.157.148  192.168.0.121   TCP               http > 60533 [SYN, ACK] Seq=0 Ack=1 Win=5672 Len=0 MSS=1430 
SACK_PERM=1 TSV=1183932478 TSER=570689780 WS=6
69.31.132.32       192.168.0.121        TCP               http > 60515 [FIN, ACK] Seq=1 Ack=2 Win=248 Len=0 
TSV=1127482958 TSER=570689780
192.168.0.121      38.126.142.136       TCP               60523 > http [ACK] Seq=1 Ack=1 Win=66608 Len=0 TSV=570689775 
TSER=1834995510
192.168.0.121      69.31.132.57 TCP               60538 > http [ACK] Seq=1 Ack=1 Win=66608 Len=0 TSV=570689780 
TSER=3998751447
192.168.0.121     69.31.132.57        HTTP                GET 
/PointRoll/Media/Banners/Ford/927258/Ford_DriveOne_ECOBOOST_970x250_Panel_122211_pr02_BACKUP.jpg?PRAd=1560455&PRCID=1560455&PRplcmt=1529995&PRPID=1529995
 HTTP/1.1 

There is a lot more of these. This is but a sample.

My limited understanding has me wondering about this traffic. Why should my setup be seeing so much (apparently) 
non-broadcast traffic that is not intended for the server? (which is at 192.168.0.50) Shouldn't the switch isolate such 
traffic? FWIW, I *am* seeing an enormous amount of traffic intended for the server which is functioning as well as it 
was before this sniffer rig was connected.



A second part of this puzzle has arisen as I prepare this question.

I have a running capture on the Wireshark machine. When I turn off IPV6 on the MacBook, the computer advises that there 
is no connection on the Ethernet port and the packet stream stops. When IPV6 is set to automatically configure, the 
packet stream resumes. (IPV6 has been turned on with auto-configure during the capture so far)



So, I have three questions-

Is there a problem with turning off IPV4 on the Wireshark interface - should I do it differently?

Why does the packet stream stop and the network port go inactive when I turn off IPV6?

Why does my connection to the switch show me so much traffic that is not apparently broadcast, nor intended for the 
server?


I appreciate any insight or suggestions.


thanks,
Larry
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe