New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 255602 link

Starred by 5 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Jan 2014
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

Feature Request: Get IP address from devtools

Project Member Reported by, Jun 28 2013

Issue description

Hi Chrome team,

In our project, we use Webpagetest( which based on Chrome devtools to detect web page errors and latency.  But we can't get the IP address when errors occur, the error may be result of server error or DNS hijack. It is critical to us especially in China.


Comment 1 by, Jun 28 2013

Labels: Cr-Platform-DevTools Cr-Internals-Network-DNS
Status: Untriaged
WebPageTest also lets you get pcap as well as net-internals logs for Chrome. Perhaps this is a good feature request anyway, but it may be a workaround for now.

Comment 3 by, Jun 28 2013

These guys *are* using WPT, though they use the newer WPT agent that's
based on just DevTools. WPT accepts a raw DevTools trace and splits it into
its own waterfall chart + a saved Timeline file that can be displayed in an
embedded Timeline viewer. Their stopgap is they hacked WPT run DNS lookups
separately after the end of the test and populate IPs into WPT's waterfall
chart. Of course with muti-IP responses there is no way to tell which of
the IPs was actually used, aggravated by IPv6, which is not ideal, but not
a showstopper until a robust solution becomes available.

The conceptual problem with pcap is you can't decode SSL, and the tests in
question do have SSL traffic.

From a conversation with Matt, another useful developer-facing application
of exposing IP in DevTools, independent of WPT, is making sure their IPv6
setup actually works with Chrome.

Comment 4 by, Jun 28 2013

There are a couple issues with implementing this:

It's fairly straight forward just to pass IP addresses from the bottom of the stack to the top in the normal, non-cached, non-proxy, non-range case after we read the headers.

That having been said...

1) In the HTTP case when we receive a partial set of headers, we currently hang up too early for that to work.

2) In the case where we have to connect to a server to validate the response, we hang up before returning any results, so we lose the IP before we pass along the headers.  It's also not clear if we *should* be exposing the IP in devtools here.  It's not the IP that the response came from, just the IP the response that we could use the cache entry came from.

3) Range requests can use multiple HTTP requests, with different sockets (And theoretically different IPs).  They may not even connect to a server until after returning cached headers and part of a cached body.  Not sure what devtools currently do in this case.

4) Proxies:  When using HTTP, HTTPS/SPDY, SOCKS4a, and SOCKS5 proxies we don't have the server IP.  It's unclear if we should provide the proxy IP.  With SOCKS4, we give the proxy the server IP, and just trust it to connect to the right server.  Suppose we should trust the server in that case.  May be rare enough that we don't really care, either way.

We can, perhaps, ignore 1) and 3), and provide no IPs in 4).  To handle 2), we'd have to cache the IP information at the HttpCacheTransaction level, like we do with resource timing information to handle the same case.

Comment 5 by, Jun 28 2013

And I should add, despite the issues I raised, I do think this would be pretty useful information to have in devtools.  I've seen it requested to help with diagnosing IPv6/IPv4 issues as well.

I'd like to hear what the devtools folks think about adding the information before we commit to anything, network side.

Comment 6 by, Jul 2 2013

Status: Assigned
@mmenke: DevTools team would be happy to show IP information.

Comment 8 by, Jan 9 2014

Hi All,

Any update about this feature?
Labels: -Pri-2 Pri-3
I'm certainly not working on it.  Have a lot of higher priority things on my plate.
This looks like a pretty old bug (7 months old).  It looks like Eugene ( had said back in August they 'd be happy to see it done.  Is it perhaps done and we don't know about it?  Can someone from the devtools team comment?

I think what Eugene meant was that if that was available in the stack, he would do the plumbing in order to surface it.
As i read the previous comments I think the implication is that it is available in the stack at least in many cases.  but I would be wrong since my knowledge of the chromium stack is limited.
It's not available at the top of the stack.

Getting it there and handling corner cases (proxies [do we want the proxy's IP?], 204s, range requests, etc) and passing things up through all the layers of the network stack is a fair bit of effort, particularly when you throw in unit tests.
Labels: -Pri-3 Pri-2
mmenke: Could we handle the common case by just listening to TYPE_TCP_CONNECT_ATTEMPT and similar events in DevToolsNetLogObserver? The main caveat is that it wouldn't work for requests that are bound to sockets that established connections prior to the DevToolsNetLogObserver being attached. But it also means no changes to the net code or needing to bubble things up. I have a hacked version running on my local machine.
It turns out that at the place we build the JSON object for the DevTools view/remote debugging (buildObjectForResourceResponse) that the ResourceResponse object already has a remote IP address field. I don't know yet if this is populated for Chrome or whether this was a Safari or other WebKit-only feature. Going to try now, but decided to jot it down in case I need to do something else.
A quick hack of the devtools console shows that this already has the right information on at least a spot check of http/https/spdy traffic. If this holds up it means that a change is reasonably trivial and does not require net plumbing work or even DevToolsNetLogObserver and IPC changes. At this point I may as well keep on just to go through the Blink process. 
And I'd want to check IPv6 as well.
And - ultimately the address is coming from URLRequest::GetSocketAddress, which does have some caveats but I believe mainly works.
Well, if we're fine with what is given in ResourceResponse, then patch is ready =)
#19: Thanks. I think in my small testing that it's probably good enough for now. mmenke may object.
I'll play with it when I have time.  The bugginess of the socket tracking used by LoadTimingObserver was what caused me to move load timing tracking into the network stack and kill LoadTimingObserver completely, and this presumably has the same type of issues, but since we're just getting an IP, and we're not exposing the information to websites, may not be as big a deal.
Labels: -Cr-Internals-Network-DNS
Status: Fixed

Sign in to add a comment