This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

UDP port range filter not working

0

I am trying to filter the traffic by udp port and find out that range filter is not working.

For example, I have two filters.

Filter 1: udp.port == 48777

Filter 2: (udp.port > 48776) and (udp.port < 48778)

In my point of view, these two filters should give be same results. But in fact filter 2 will give me all udp traffic, regardless of port number. If I just need a small range of ports, I can use equal to do the same job. But it becomes impossible if I am trying to look at a large range of ports.

Any ideas?

========

update

I changed the filter into the following and still getting different results. I think both of them should give me udp traffic with source port 48777 only.

Filter 1: udp.srcport == 48777

Filter 2: (udp.srcport > 48776) and (udp.srcport < 48778)

========

update (7/19/2013)

Part of capture is uploaded at here(http://www.cloudshark.org/captures/d9353f10683c)

The problem is there are two UDP headers in the capture. Thus there are two source ports to be considered while filtered. Thanks @cmaynard.

Now the question is, how to just filter the UDP header inside GTP and disregard the port of UDP header beyond GTP?

UDP inside GTP is GTP-U and this is the one I am looking into. The other one is for GTP-C and I don't really care about it.

asked 18 Jul '13, 15:22

Jay%20Tang's gravatar image

Jay Tang
16115
accept rate: 0%

edited 19 Jul '13, 09:29


3 Answers:

3

The problem here is that you have 2 UDP headers, and thus 2 UDP source ports to consider. Take frame 82, for example:

Frame 82: 140 bytes on wire (1120 bits), 140 bytes captured (1120 bits)
Ethernet II, Src: Cisco-Li_8c:cf:7a (00:16:b6:8c:cf:7a), Dst: Azurewav_ce:5d:f9 (00:25:d3:ce:5d:f9)
Internet Protocol Version 4, Src: 212.129.65.81 (212.129.65.81), Dst: 212.129.65.23 (212.129.65.23)
User Datagram Protocol, Src Port: gtp-user (2152), Dst Port: gtp-user (2152)
GPRS Tunneling Protocol
T-PDU Data 86 bytes
Internet Protocol Version 4, Src: 70.48.208.171 (70.48.208.171), Dst: 192.168.111.20 (192.168.111.20)
User Datagram Protocol, Src Port: 59008 (59008), Dst Port: 63529 (63529)
Data (58 bytes)

When you apply a display filter of udp.srcport == 48777, Wireshark is looking for an exact match on any UDP source port field matching that filter. Since neither the first UDP source port occurrence of 2152 nor the second UDP source port occurrence of 59008 matches that filter, this frame is not displayed.

Now let's consider what happens when you apply the next filter, (udp.srcport > 48776) and (udp.srcport < 48778): Wireshark determines that the second UDP source port of 59008 satisfies the first constraint and the first UDP source port of 2152 satisfies the second constraint, so this frame is determined to match the filter and is displayed.

answered 18 Jul '13, 20:58

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142
accept rate: 20%

edited 18 Jul '13, 20:58

Thanks for the answer. Now I am using (udp.srcport > 48776) and (udp.srcport < 48778) and (udp.srcport != 2152) but it cannot filter out the gtp port.

(18 Jul '13, 21:21) Jay Tang

Again, you have 2 UDP source ports to contend with. The second occurrence is UDP source port 59008, which is not equal to 2152.

(18 Jul '13, 21:38) cmaynard ♦♦

By the way, what exactly are you trying to accomplish by all of this? i.e., which packets are you really trying to find?

(18 Jul '13, 21:47) cmaynard ♦♦

Also, you probably noticed that the filter you tried caused the background to display in yellow. Maybe what you wanted was (udp.srcport > 48776) and (udp.srcport < 48778) and !(udp.srcport == 2152)?

(18 Jul '13, 21:50) cmaynard ♦♦

I am trying to filter the udp srcport inside GTP. I don't really care about one beyond GTP.

(19 Jul '13, 08:01) Jay Tang

For example I want to see peer-to-peer traffic so I filter udp srcport from 49152 to 65535. But with another UDP srcport 2152, which is for GTP control panel, I will get all UDP traffic if I just do (udp.srcport > 49152) and (udp.srcport < 65535).

(19 Jul '13, 08:14) Jay Tang

OK, then maybe this filter will do the trick for you?

udp and !(udp.srcport eq 2152) and !(udp.dstport eq 2152)
(19 Jul '13, 08:25) cmaynard ♦♦

Or you could dispense with udp port matching altogether if you use another filter, which is really what you're after. For example, if I apply this next filter to the same trace file you provided, the same 2 packets are shown:

(gtp.message == 0x10) || (gtp.message == 0x11)

So this is why I was asking what you really wanted to find.

(19 Jul '13, 08:37) cmaynard ♦♦

I tried

(udp.srcport > 48776) and (udp.srcport < 48778) and !(udp.srcport eq 2152)

and there is no match for this filter. Looks like no packet with udp source port 2152 can get through this filter...

(19 Jul '13, 08:47) Jay Tang

Hmm, when you say you want to see peer-to-peer traffic, are you referring to the bittorrent traffic? If so, you could just use a display filter of:

bittorrent

Applying it yields 47 frames of the 9999 in your test.pcap capture file.

(19 Jul '13, 08:54) cmaynard ♦♦

Well I just take peer-to-peer as an example. I also need to look into other kind of traffic, and I will need different port ranges. But all of the traffic I am looking into is encapsulated by GTP so there will always be two udp headers.

(19 Jul '13, 09:01) Jay Tang
1

Well, maybe you would be better off stripping off the outer headers so you can avoid dealing with multiple UDP headers? To do this, you can use editcap, something like:

editcap -T user0 -F libpcap -C 42 in.pcap out.pcap

(Note: 42 is the number of bytes to remove from the beginning of each frame and comprises 14 bytes for the Ethernet header + 20 bytes for the outer IP header + 8 bytes for the outer UDP header.)

When you launch Wireshark, your packets won't be dissected correctly (yet), but you should notice an indication in the packet details pane, "User encapsulation not handled: DLT=147, check your Preferences->Protocols->DLT_USER" (assuming of course that you don't already have a protocol assigned to this DLT). Now you need to assign DLT 147 to gtp via: Edit -> Preferences -> Protocols -> DLT_USER -> Encapsulations Table: Edit -> New -> DLT: User 0 (DLT=147) -> Payload protocol: gtp -> OK -> OK -> OK

At this point, all the UDP filters should be easier to work with because you will only have a single UDP header now.

(19 Jul '13, 09:47) cmaynard ♦♦
showing 5 of 12 show 7 more comments

1

You encountered a pretty common misunderstanding :) Filter 1 requires to have UDP source port OR UDP destination port within a single packet to match exaclty port number 48777.

Filter 2 states that you must have ONE UDP port greater than 48776 AND ONE UDP port smaller than 48778 which is independent of being source and/or destination port -> so UDP Port 22 to UDP Port 50000 will match filter 2 since you match each condition, one with udp.srcport and the other with udp.dstport

answered 18 Jul '13, 15:27

Landi's gravatar image

Landi
2.3k51442
accept rate: 28%

Thanks for the answer.

Let's put it this way.

Filter 1: udp.srcport == 48777

Filter 2: (udp.srcport > 48776) and (udp.srcport < 48778)

And I am still getting different results. So how should I write the filter that it can give me udp traffic with certain source or destination range?

(18 Jul '13, 15:34) Jay Tang

Then you have to specify the ranges for source AND destination port e.g. (udp.srcport > 48776 and udp.srcport < 48778) or (udp.dstport > 48776 and udp.dstport < 48778)

meaning that either udp source or destination port will match your desired range

BTW: Your recent commented filters should do exactly the same regarding source port only filtering

(18 Jul '13, 15:47) Landi

But the interesting thing is this filter, (udp.srcport > 48776) and (udp.srcport < 48778), is not doing its job...

I am using the latest wireshark 1.10.0 so I don't know what is wrong here. People are filtering port ranges everyday so there should not be a bug here.

Actually what I need to do is using tshark to generate the filtered stats. I found it not right so then tried to verify it in wireshark.

(18 Jul '13, 16:00) Jay Tang

Well that's strange - could you upload the trace (or parts of it) to www.cloudshark.org so that we can verify if maybe this is a local problem with your installation and do some more troubleshooting?

(18 Jul '13, 16:12) Landi

Why the link will be considered as spam? OK, just the capture ID: d9353f10683c

Its basically BitTorrent traffic encapsulated by GTP. So it will look like cellular traffic.

(18 Jul '13, 17:42) Jay Tang

0

The problem is that each UDP packet has two port numbers, source and destination. Your filter checks if any of both is greater than 48776 and less than 48778 - but unless both are 48777 it will always allow the packet through.

What you need to do is to specify whether you mean source or destination port (e.g. "(udp.srcport > 48776) and (udp.srcport < 48778)".

answered 18 Jul '13, 15:27

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

edited 18 Jul '13, 15:29

Why the link will be considered as spam?

That in itself is a good question to ask. It should work.

Anyway, here's the link: http://cloudshark.org/captures/d9353f10683c

(18 Jul '13, 20:37) cmaynard ♦♦