| Bug ID |
11567
|
| Summary |
Resolve hostname from DNS/Packet and or TLS Certificate
|
| Product |
Wireshark
|
| Version |
unspecified
|
| Hardware |
x86
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Enhancement
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Version 1.12.7 (v1.12.7-0-g7fc8978 from master-1.12)
--
If an application uses a Content-Delivery Network to fetch data like for
example the Blizzard Battle.net , G-datas Antivirus or even Microsofts Windows
Update, you end up with weird hostnames in your wireshark trace.
I think "edgecast.blizzard.com" would be more helpfull to the user than what
the "resolve hostnames" option does by default.
Currently you get gp1.wpc.v1cdn.net
In this example you could get it from the get request.
"GET /tpr/hs/data/15/f7/15f7c032fe3ceb9331912723379924a5 HTTP/1.1
Host: edgecast.blizzard.com"
or blzddist1-a.akamaihd.net instead of a1219.d.akamai.net from
GET /tpr/hs/data/59/a4/59a40ea8c53d0172777be5b5c892aa0d HTTP/1.1
Host: blzddist1-a.akamaihd.net
I think similiar options could be provided by matching dns requests that most
applications send out to get the ip shortly before the connection is made or by
grabbing the hosts from the certificate.
It might not be completely right at all times to get itt it would be more
helpful than the plain reverse lookup of the ip.
Manually resolving and editing the host is quite an effort on large capture
files.
You are receiving this mail because:
- You are watching all bug changes.