~ /wireshark-lab /capture-and-filters
Lab 01 · Capture & filters

Capture everything. Display what matters.

A capture records everything on the interface. A display filter hides every packet that doesn't match, without changing the capture. All six filters below were applied to the same capture file.

wireshark_lab_http.pcapng23,780 framesMy IP · 192.168.1.229

The six filters#

# Filter Shows
1 http Only HTTP: the HEAD / request and the 200 OK reply
2 ip.addr == 192.168.1.229 Every IPv4 packet to or from my Mac
3 ip.src == 192.168.1.229 Only packets my Mac sent
4 ip.dst == 192.168.1.229 Only packets my Mac received
5 ip.dst == 192.168.1.229 and http HTTP addressed to my Mac, which is the server's response
6 dns or http Lookups and web requests together, each lookup just before its request

ip.addr matches if either the source or the destination equals the address. and keeps packets that match both conditions, and or keeps packets that match either one.

http#

http: frame 23058 HEAD / HTTP/1.1 from 192.168.1.229 to 34.223.124.45, and the HTTP/1.1 200 OK reply 0.368 s later

ip.addr, ip.src and ip.dst#

ip.addr == 192.168.1.229: traffic in both directions

ip.src == 192.168.1.229: only outgoing packets

ip.dst == 192.168.1.229: only incoming packets

ip.dst == 192.168.1.229 and http#

Only one packet matches both conditions: the HTTP/1.1 200 OK coming back from neverssl.com

dns or http#

dns or http: the DNS queries to 192.168.1.1 alongside the HTTP request they led to

Why PSU never showed up as HTTP#

The lab asks for HTTP traffic from www.psu.edu.sa, but that site only accepts HTTPS. The capture shows it clearly:

53
TCP SYNs to 85.194.98.161:80
0
Replies from port 80
12,985
Packets on port 443 (TLS), both ways
0
PSU packets under the http filter

Port 80 never answered, so curl gave up with a timeout. Everything the browser loaded came over TLS on port 443. That traffic is encrypted, so Wireshark's http filter has nothing to show.

To get readable HTTP I used http://neverssl.com (34.223.124.45), a site kept on plain HTTP for testing:

zsh · curl
% curl -I http://neverssl.com
HTTP/1.1 200 OK
Server: Apache/2.4.68 ()
Content-Type: text/html; charset=UTF-8
! remaining headers trimmed

curl -I http://neverssl.com returned HTTP/1.1 200 OK with its headers

One name, two correct answers#

google.com.sa was resolved twice:

Resolver Answer Where
8.8.8.8 (Google Public DNS) 142.250.203.3 nslookup google.com.sa 8.8.8.8
192.168.1.1 (the router, local DNS) 172.217.17.35 Frames 221 and 224, just before the ping
zsh · nslookup via 8.8.8.8
% nslookup google.com.sa 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   google.com.sa
Address: 142.250.203.3

nslookup google.com.sa 8.8.8.8 answered 142.250.203.3

Both answers are correct:

Many front ends#

Google serves the same site from many IP addresses around the world, not from one machine.

Depends on who asks#

Google's DNS gives out an address near where the query seems to come from. My router and 8.8.8.8 sit in different places, so each gets a different "nearest" server.

Anycast#

8.8.8.8 is one address announced from many Google sites. The query goes to whichever is closest in routing terms.

The ping used the local answer, so every ICMP packet in the capture goes to 172.217.17.35.