[WSL2/Ubuntu/Debian/Kali] Network not configured

[ericct]

Windows build number: version 2004 Build 19041.264

I've removed all WSL/WSL2 components and Docker before installing only WSL/WSL2. I have the same behaviour on 4 distributions (Ubuntu 18.04/20.04, Debian 10, Kali Linux 2020.1).

All coming lines are from Ubuntu 20.04.

When started, I cannot get any connection. eth0 interface is down and not configured:

ip addr show eth0
4: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:15:5d:3c:76:f7 brd ff:ff:ff:ff:ff:ff

Using ipconfig from Windows gives me information about needed network configuration:

Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::a0cf:c53c:da4:86ef%53
   IPv4 Address. . . . . . . . . . . : 172.31.208.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

I then manually configure eth0 and add a default route:

sudo ip address add 172.31.208.10/20 broadcast 172.31.223.255 dev eth0
sudo ip route add default via 172.31.208.1

Now the interface:

ip addr show eth0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:3c:76:f7 brd ff:ff:ff:ff:ff:ff
    inet 172.31.208.10/20 brd 172.31.223.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe3c:76f7/64 scope link
       valid_lft forever preferred_lft forever

and the route:

ip route
default via 172.31.208.1 dev eth0
172.31.208.0/20 dev eth0 proto kernel scope link src 172.31.208.10

are correct (network connections are working).

What's not working: network is not fully configured
Expected behaviour: have inet fully configured without manual intervention. Also, the network settings change at each reboot, raising the need for this operation after each reboot.

[betancour]

Hello Fellow Devs 😊

I had an error using WSL2 and Ubuntu 20.04
Seems like the /etc/resolv.conf generates an incorrect nameserver
adjusting this nameserver manually my connection start to working again.

I've tried to disable the auto-generation of this nameserver adjusting the /etc/wsl.conf
with:

[network]
generateResolvConf = false

this creates a linked file with .../run/resolvconf/resolv.conf that don't allows me to create a fixed one.

please let me know if you have any patch or remedy to this error.

Best regards.

[skippednote]

@betancour I set my DNS to the one being used on the host but that didn't help. I've tried solutions on the other issues and none of it has worked so far.

[betancour]

@betancour I set my DNS to the one being used on the host but that didn't help. I've tried solutions on the other issues and none of it has worked so far.

Hi skippednote
Regarding your message
Did you use your router IP as the nameserver?

[skippednote]

@betancour By default it points to 172.20.32.1 which is Ethernet (WSL).
I've tried changing it to 8.8.8.8 as well but that didn't help either.

[betancour]

@betancour By default it points to 172.20.32.1 which is Ethernet (WSL).
I've tried changing it to 8.8.8.8 as well but that didn't help either.

Hi Again @skippednote

I've tried using Google DNS unsuccessfully.

The way that works is when I use my router ip as nameserver
Example:

 betancour  Inspiron-5570  mnt  d  Dev  $  sudo apt-get update
[sudo] password for betancour:
Err:1 https://deb.nodesource.com/node_12.x focal InRelease
  Temporary failure resolving 'deb.nodesource.com'
Err:2 https://archive.ubuntu.com/ubuntu focal InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Err:3 https://security.ubuntu.com/ubuntu focal-security InRelease
  Temporary failure resolving 'security.ubuntu.com'
Err:4 https://dl.yarnpkg.com/debian stable InRelease
  Temporary failure resolving 'dl.yarnpkg.com'
Get:5 https://archive.ubuntu.com/ubuntu focal-updates InRelease [107 kB]
Get:6 https://archive.ubuntu.com/ubuntu focal-backports InRelease [98.3 kB]
Fetched 205 kB in 39s (5261 B/s)
Reading package lists... Done
W: Failed to fetch https://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch https://security.ubuntu.com/ubuntu/dists/focal-security/InRelease  Temporary failure resolving 'security.ubuntu.com'
W: Failed to fetch https://deb.nodesource.com/node_12.x/dists/focal/InRelease  Temporary failure resolving 'deb.nodesource.com'
W: Failed to fetch https://dl.yarnpkg.com/debian/dists/stable/InRelease  Temporary failure resolving 'dl.yarnpkg.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.
 betancour  Inspiron-5570  mnt  d  Dev  $  echo 'nameserver 192.168.1.1' >> /etc/resolv.conf
 betancour  Inspiron-5570  mnt  d  Dev  $  sudo apt-get update
