Wireshark · Wireshark-users: Re: [Wireshark-users] Multicast problem

["Robert D. Scott" <robert@xxxxxxx>]

I am not sure the switch will hairpin the multicast and send it out the same
interface it came in on. Even if it receives a join on the interface. Never
tried that in the lab, but in general terms hairpinning is not supported.

Robert D. Scott                 Robert@xxxxxxx
Senior Network Engineer         352-273-0113 Phone
CNS - Network Services          352-392-2061 CNS Receptionist
University of Florida           352-392-9440 FAX
Florida Lambda Rail             352-294-3571 FLR NOC
Gainesville, FL  32611          321-663-0421 Cell


-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Lars Lars
Sent: Thursday, October 30, 2008 4:43 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Multicast problem

Thank you for the quick response.

The code that configures the nic and handling receiving multicast is the
same for server and clients. So it does not make sense for the server to
fail and the clients to work. Also, the current code has worked fine for
several years. The case being mentioned is the exception.

Will look into promiscuous mode tomorrow morning.

Cheers

> Date: Thu, 30 Oct 2008 21:24:21 +0100
> From: jaap.keuter@xxxxxxxxx
> To: wireshark-users@xxxxxxxxxxxxx
> Subject: Re: [Wireshark-users] Multicast problem
> 
> Hi,
> 
> That's called promiscuous mode. In that mode the MAC filter is 
> disabled letting all packets come through to the driver layer, where 
> the capture stub can get them. You can unselect this mode when you 
> start a capture and see what your server does then.
> 
> If I recall correctly it's a socket option in your application to get 
> your own multicasts back. Otherwise make sure the application joins 
> the multicast group it sends on, so to get the MAC filter in the NIC setup
to receive multicast.
> 
> Thanx,
> Jaap
> 
> Lars Lars wrote:
> > Thank you for the response.
> > 
> > It sounds reasonable that the server nic shortcuts the multicast. Is 
> > there a way to verifying this shortcut since it does not appear to 
> > be valid in at least one instance.
> > 
> > After more debugging it appears that when wireshark (or windump) 
> > listens to the server nic this affect the nic and triggers the 
> > server application to receive the multicasts. By stoping wireshark 
> > to listen to the nic, then the server application also stops 
> > receiving the multicasts. What possible changes to the nic does 
> > wireshark perform when listening to the traffic and could any of 
> > them explain the problems we are having.
> > 
> > Appreciate any input.
> > 
> > 
> > 
> > --------------------------------------------------------------------
> > ----
> > From: robert@xxxxxxx
> > To: wireshark-users@xxxxxxxxxxxxx
> > Date: Thu, 30 Oct 2008 12:54:14 -0400
> > Subject: Re: [Wireshark-users] Multicast problem
> > 
> > Your switch may allow you to span the traffic either in, out, or both. 
> > Both is default on a Cisco switch if you do not specify. This 
> > assumes you have access to the network, and Wireshark is running on 
> > an independent platform. The interface driver on the server NIC may 
> > shortcut the multicast before it has to get on the wire and come back.
> > 
> > 
> > 
> > Robert D. Scott Robert@xxxxxxx <mailto:Robert@xxxxxxx>
> > 
> > Senior Network Engineer 352-273-0113 Phone
> > 
> > CNS - Network Services 352-392-2061 CNS Receptionist
> > 
> > University of Florida 352-392-9440 FAX
> > 
> > Florida Lambda Rail 352-294-3571 FLR NOC
> > 
> > Gainesville, FL 32611 321-663-0421 Cell
> > 
> > 
> > 
> > *From:* wireshark-users-bounces@xxxxxxxxxxxxx
> > [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] *On Behalf Of *Lars 
> > Lars
> > *Sent:* Thursday, October 30, 2008 12:22 PM
> > *To:* wireshark-users@xxxxxxxxxxxxx
> > *Subject:* [Wireshark-users] Multicast problem
> > 
> > 
> > 
> > 
> > Hello
> > 
> > I'm new to this mailinglist and I'm hoping to get some help on a 
> > specific problem I'm trying to debug.
> > 
> > An server application is setup to send udp multicast message every 
> > second. There are a number clients, including the server itself, 
> > that listen for this messages. This has worked fine for several 
> > years. Then this week I found an installation where all clients 
> > received udp multicast message except the server. So the multicast 
> > is not echo'ed back to the itself. (There is no firewall on any of 
> > the computers)
> > 
> > By starting Wireshark 1.0.4 I'm able to monitor the multicast 
> > messages\packages
> > Source: 172.21.1.1
> > Destionation : 230.21.1.200
> > Protocol: UDP
> > Source port:14800
> > Destionation port: 14800
> > 
> > What I'm not able to understand is how can I debug this problem 
> > using wireshark? How can I figure out if a particular udp multicast 
> > packet is actually both sent and received by the same computer? Does 
> > this application enable me to do so? Can someone please explain how 
> > I could go about doing so, or recommend any other utility that might aid
me.
> > 
> > Thanks for your time. Appreciate any input.
> > 
> 
> 
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> https://wireshark.org/mailman/listinfo/wireshark-users


________________________________

Se bildegalleri på MSN Style. Kate Moss eller Sienna Miller: Hvilken
kjendis-stil passer deg?
<http://style.no.msn.com/gallery/21074/73014?ocid=30032>