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: Filter 2: 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: Filter 2: ======== 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 Tang edited 19 Jul '13, 09:29 |
3 Answers:
The problem here is that you have 2 UDP headers, and thus 2 UDP source ports to consider. Take frame 82, for example: When you apply a display filter of Now let's consider what happens when you apply the next filter, answered 18 Jul '13, 20:58  cmaynard ♦♦ edited 18 Jul '13, 20:58 showing 5 of 12 show 7 more comments |
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 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 |
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 ♦♦ 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 ♦♦ |
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.
Again, you have 2 UDP source ports to contend with. The second occurrence is UDP source port 59008, which is not equal to 2152.
By the way, what exactly are you trying to accomplish by all of this? i.e., which packets are you really trying to find?
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)?I am trying to filter the udp srcport inside GTP. I don't really care about one beyond GTP.
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).
OK, then maybe this filter will do the trick for you?
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:
So this is why I was asking what you really wanted to find.
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...
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:
Applying it yields 47 frames of the 9999 in your test.pcap capture file.
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.
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:
(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 -> OKAt this point, all the UDP filters should be easier to work with because you will only have a single UDP header now.