Get:1 https://security.ubuntu.com/ubuntu focal-security InRelease [107 kB]
Hit:2 https://archive.ubuntu.com/ubuntu focal InRelease
Get:3 https://archive.ubuntu.com/ubuntu focal-updates InRelease [107 kB]
Hit:4 https://dl.yarnpkg.com/debian stable InRelease
Hit:5 https://deb.nodesource.com/node_12.x focal InRelease
Get:6 https://archive.ubuntu.com/ubuntu focal-backports InRelease [98.3 kB]
Fetched 312 kB in 18s (17.8 kB/s)
Reading package lists... Done

[skippednote]

@betancour I'm seeing a similar output. What DNS address is working for you?

[betancour]

Hi @skippednote as you can see I am using the 192.168.1.1

[skippednote]

@betancour This doesn't work for me. Only thing that work is reverting to WSL1

[ericct]

There are two different things here:

• one is to have a network route (initial topic), which sometimes apprently is not set (initial topic here)
• another one is indeed name resolution

Default is to rely on the host machine for name resolution. /etc/resolv.conf is dynamically generated when WSL2 kernel starts. One can of course set another DNS IP.

But, there may also be a third problem with the firewall on the host, blocking communication for WSL2.

At the end, apt update problem can have multiple reasons.

[skippednote]

@ericct I don't have a VPN or Antivirus installed. I have tried with Windows Defender Firewall disabld.

[skippednote]

@betancour @ericct For me it was an issue with the ISP who had disabled post routing. After enabling it internet is working fine in WSL2.

[tokiedokie]

same here

eth0 is down every after reboot
but i configure eth0 up, eth0 can't ip addr
when i configure ip addr and route, network works fine

[ericct]

same here

eth0 is down every after reboot
but i configure eth0 up, eth0 can't ip addr
when i configure ip addr and route, network works fine

Yes, this is the same case. I'm not alone!

It's really that the network is not fully configured, the other cases are other issues.

So, does anyone have a solution for this uncomplete network configuration (inside WSL2)?

[tokiedokie]

clean install windows works for me.

[betancour]

clean install windows works for me.

Anotherway is deleting the account and log again with your account to set default parameters. thanks so much.

[fanqisoft]

I can't access the HTTPS network, but HTTP is OK

[ericct]

Is it closed because it's fixed?

There are different problems reported in this thread, but the initial one seems to impact multiple people and while it seems to have work-arounds (more or less convenient), there's no clear status.

Is it just rejected as bug?

[therealkenc]

This one got caught in the clicks, apologies. There is no repro here though. That's not on you, but without someone guessing the externality (the variable) it will be tough to turn into an actionable.

[betancour]

To repro

1. Fresh install Windows 10 2004
2. Install WSL
3. Convert any WSL distro to WSL 2
4. Check updates on the converted repo,

[therealkenc]

That is obviously not a repro. That it is a repro for you and confirmed by others, for reasons as yet unidentified, is not in question. But imagine, just for a moment, if that was actually a way to reproduce the issue. I am not sure it is even constructive to point this out. You cannot possibly imagine that posting those four steps contributes toward a better understanding of the nature of this issue.

(deep breath)

WAG try fiddling "ipv6 things". That's a usual suspect ref #4486.

[betancour]

That is obviously not a repro. That it is a repro for you and confirmed by others, for reasons as yet unidentified, is not in question. But imagine, just for a moment, if that was actually a way to reproduce the issue. I am not sure it is even constructive to point this out. You cannot possibly imagine that posting those four steps contributes toward a better understanding of the nature of this issue.

(deep breath)

WAG try fiddling "ipv6 things". That's a usual suspect ref #4486.

I am not blaming the REPO, while the REPO is WSL the connection works without any issue, the problem start when the REPO is converted.

You are able to test this procedure and check if this happens or not.

Regards,

[therealkenc]

You are conflating the sequence of events that you experienced with causality. That is a standard "does not follow" logic fail. You have proposed no technical basis for the premise that upgrading a WSL 1 distro would be any different than installing a distro with the default set to WSL 2. You would have to conclude every WSL 2 user manually configures their network (and everyone kept that to themselves until 6 days ago) if that were plausible.

You are able to test this procedure and check if this happens or not.

No one sane would pursue that test procedure, given the known data-point of tens of thousands of WSL 2 users doing that very scenario all day every day. But allowing for the negative antecedent....

[czheji]

@ericct This problem occurs if the %temp% directory is compressed. To fix:

wsl --shutdown
compact /u %temp% /i /Q

I guess the temporarily created swap file was compressed, which caused this problem.
But it is very strange, why compressing the swap partition will cause wsl2 initialization is incomplete, and there is no error message!

To repro:

wsl --shutdown
compact /C %temp% /i /Q

When using wsl2 again, there will be problems.

[giannadakis]

Hi, for me works when i use this command:

