wsl: Failed to configure network (networkingMode Consomme), falling back to networkingMode None. #41722

Activity

1. github-actions commented on Sep 29, 2026

   

   github-actionsBot

   on Sep 29, 2026 – with GitHub Actions

   Contributor

   More actions

   Diagnostic information

   .wslconfig found
   	Custom kernel command line found: 'ipv6.disable=1'
   Detected appx version: 2.9.13.0
   
2. OneBlue commented on Oct 9, 2026

   

   Blue (OneBlue)

   on Oct 9, 2026

   Collaborator

   More actions

   Fixed in 3.0.3
3. Blue (OneBlue)

   closed this as completedon Oct 9, 2026
4. fowl2 commented on Nov 5, 2026

   

   James May (fowl2)

   on Nov 5, 2026

   More actions

   I can still reproduce CreateInstance/CreateVm/ConfigureNetworking/E_UNEXPECTED on WSL 3.0.3.0 with networkingMode=consomme and kernelCommandLine=ipv6.disable=1. :(

   AI diagnosis:

   The diagnostic trace appears to identify a different IPv6-disabled failure path from the loopback sysctl failure addressed by PR #41729: WSL attempts to add an IPv6 address to the guest, and Linux rejects the netlink operation with error -95.

   Environment

   • Windows 11 Enterprise, 10.0.26200.9711
   • WSL version: 3.0.3.0
   • Kernel version reported by wsl --version: 6.18.54.1-1
   • Guest uname -r: 6.18.54.1-microsoft-standard-WSL2
   • WSL 2
   • Ubuntu 24.04.4 LTS (Noble Numbat)
   • GlobalProtect 6.3.3-1199, disconnected during the initial controlled tests

   Both the registered WSL package and the installed WSL service executable report version 3.0.3.0.

   Relevant configuration for reproduction

   [wsl2]
   networkingMode=consomme
   kernelCommandLine=ipv6.disable=1

   The failure was also reproduced with networkingMode=VirtioProxy, which reported Consomme in the startup error.

   Reproduction

   1. Configure Consomme networking and kernelCommandLine=ipv6.disable=1.
   2. Run:

      wsl --shutdown
      wsl -d Ubuntu

   3. Observe:

      wsl: Catastrophic failure
      Error code: CreateInstance/CreateVm/ConfigureNetworking/E_UNEXPECTED
      wsl: Failed to configure network (networkingMode Consomme), falling back to networkingMode None.
      

   Ubuntu still starts. An IPv4 address is present on its network interface, but the default IPv4 route is missing. DNS resolution fails, and an IPv4 HTTPS request fails with:

   curl: (6) Could not resolve host: example.com
   

   Controlled configuration tests

   I tested the IPv6 boot setting while keeping the other configuration settings unchanged within the following remove/restore sequence:

   Configuration	Observed result
   networkingMode=VirtioProxy, ipv6.disable=1	Consomme startup error; no default route; DNS/HTTPS failed
   Removing only kernelCommandLine=ipv6.disable=1, followed by shutdown/restart	No networking warning; default route present; DNS resolution worked; IPv4 HTTPS returned HTTP 200 twice
   Restoring only kernelCommandLine=ipv6.disable=1, followed by shutdown/restart	Same startup error returned; default route absent; DNS/HTTPS failed

   Separately, switching to NAT while retaining kernel-level IPv6 disabling restored networking.

   The current working NAT session was subsequently checked:

   Distribution: Ubuntu 24.04.4 LTS
   Kernel: 6.18.54.1-microsoft-standard-WSL2
   Kernel command-line option: ipv6.disable=1
   /proc/sys/net/ipv6: absent
   wslinfo --networking-mode: nat
   IPv4 default route count: 1
   

   Relevant diagnostic trace events

   I collected the failing startup with Microsoft's collect-wsl-logs.ps1, using the default WSL profile.

   The collector confirmed:

   The trace was successfully saved.
   

   The trace was decoded locally. The excerpts below redact the actual IPv6 address and omit identifying local paths.

   Configuration telemetry records:

   wslVersion=3.0.3.0
   NetworkingMode=Consomme
   EnableIpv6=0
   

   Immediately before the networking failure, Linux/GNS logs:

   GnsEngine: run - ERROR: Error while processing message:
   Exception thrown by void NetlinkTransaction::Execute(
       const std::function<void (const NetlinkResponse &)> &
   ) in NetlinkTransaction.cpp:35:
   Error in netlink transaction.
   
   Innermost exception:
   Exception thrown by void NetlinkResponse::ThrowIfErrorFound() const
   in NetlinkResponse.cpp:25:
   Netlink returned error: -95
   

   The corresponding Windows-side event is from GnsChannel.cpp:68:

   hr=0x8000FFFF
   Error returned from GNS after sending message:
   {
     "RequestType": "Add",
     "ResourceType": "IPAddress",
     "Settings": {
       "Address": "<IPv6 address redacted>",
       "Family": 23,
       "OnLinkPrefixLength": 64,
       "PreferredLifetime": 4294967295,
       "PrefixOrigin": 0,
       "SuffixOrigin": 0
     }
   }
   type 55. Result=-1
   

   Linux error 95 is EOPNOTSUPP (“Operation not supported”).

   This is followed by:

   CreateInstance/CreateVm/ConfigureNetworking/E_UNEXPECTED
   Failed to configure network (networkingMode Consomme),
   falling back to networkingMode None.
   

   The trace therefore shows an IPv6 address-add request being sent to the guest despite EnableIpv6=0 and kernel IPv6 being disabled.

   Relationship to PR #41729

   PR #41729, “Don't fail configuring the consommé loopback adapter when ipv6 is disabled,” is present in the public 3.0.3 source and adds a ConfigurationNoIpv6 regression test.

   Its exception handling protects the IPv6 sysctl operations in NetworkManager::InitializeLoopbackConfiguration, ignoring ENOENT when /proc/sys/net/ipv6 is absent.

   The failure captured here appears to be a separate netlink IP-address configuration operation, rather than that missing-sysctl failure. This would explain why the loopback fix does not prevent the failure on this machine.

   I have verified the installed component version labels, but have not independently verified the compiled Linux initialization binary against the source tag.

   Could the host IPv6 address configuration path also need to honor the guest's disabled-IPv6 state?

   WSL and GlobalProtect update history

   Local Windows Installer events show:

   Date/time (UTC+11)	Event
   26 October 2026	WSL 2.7.14.0 installed
   5 November 2026, approximately 01:49	GlobalProtect installation completed
   5 November 2026, approximately 09:27–09:29	WSL 3.0.3.0 installed

   The immediately preceding WSL version was therefore likely 2.7.14.0. I have not retested that version, so I cannot establish a regression boundary.

   The current GlobalProtect executable reports 6.3.3-1199; its registry DisplayVersion is 6.3.3.1199.

   The removed GlobalProtect package also reported version 6.3.3, so the available installer events do not establish its previous full build or distinguish a build-level update from a same-version reinstall.

   The problem was initially associated with the GlobalProtect update, but a WSL update also occurred that morning. GlobalProtect's involvement remains unproven.

   Previous troubleshooting

   Before the controlled IPv6 tests, the following did not resolve the issue:

   wsl --shutdown
   Restart-Service hns
   hnsdiag reset networks

   A Windows reboot also did not resolve it.

   Diagnostic availability

   I have retained the full ETW capture locally, but am not attaching the archive publicly because it contains personal and corporate network information.

   The collector reported a WSLg log-collection timeout, but the WSL ETW trace was successfully saved and contains the reproduced networking failure.

   I can provide additional targeted, sanitized event excerpts if needed. Please advise which events or fields would help investigate the IPv6 address-add path.
5. fowl2 commented on Nov 5, 2026

   

   James May (fowl2)

   on Nov 5, 2026

   Last edited by fowl2

   More actions

   Seems like consomme+ipv6 disabled is fixed in prerelease 3.0.5.0. Probably PR #42026.

   yolo wsl --update --pre-release I guess