DEV Community

Gordon Deng
Gordon Deng

Posted on

Wireshark shows DNS for an HTTP lab site but no plaintext HTTP GET on WLAN

#wireshark #networking #http #help

I'm doing a university Wireshark lab and I’m stuck on a packet-capture issue. I’d appreciate help understanding what is happening and what I should capture next.

Goal

Capture a plaintext HTTP request/response for this lab URL in Wireshark:

http://gaia.cs.umass.edu/wireshark-labs/INTRO-wireshark-file1.html

The page is expected to return a simple welcome message, and the lab requires analyzing the HTTP GET and the server response.

Environment

  • Windows
  • Wireshark 4.6.9
  • Microsoft Edge
  • Capturing on the WLAN interface

What I observe

In the first capture:

  • DNS resolution for gaia.cs.umass.edu is visible.
  • The lab server resolves to 128.119.245.12.
  • My client’s private IPv4 address is 172.27.x.x.
  • Applying the display filter http does not show the expected GET request to gaia.cs.umass.edu.
  • The HTTP-filtered packets appear to be unrelated Windows connectivity-check traffic.
  • There is a connection from the client to the lab server on TCP port 443 (HTTPS), but the lab needs the plaintext HTTP request on port 80.

The confusing part is that the site itself works over HTTP. I tested it separately with curl and got 200 OK with no redirect, and the expected welcome text:

Congratulations! You've downloaded the first Wireshark lab file!

So the server supports plaintext HTTP. The problem seems to be on the capture/routing side.

What I’ve tried

  • Confirmed the URL starts with http://, not https://.
  • Checked that Edge’s “always use secure connections / automatic HTTPS” option is not enabled.
  • Captured on WLAN and filtered with:
    • http
    • http.host == "gaia.cs.umass.edu" || http.response
    • dns.qry.name == "gaia.cs.umass.edu"
  • DNS packets are captured, but the expected HTTP GET is not.
  • I have fully exited the accelerator/proxy software and repeated the capture in a clean InPrivate window.

Any debugging suggestions would be very helpful. I can share sanitized packet details or a filter output if needed, but I’d rather not upload the full capture because it may contain unrelated traffic.

Top comments (1)

Collapse
 
m_montazeri profile image
Mohammad Montazeri •

The useful next comparison is to capture the curl request that already works, on the same Windows machine and WLAN interface, while Wireshark is recording. Start a fresh capture with no capture filter; then run:

curl.exe -v http://gaia.cs.umass.edu/wireshark-labs/INTRO-wireshark-file1.html
Enter fullscreen mode Exit fullscreen mode

Afterward, use ip.addr == 128.119.245.12 && tcp as a display filter (adjust the address if the current lookup differs), rather than starting with http. Check the actual destination port and whether the TCP exchange appears. Wireshark’s display filter only hides packets; it does not remove them from the capture.

If that controlled curl request appears on port 80 with the GET/response, the interface can capture this traffic; compare a separate Edge capture and its final URL/protocol next. If curl returns the page but its connection is absent from that capture, first compare the connection endpoint reported by -v with the interfaces/proxy path being captured. Seeing DNS alone does not establish that the later web connection took the same path.

No full packet capture is needed here: the outcome of those two tests and sanitized destination-port/status details should narrow it down. Verbose output can contain sensitive headers, so do not paste it unredacted.

Sources: wireshark.org/docs/wsug_html_chunk... and curl.se/docs/manpage.html#--verbose

AI-assisted reply; I work on Lisar Connect.