How do I filter using a range IPv4 addresses?

IPrange

asked 2018-03-15 14:35:19 +0000

frubin
1 ●1 ●1 ●1

updated 2018-03-15 15:48:23 +0000

cmaynard

11115 ●11 ●317 ●165 https://www.igt.com/

I am attempting to a track data from a range of IP addresses for servers in a cluster and cannot seem to get the verbiage correct to achieve this. I have tried:

ip.addr == 153.11.105.34/38 (expression is green, but nothing returns)
ip.address == 153.11.105.34 or 153.11.105.35 (expression turn red)
ip contains 153.11.105.34/38 (expression is green, but nothing shows as being captured but when I do ip.addr ==any of individual address in that range, it shows packets)
host 153.11.105.34 or host 153.11.105.35 (expression turns red)
ip host 153.11.105.34 (expression turns red)
net 153.11.105.34

This is being attempted on 2.4.4

Thank you

edit retag flag offensive close merge delete

Comments

Are you certain that ip.addr == 153.11.105.34/38 (with 38 after the /, not some value between 1 and 32) doesn't turn the display filter box red?

Guy Harris ( 2018-03-15 23:28:33 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2018-03-15 16:03:01 +0000

cmaynard

11115 ●11 ●317 ●165 https://www.igt.com/

I'll address each one in turn:

ip.addr == 153.11.105.34/38 This is invalid because the maximum number of bits is /32. You probably want ip.addr == 153.11.105.34/31. (Ideally, the Wireshark display filter validation could be improved to detect this and turn the expression red instead of green.)
ip.address == 153.11.105.34 or 153.11.105.35 This is invalid because there is no field called "ip.address" and you need to specify the field name for the second IP address too. You probably want ip.addr == 153.11.105.34 or ip.addr == 153.11.105.35
ip contains 153.11.105.34/38 Again, /38 is invalid, but also the contains operator does not work with IP addresses. Refer to the wireshark-filter man page for more information.

As the red color indicates, the following are not valid Wireshark display filter syntax. They are pcap-filter capture filter syntax and can't be used in this context. Refer to the pcap-filter man page for more information.

host 153.11.105.34 or host 153.11.105.35
ip host 153.11.105.34
net 153.11.105.34

edit flag offensive delete link

Comments

Oops, grahamb beat me to the answer while I was typing/linking/formatting.

cmaynard ( 2018-03-15 16:03:55 +0000 )edit

This is invalid

...and should be reported as an error, just as libpcap does:

$ tcpdump -i en0 -d net 153.11.105.34/38
tcpdump: mask length must be <= 32

At least in the master branch, it does get reported:

$ dftest 'ip.addr == 153.11.105.34/38'
Filter: "ip.addr == 153.11.105.34/38"
dftest: Netmask bits in a CIDR IPv4 address should be <= 32, not 38

but if a green background is displayed with that filter, that's a bug.

Guy Harris ( 2018-03-15 22:12:59 +0000 )edit

Indeed, a /38 is indicated as being invalid even with version 2.4.5, the specific message being, "Invalid filter: Netmask bits in a CIDR IPv4 address should be <= 32, not 38", just as described.

But @frubin indicated version 2.4.4 was in use and that the filter was "green", so either that can't be the case - a different version was in use or the filter wasn't "green" - or the display filter syntax checking was improved some time between those 2 releases, although I don't find any mention of that in the release notes. Or something else?

EDIT: And annoyingly, dftest still isn't included in the Windows installer ... at least not for 2.4.x.

cmaynard ( 2018-03-15 22:48:30 +0000 )edit

The check for that issue appears to be in the current 2.4 branch and, in fact, 2.4.5 does turn the display filter bar in the main window and in the "Capture Options" dialog red for "ip.addr == 153.11.105.34/38", at least in the macOS version.

Guy Harris ( 2018-03-15 23:25:55 +0000 )edit

...and that check was added back in 2001, so it's been there for a long while. In fact, the check was part of the initial checkin of code to support CIDR netmasks in display filters, so it's been there for as long as it's been possible to say "/NN" in tests of IP addresses in display filters.

Guy Harris ( 2018-03-15 23:27:32 +0000 )edit

add a comment

answered 2018-03-15 15:52:40 +0000

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23835 ●4 ●976 ●227 https://www.wireshark.org

updated 2018-03-15 16:18:07 +0000

You seem to be confused by the differing syntaxes of capture and display filters.

Capture filter syntax is explained here, and allows use of the following keywords to identify ip addresses:

host- identifies a particular host, if a name, the resolved ip(s) are all used, if an ip, then that is used.
net - identifies a network of addresses, usually in CIDR notation, e.g. 1.2.3.0/24

Display syntax is explained here and uses a form of ip.xxx == 1.2.3.4, e.g:

ip.addr == 1.2.3.4 or ip.addr == myhost filters any packets to or from the ip address or host name
ip.addr == 1.2.3.0/24 filters any packets in the 1.2.3.4.0 class c subnet.

Assuming you're trying to create a display filter for address in the range 153.11.105.34 - 38 you can either use:

individual address: ip.addr == 153.11.105.34 or ip.addr == 153.11.105.35 or ip.addr == 153.11.105.36 or ip.addr == 153.11.105.37 or ip.addr == 153.11.105.38
a subnet, unfortunately your range of addresses doesn't map neatly so you'll have to use a slightly bigger subnet, e.g. ip.addr == 153.11.105.32/29 which will permit address in the range 153.11.105.32 - 153.11.105.39.

You could also combine a mix of explicit addresses and a smaller subnets:

ip.addr == 153.11.105.34/31 or ip.addr == 153.11.105.36/31 or ip.addr == 153.11.105.38

edit flag offensive delete link

Comments

Thank you very much, we just installed it 3 days ago and I have been reading a lot about this software since then, but I was unable to determine what the proper syntax that would be needed. Thank you!

frubin ( 2018-03-15 15:57:38 +0000 )edit

If an answer has solved your issue, please accept it to assist others with the same question by clicking the checkmark icon by the side of the answer.

grahamb ( 2018-03-15 16:19:19 +0000 )edit

add a comment