Localhost stops working for windows containers on latest stable build

[mlmeyers]

Expected behavior

docker run -d -p 80:80 nanoserver/apache24
Call http://localhost:80 from the browser will show its working page

Actual behavior

Cannot reach http://localhost:80 from the browser.

Information

PS C:\WINDOWS\system32> docker version
Client:
Version: 17.12.0-ce
API version: 1.35
Go version: go1.9.2
Git commit: c97c6d6
Built: Wed Dec 27 20:05:22 2017
OS/Arch: windows/amd64

Server:
Engine:
Version: 17.12.0-ce
API version: 1.35 (minimum version 1.24)
Go version: go1.9.2
Git commit: c97c6d6
Built: Wed Dec 27 20:15:52 2017
OS/Arch: windows/amd64
Experimental: true

A diagnostic was uploaded with id: ED8A1BCA-EA54-42C8-B846-21A0B2FBB388/2018-02-21_22-09-42

WinVer: 16299.284

Unfortunately I am not sure what triggers this and how to reproduce it. It will work OK after a nuke and pave re-install and then simply stop working. I have now encountered this behavior on 3 different workstations and on others it never seems to present itself. Starting to wonder if compose triggers it as I started a few compose projects wiht exposed ports in my last run when it again stopped working (dart at a dart board).

When the issue is encountered I see this in the logs.

[21:42:21.217][LocalhostForwarder][Info ] TransortErrorException 1
[21:42:21.217][LocalhostForwarder][Info ] Failed to forward tcp port 27019 to 172.29.42.128:27017
[21:42:21.217][LocalhostForwarder][Info ] Reconciliation failed: invalid argument

I am rather certain the log points to the issue, unfortunately I have come up empty trying to understand what causes the exception and how to resolve it.

This is a major problem for me as I am rolling out docker to developers. We have tests that look to localhost and am relying on this to work properly. Any help / assistance on this issue would be greatly appreciated.

[guillaumerose]

We have the same issue on our CI. Since couple of days, with an up-to-date version of Windows, exposed ports stopped working. The port cannot be bound by the forwarder we have for that purpose.
We are looking at it with Microsoft right now. Sorry for this.

If you use Windows build 15063, it will work. But 16299 (and probably up-to-date Windows Server 2016) are impacted.

[mlmeyers]

Thanks Guillaume for the update, please keep me posted on any findings. I am happy to test | help if needed. Unfortunately rolling back from creators is a high cost proposition and just not doable across my organisation. looking I suspect the forwarder was pulled in from this project.

https://github.com/simonferquel/localhost-forwarder

Not being a developer I have a hard time saying but appears the error is thrown from forwarding_tcp_addEntry method in the shim.cpp class.

Unfortunately the error thrown falls into the unknown category, see below.

<client_c.h>
enum forwarding_error{
FORWARDING_OK = 0,
FORWARDING_UNKNOWN_ERROR = 1,
FORWARDING_NAME_RESOLUTION_FAILED = 2,
FORWARDING_BIND_FAILED = 3,
};

<shim.cpp>
forwarding_error forwarding_tcp_addEntry(forwarding_tcp tcp, uint16_t localPort, uint32_t remotePort, char* remoteAddress) {
try {
reinterpret_castforwarding::TcpForwarder*(tcp)->AddEntry(localPort, remotePort, remoteAddress);
return FORWARDING_OK;
}
catch (forwarding::TransportErrorException& ex) {
switch (ex.Error)
{
case forwarding::TransportError::NameResolutionFailed:
return FORWARDING_NAME_RESOLUTION_FAILED;
case forwarding::TransportError::BindFailed:
return FORWARDING_BIND_FAILED;
default:
return FORWARDING_UNKNOWN_ERROR;
}
}
catch (...) {
return FORWARDING_UNKNOWN_ERROR;
}
}

[guillaumerose]

Yes it's a bind error and if you try to run python -m http.server 8080. You will see the full error. Really strange.

[mlmeyers]

Hey guillaumerose, just curious if anything further has been learned in regards to this issue? Sadly I am on hold with my roll-out until the time I can confirm this will not be an issue.

[mlmeyers]

This appears related to windows CU update (KB4074588) build 16299.248

I was ahead of my org when I was encountering this issue and recently reset back to our base image that was running on build 16299.192, This seemed to have resolved my issue. Unfortunately the organization is now pushing this CU out, got the notify today it was being installed. Immediately after the CU update the issue returned. Probably safe to say it is going to break every docker users port forwarding.

Is there any traction on this?

[mlmeyers]

Closing this out, #1707 appears the best place to track and is wip.

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked