Reactivation required every reboot of Debian in WSL2

OS Name/Version: WSL2 Debian

Product Name/Version: AMP Release “Phobos” v2.6.0.6,

Problem Description: Every time the computer restarts, I am required to re-enter the license key.

Steps to reproduce:
Install AMP in WSL2 Debian instance. Enter licence key. Restart Windows. Start WSL2 Debian instance. Licence key required again. If I just close the Debian instance and re-open it, this issue doesn’t occur.

Actions taken to resolve so far:

It looks to me like the issue is the eth0 MAC changing on reboot of the system.

ip addr on initial load:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1420 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:28:39:72 brd ff:ff:ff:ff:ff:ff
    inet 172.27.31.184/20 brd 172.27.31.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe28:3972/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:ad:d2:1a:fd brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

ip addr on second load:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1420 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:db:9f:38 brd ff:ff:ff:ff:ff:ff
    inet 172.27.31.184/20 brd 172.27.31.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fedb:9f38/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:75:72:e1:b7 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

Is there any way around this? Could this issue be addressed?

It’s not an AMP issue per-se, as AMP encrypts the licence with the hardware ID.
If I remember correctly, Windows Pro has a feature where you can set the MAC address to change on startup, you’d want to check for and disable that if it’s on.
You can run into a similar issue with VPNs installed on the system, as they’ll sometimes change their MAC address, but since they’re not standard hardware, AMP has some checks to filter out some of it iirc.

That makes sense. In looking at options for setting a MAC address, I may need to create a dummy interface rather than modifying eth0. Any idea if AMP looks at just eth0 or all external facing interfaces?

To my knowledge it would be looking for any that look like a proper Ethernet or Wifi interface, not sure on the specifics it uses for weeding out docker or VPN interfaces.

Found a few things while looking around:
https://dhcp.msu.edu/help/randommac.html#windows_device

This looks a bit more related, but not too promising, being an open issue from 2020:
https://learn.microsoft.com/en-us/answers/questions/73672/(ubuntu-on-the-wsl2)-fixed-mac-address-with-availa

Should probably take a copy of your instance files before fiddling around with the WSL install, just in case something borks out

Found this similar issue, that might have a workaround configuring the MAC address in a config file:
https://github.com/microsoft/WSL/issues/5291#issuecomment-1325991398
https://github.com/luxzg/WSL2-fixes/blob/master/networkingMode%3Dbridged%20-%20quick%20setup.md

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.