Wireshark · Wireshark-users: Re: [Wireshark-users] How to filter for gsm_sms TP-Destination-Address

[Emre UZUNCA <euzunca@xxxxxxxxx>]

Hi Abrik,

 

Filter is working. Thank you very much.

BR,

Emre

---

From: "wireshark-users-request@xxxxxxxxxxxxx" <wireshark-users-request@xxxxxxxxxxxxx>
To: wireshark-users@xxxxxxxxxxxxx
Sent: Friday, October 31, 2008 3:30:57 PM
Subject: Wireshark-users Digest, Vol 29, Issue 58

Send Wireshark-users mailing list submissions to
    wireshark-users@xxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
    https://wireshark.org/mailman/listinfo/wireshark-users
or, via email, send a message with subject or body 'help' to
    wireshark-users-request@xxxxxxxxxxxxx

You can reach the person managing the list at
    wireshark-users-owner@xxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wireshark-users digest..."


Today's Topics:

  1. Re: Multicast problem (Robert D. Scott)
  2. Re: Multicast problem (Lars Lars)
  3. Re: Multicast problem (Jim Young)


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

Message: 1
Date: Thu, 30 Oct 2008 17:53:30 -0400
From: "Robert D. Scott" <robert@xxxxxxx>
Subject: Re: [Wireshark-users] Multicast problem
To: "'Community support list for Wireshark'"
    <wireshark-users@xxxxxxxxxxxxx>
Message-ID: <002701c93ad9$f2523d80$d6f6b880$@edu>
Content-Type: text/plain;    charset="iso-8859-1"

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>



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

Message: 2
Date: Fri, 31 Oct 2008 11:32:21 +0100
From: Lars Lars <laasunde@xxxxxxxxxxx>
Subject: Re: [Wireshark-users] Multicast problem
To: Community support list for Wireshark
    <wireshark-users@xxxxxxxxxxxxx>
Message-ID: <COL110-W40979098C452A93DD40B12CA200@xxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

Just a quick update.

Here are some observations:

Running server application and running wireshark but not listening to any adapter - no multicasts are received on the server.

Running server application and just opening Capture -> Interface... to show "Wireshark. Capture Interfaces" - this triggers the server application to receive multicast packets. I'm only showing the dialog window - not using it. By closing the window the server stops receiving the multicasts.

Running server application and opening Capture -> Options... in wireshark select correct adapter and disabled promiscues mode - click Start and then the server starts to receive multicast messages. By stoping the capture then the server stops receiving multicasts. Tried enabling and disabling various settings within Wireshark: Capture options dialog window but it does not seem to affect the behaviour - it seems, regardless of mode or settings by listening to the adapter the server receives the multicasts.

Can anyone shed some light on what wireshark does to 'cause' the behaviour I am describing.Thank you



> From: robert@xxxxxxx> To: wireshark-users@xxxxxxxxxxxxx> Date: Thu, 30 Oct 2008 17:53:30 -0400> Subject: Re: [Wireshark-users] Multicast problem> > 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 a
nd 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 rece
ive 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:2
2 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> > > _______________________________________________> Wireshark-users mailing list> Wireshark-users@xxxxxxxxxxxxx> https://wireshark.org/mailman/listinfo/wireshark-users
_________________________________________________________________
Med MSN p? mobilen holder du deg oppdatert.
http://info.mobile.no.msn.com/pc/default.aspx?ocid=30032
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.wireshark.org/lists/wireshark-users/attachments/20081031/6a268c47/attachment.htm

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

Message: 3
Date: Fri, 31 Oct 2008 09:10:35 -0400
From: "Jim Young" <SYSJHY@xxxxxxxxxxxxxxx>
Subject: Re: [Wireshark-users] Multicast problem
To: "Community support list for Wireshark"
    <wireshark-users@xxxxxxxxxxxxx>
Message-ID: <490ACB8B020000870008AC8F@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII

Hello Lars,

>>> Lars Lars <laasunde@xxxxxxxxxxx> 10/31/08 6:32 AM >>>
> Here are some observations:
> Running server application and running wireshark but
> not listening to any adapter - no multicasts are received
> on the server.
>
> Running server application and just opening
> Capture -> Interface... to show "Wireshark. Capture Interfaces"
> - this triggers the server application to receive multicast
> packets. I'm only showing the dialog window - not using it.
> By closing the window the server stops receiving the
> multicasts.
> 
> Running server application and opening Capture -> Options...
> in wireshark select correct adapter and disabled promiscues
> mode - click Start and then the server starts to receive
> multicast messages. By stoping the capture then the
> server stops receiving multicasts. Tried enabling and
> disabling various settings within Wireshark: Capture
> options dialog window but it does not seem to affect
> the behaviour - it seems, regardless of mode or
> settings by listening to the adapter the server
> receives the multicasts.
> 
> Can anyone shed some light on what wireshark
> does to 'cause' the behaviour I am describing.Thank you

A few questions:

What platform is this multicast server application
running on?  (Windows (XP, Vista), Linux, etc)?

What version of Wireshark are you using?

Do you have any firewall installed on this system? 

What type of multicast server application is this?

When your server actually subscribes to the multicast
group 230.21.1.200 it should send an IGMP message
indicating that fact.  Do you see IGMP packets
egressing from your server machine?

If your machine is sending IGMP packets, what do
these IGMP packets contain?

If your system is NOT sending any packet, then your
system (for some reason) is NOT advertising its desire
to subscribe to the multicast group 230.21.1.200.

Is this the ONLY system that produces (sends) data for
this multicast group (230.21.1.200:14800)?

If not, does this same server system receive multicast
packets from other systems that are sending on this
group (230.21.1.200:14800)?

I am assuming you have multicast aware networking
equipment? 

If your networking equipment is multicast aware,
and you (or your networking group) have access
to the management interface of the switch, you
should be able to query its multicast forwarding
tables to determine if your machine has subscribed
to the multicast 230.21.1.200  group or not.

I also agree with the earlier reply to this thread regarding
hair-pinning.  It is extremely unlikely that the switch
equipment would locally (Layer 2) send a multicast packet
back to the same switch port that it originated on. 

But if the multicast packet is ultimately forwarded to a
rendevous point then perhaps a copy of your multicast
packet could ultimately be sent back to the same switch
port that it originated on. 

Does the switch port that your server is connected to
have multiple vlans exposed on it?

Answers to the above might help narrow down
possibilities.

Best regards,

Jim Y.




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

_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-users


End of Wireshark-users Digest, Vol 29, Issue 58
***********************************************