sudo sh -c "echo 'nameserver 192.168.1.1' >> /etc/resolv.conf"

but after reboot the system the nameserver 192.168.1.1 disappear and the problem returned.

[ericct]

OK, I'll try to reproduce on another machine

[ericct]

Hi, for me works when i use this command:

sudo sh -c "echo 'nameserver 192.168.1.1' >> /etc/resolv.conf"

but after reboot the system the nameserver 192.168.1.1 disappear and the problem returned.

This issue is not about DNS/nameserver but network stack not configured. Again, there may be multiple reasons for not being able to update, the issue reported here is not "apt update fails" or "no Internet access".

Good hint anyway!

[KylePiira]

@czheji's solution worked for me. I just unchecked the NTFS compression on AppData/Temp.

Seems like WSL 2 doesn't work very well with NTFS compression since I also needed to fix #4103 previously. I wonder if using encryption on %temp% would also break networking.

[therealkenc]

That appears to be a repro. @ericct can you confirm whether (or not) your %temp% is compressed.

[ericct]

Hello,

No, my temp folder is not compressed. So it may trigger the problem but seems not to be the only reason.

[ericct]

No clear repro so far, but another case it seems: #5336

[therealkenc]

No, my temp folder is not compressed.

That was my suspicion, thanks. @czheji if you want to open a new issue with your %temp% repro (good catch thank-you) please do. Or I'll get it if it doesn't pop up in the next couple of days. Otherwise we'll have multiple potential actionables in one issue, which is usually a thread killer.

[gtumanyan]

This problem occurs if the %temp% directory is

in my case, it was moved without symlink made pointing to a new location.
Thank you. My problem is solved too!

[kobenauf]

@giannadakis fix above worked for me too, but also only until I reboot.

sudo sh -c "echo 'nameserver 192.168.1.1' >> /etc/resolv.conf"

After that sudo apt update works. The problem seems to be with the ip addr wsl2 is populating in /etc/resolv.conf as the nameserver. Mine originally was this: nameserver 172.28.144.1.

Is it related to some change Windows has made to permissions/firewall on that internal ip addr? The sudo apt update command used to work. I don't know what nameserver used to be set at when it used to work, because I never needed to care before.

[ericct]

Yes, I confirm the root cause, as explained in #5437

Better to close this one then, since it's misleading to other network issues (nameserver issues mainly).

[Ritbit1111]

same here

eth0 is down every after reboot
but i configure eth0 up, eth0 can't ip addr
when i configure ip addr and route, network works fine

Hey can you show the steps?

[realasking]

Hi, for me works when i use this command:

sudo sh -c "echo 'nameserver 192.168.1.1' >> /etc/resolv.conf"

but after reboot the system the nameserver 192.168.1.1 disappear and the problem returned.

This works for me. Thanks very much.

[therealkenc]

/dupe #5437

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!

[TgMrP]

Hi, for me works when i use this command:

sudo sh -c "echo 'nameserver 192.168.1.1' >> /etc/resolv.conf"

but after reboot the system the nameserver 192.168.1.1 disappear and the problem returned.

This works for me. Thank you very much.

[EvoPulseGaming]

Internet worked once, then never again. After several days of trying things:
Reset network = no
Reset firewall = no
Manually setting IP, using ICS with the vEthernet (WSL), etc = no

Finally:
wsl --shutdown
compact /u %temp% /i /Q (I would like to point out that the temp folder itself was not compressed, but I suspect something within was.
Open device manager, remove the Hyper-V network, restart.

Suddenly its like the day I first installed wsl 2 and everything works.

[OranguTech]

@ericct This problem occurs if the %temp% directory is compressed. To fix:

wsl --shutdown
compact /u %temp% /i /Q

I guess the temporarily created swap file was compressed, which caused this problem.
But it is very strange, why compressing the swap partition will cause wsl2 initialization is incomplete, and there is no error message!

To repro:

wsl --shutdown
compact /C %temp% /i /Q

When using wsl2 again, there will be problems.

This was driving me nuts, thank you! (To be clear, it applied to multiple distros)

[msustik]

Windows noob here. When you use % in the file or directory names is that actually part of the name?
compact /C %temp% /i /Q
returned that 0 files within 1 directories were uncompressed.

[zecaoliveira]

@czheji's solution worked for me. I just unchecked the NTFS compression on AppData/Temp.

Seems like WSL 2 doesn't work very well with NTFS compression since I also needed to fix #4103 previously. I wonder if using encryption on %temp% would also break networking.

Thank you @KylePiira .

I disabled bitlocker but the folder %temp% was still compressed.

After turning off compression, the interface started working automatically.