https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rancher-desktop
a
This message was deleted.
f
Please try the IPv4 address from the 
rd1
interface instead then; I'm not sure that IPv6 is going to work.
s
can do! I'll let you know how it goes in 1m
Also, thank you for the speedy reply!
f
The 
rd0
interface is a bridged interface to your local LAN, and some networks don't allow multiple IP addresses on a single interface
The 
rd1
interface is local to your host, so not routable from outside your machine
s
bad news, rd1 is also inet6
Copy code
3: rd1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:55:55:8f:14:e0 brd ff:ff:ff:ff:ff:ff
    inet6 fd1e:407f:9b33:4797:5055:55ff:fe8f:14e0/64 scope global dynamic flags 100 
       valid_lft 2591959sec preferred_lft 604759sec
    inet6 fe80::5055:55ff:fe8f:14e0/64 scope link 
       valid_lft forever preferred_lft forever
is there a way to force ipv4?
f
I've never seen RD1 not getting an IPv4 address; is there a conflict with an existing subnet? 
rd
uses 
192.168.206.0/24
s
is there a conflict with an existing subnet
I'm not sure. Do you know how I would check?
my eth0 is 
inet 192.168.5.15/24
f
Yeah, that is not routable from the host; it is only used for port forwarding
👍 1
s
would the conflict be within rdctl or ifconfig?
f
I'm trying to remember where the log files for the vmnet daemons are 🙂
s
Is this what you're looking for?
Copy code
{"type":"vz","useRosetta":true,"socketVMNet":true,"mount":{"type":"virtiofs","9p":{"securityModel":"none","protocolVersion":"9p2000.L","msizeInKib":128,"cacheMode":"mmap"}},"networkingTunnel":false,"proxy":{"enabled":false,"address":"","password":"","port":3128,"username":"","noproxy":["0.0.0.0/8","10.0.0.0/8","127.0.0.0/8","169.254.0.0/16","172.16.0.0/12","192.168.0.0/16","224.0.0.0/4","240.0.0.0/4"]}}}} -> {}
that was in server.log
f
No, the 
socket_vmnet
is a separate daemon process that writes logs somewhere else
👍 1
They are in 
~/Library/Application Support/rancher-desktop/lima/_networks
Can you look through the files in there to see if you find anything interesting?
Normally they will all be empty files
s
Will do
Copy code
❯ ls -al
total 8
drwxr-xr-x@ 8 jjolley  staff  256 Feb  6 09:10 .
drwxr-xr-x@ 5 jjolley  staff  160 Feb  5 15:21 ..
-rw-r--r--@ 1 jjolley  staff    0 Feb  6 09:10 rancher-desktop-bridged_en0_socket_vmnet.stderr.log
-rw-r--r--@ 1 jjolley  staff    0 Feb  6 09:10 rancher-desktop-bridged_en0_socket_vmnet.stdout.log
-rw-r--r--@ 1 jjolley  staff    0 Feb  6 08:50 rancher-desktop-bridged_en7_socket_vmnet.stderr.log
-rw-r--r--@ 1 jjolley  staff  294 Feb  6 08:56 rancher-desktop-bridged_en7_socket_vmnet.stdout.log
-rw-r--r--@ 1 jjolley  staff    0 Feb  6 09:10 rancher-desktop-shared_socket_vmnet.stderr.log
-rw-r--r--@ 1 jjolley  staff    0 Feb  6 09:10 rancher-desktop-shared_socket_vmnet.stdout.log

~/Library/Application Support/rancher-desktop/lima/_networks
❯ cat rancher-desktop-bridged_en7_socket_vmnet.stdout.log
Initializing vmnet.framework (mode 1002)
Using network interface "en7"
* vmnet_mtu: 1500
* vmnet_interface_id: 6639729A-D67B-4FE8-92CC-F0C6B0665FCC
* vmnet_max_packet_size: 1514
* vmnet_mac_address: 36:40:45:db:0a:72
Accepted a connection (fd 6)
Closing a connection (fd 6)

Received signal 15
Only one file had anything in it, I included the contents of it
f
Did you terminate Rancher Desktop before looking at the log file? It doesn't look like an error, except for the 
signal 15
, but that can happen when Rancher Desktop stops
s
Negative:
Should I restart it?
f
Anyways, that is the bridged interface, the shared interface should still have an IPv4 address.
I would reboot the whole machine and see if that makes a difference. Are you using any special network config, like VPNs or proxies, or a company MDM profile?
s
I am on a corporate vpn
f
So can you try starting Rancher Desktop before you connect to the VPN, to see if maybe that is preventing you from getting the IPv4 address?
s
Can do!
I'll be back in a few after the machine restart. Thank you again for your help
f
Before you start Rancher Desktop again, please run 
netstat -rn | grep 192.168.2
and see if it shows any routes in the 
192.168.205.0/24
subnet (I wrote 
206
above, which was a mistake)
👍 1
s
Copy code
# Before connecting to VPN
~/Library/Application Support/rancher-desktop/lima/_networks
❯ netstat -rn | grep 192.168.2

# After connecting to VPN
~/Library/Application Support/rancher-desktop/lima/_networks
❯ netstat -rn | grep 192.168.2

# After disconnecting from VPN and starting rancher-desktop
❯ netstat -rn | grep 192.168.2
192.168.205        link#24            UC          bridge100      !
192.168.205.1      5e.e9.1e.e7.a4.64  UHLWIi            lo0
192.168.205.255    ff.ff.ff.ff.ff.ff  UHLWbI      bridge100      !
Copy code
❯ rdctl shell ip a show rd0
4: rd0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:55:55:f4:41:2b brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5055:55ff:fef4:412b/64 scope link
       valid_lft forever preferred_lft forever

~/Library/Application Support/rancher-desktop/lima/_networks
❯ rdctl shell ip a show rd1
3: rd1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:55:55:8f:14:e0 brd ff:ff:ff:ff:ff:ff
    inet6 fd1e:407f:9b33:4797:5055:55ff:fe8f:14e0/64 scope global dynamic flags 100
       valid_lft 2591994sec preferred_lft 604794sec
    inet6 fe80::5055:55ff:fe8f:14e0/64 scope link
       valid_lft forever preferred_lft forever
f
Ok, that is the shared network then. Do you still not have an IPv4 address for 
rd1
?
s
Still IPv6 for rd1
f
I have no idea how/why this happens.
I have meeting season starting in 2 min; will reply later if I get any more ideas
s
I appreciate you taking the time to dig into this with me
Good luck in your meeting
f
I still have no idea how this can be happening, but I would next try to look into 
/var/db/dhcpd_leases
and check if you have any entries from 
name=lima-0
in there.
That would tell us if VMNET allocated an IPv4 address or not, but I don't really know what to do with that information.
Oh, and did you start Rancher Desktop before you connected to your VPN? Or is this started automatically during login (and maybe controlled by an MDM profile)?
s
The VPN is started automatically during login and I need a password to turn it off. I can disconnect it by signing out, but I can't prevent it from starting altogether. I don't have my laptop with me currently, but when next I get on, I'll get you the info from /var/db/dhcpd_leases filtered to name=lima-0
q
Hi. Sorry to chime in, but I have the same issue.
It worked before but after an factory-reset I only get IPv6. I'm on an M1
f
@quaint-memory-32205 Can you provide more information about your setup? Are you also on a VPN? If yes, can you start the machine without the VPN and see if you get an IPv4 address then? Is this an enterprise-managed machine with an MDM profile?
q
Sure. MDM managed MacOS 14.3.1, RD 1.12.3, It doesn't make a difference with or without VPN. It did work. well until I upgraded MacOS from 14.3. to 14.3.1 yesterday. I first could hard code 
TESTCONTAINERS_HOST_OVERRIDE
to the IP it was set before which worked. I then did a 
factory-reset
to see if it helps. But since then the "hack" also doesn't work anymore. I checked with some users in our company and got mixed results. For users that run 14.3 it still seems to work. With some users running 14.3.1 also. But some users running 14.3.1 also have the same issue.
Copy code
$ rdctl shell ip a show vznat
3: vznat: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:55:55:c0:20:94 brd ff:ff:ff:ff:ff:ff
    inet6 fdd0:fddf:f57b:2dc5:5055:55ff:fec0:2094/64 scope global dynamic flags 100
       valid_lft 2591972sec preferred_lft 604772sec
    inet6 fe80::5055:55ff:fec0:2094/64 scope link
       valid_lft forever preferred_lft forever
Copy code
$ cat /var/db/dhcpd_leases
{
	name=lima-0
	ip_address=192.168.205.2
	hw_address=1,52:55:55:c0:20:94
	identifier=1,52:55:55:c0:20:94
	lease=0x65cdf9a4
}
{
	name=lima-0
	ip_address=192.168.106.3
	hw_address=1,52:55:55:c0:20:94
	identifier=1,52:55:55:c0:20:94
	lease=0x65b7d515
}
{
	name=colima
	ip_address=192.168.106.2
	hw_address=1,52:55:55:e4:8a:8f
	identifier=1,52:55:55:e4:8a:8f
	lease=0x658d806d
}
f
I just checked on my 14.3.1 machine, and it also still works
Ok, so you get IP addresses assigned by DHCP, but they aren't being used by the interfaces. I see you are using 
colima
, does it have the same issue?
q
I have used it before but have uninstalled to switch to RD. I'll reinstall it. What is the equivalent command for 
rdctl shell ip a show vznat
?
f
For 
colima
? I don't know, but I'll try to find out 🙂
I'm also curious about this entry from your leases file:
Copy code
{
	name=lima-0
	ip_address=192.168.106.3
	hw_address=1,52:55:55:c0:20:94
	identifier=1,52:55:55:c0:20:94
	lease=0x65b7d515
}
It matches the Rancher Desktop instance name, and has the same MAC address as the other request, but gets an IP address from the default 
host
subnet (which isn't used by Rancher Desktop, but would also be in the 
192.168.206.0/24
range if it was used via 
Rancher Desktop
).
You have to start 
colima
with 
colima start --network-address
to get a routable network address. You can then check the address with:
Copy code
$ colima ssh ip a show col0
3: col0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:55:55:88:a5:c7 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 192.168.106.3/24 metric 100 brd 192.168.106.255 scope global dynamic col0
       valid_lft 86366sec preferred_lft 86366sec
    inet6 fd41:7e08:f19:ac03:5055:55ff:fe88:a5c7/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591985sec preferred_lft 604785sec
    inet6 fe80::5055:55ff:fe88:a5c7/64 scope link
       valid_lft forever preferred_lft forever
And I got the 
host
network address that was also in your leases file: 
192.168.106.3
This is plausible; however I still have no idea how you could have ended up with this address for a Rancher Desktop interface.
Anyways, this is how I tested it with 
colima
right now, so I'm curious if you have the same IPv4 issue with 
colima
on this machine.
q
Seems to be the same
Copy code
$ colima ssh ip a show col0
3: col0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:55:55:e4:8a:8f brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet6 fdae:811c:424c:a982:5055:55ff:fee4:8a8f/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591988sec preferred_lft 604788sec
    inet6 fe80::5055:55ff:fee4:8a8f/64 scope link
       valid_lft forever preferred_lft forever
f
Are you using QEMU or VZ. If you are using QEMU, could you take a look at 
~/Library/Application\ Support/rancher-desktop/lima/0/serial.log
to see if there are any errors from DHCP in there?
Same for `colima`: any DHCP error messages in 
~/.lima/colima/serial*.log
Successful output (for Rancher Desktop) looks like this:
Copy code
*   eth0 ...udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: broadcasting select for 192.168.5.15, server 192.168.5.2
udhcpc: lease of 192.168.5.15 obtained from 192.168.5.2, lease time 86400
 [ ok ]
 *   rd1 ...udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: broadcasting select for 192.168.205.2, server 192.168.205.1
udhcpc: lease of 192.168.205.2 obtained from 192.168.205.1, lease time 86400
 [ ok ]
 *   rd0 ...udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: broadcasting select for 192.168.18.119, server 192.168.17.1
udhcpc: lease of 192.168.18.119 obtained from 192.168.17.1, lease time 86400
 [ ok ]
👀 1
Ok, the 
colima
log location was for an older version; it is now at 
~/.colima/_lima/colima/serial.log
and looks different because 
colima
switched to Ubuntu and cloud-init
Please confirm that you tested with latest colima (0.6.8).
q
I don't find any of those. Am I looking at the right file? 
~/Library/Application\ Support/rancher-desktop/lima/0/serial.log
serial.log
Copy code
$ colima --version
colima version 0.6.8
f
Yes, it is the right log, but it doesn't show the DHCP output because it is the VZ log, not QEMU.
It may be helpful to just run with QEMU once, to see if we can get an error message that way, but first please take a look at the files inside 
~/Library/Application Support/rancher-desktop/lima/_networks
and check if any are non-empty
q
I started it with 
rdctl start --experimental.virtual-machine.type qemu
f
You did? Is this ARM or Intel?
q
ARM
f
Let me double-check
I'm sorry, you are right, this is only in the Intel version of the log 😞
Wait, the file is 
serialp.log
. I need to figure out why these are not using consistent names
q
Look more like what you posted 😀. Looking into it.
searched for but could only find 
udhcpc
Copy code
* Starting networking ... *   lo ... [ ok ]
 *   eth0 ...udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: broadcasting select for 192.168.5.15, server 192.168.5.2
udhcpc: lease of 192.168.5.15 obtained from 192.168.5.2, lease time 86400
f
You need to enable admin mode to get the routable interfaces
q
Copy code
* Starting networking ... *   lo ... [ ok ]
 *   eth0 ...udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: broadcasting select for 192.168.5.15, server 192.168.5.2
udhcpc: lease of 192.168.5.15 obtained from 192.168.5.2, lease time 86400
 [ ok ]
 *   rd1 ...udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc failed to get a DHCP lease
udhcpc: no lease, forking to background
 [ ok ]
 *   rd0 ...udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: broadcasting select for 192.168.178.118, server 192.168.178.1
udhcpc: lease of 192.168.178.118 obtained from 192.168.178.1, lease time 864000
f
So you should have an IPv4 address for 
rd0
but not for 
rd1
now?
q
correct
Copy code
$ rdctl shell ip a show rd0
4: rd0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:55:55:0b:1c:1a brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.118/24 brd 192.168.178.255 scope global rd0
       valid_lft forever preferred_lft forever
    inet6 fe80::5055:55ff:fe0b:1c1a/64 scope link
       valid_lft forever preferred_lft forever
f
So right now things should be working because 
rd1
is only used when 
rd0
doesn't have an address.
It currently looks to me like Apple introduced a bug that make VMNET DHCP flaky in the 14.3.1 release. I don't have any ideas right now how to deal with it 😞
q
But at least I know now how to debug this 🙂. Thanks for helping out. I'll call it a day for know.
f
Can you take a look at 
/etc/bootpd.plist
(or share it with me) to see if there is something interesting there on the machines that don't support IPv4?
I mean 
/etc/bootpd.plist
on macOS, not the VM.
q
Copy code
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "<http://www.apple.com/DTDs/PropertyList-1.0.dtd>">
<plist version="1.0">
<dict>
	<key>Subnets</key>
	<array>
		<dict>
			<key>_creator</key>
			<string>com.apple.NetworkSharing</string>
			<key>allocate</key>
			<true/>
			<key>dhcp_domain_name_server</key>
			<array>
				<string>192.168.205.1</string>
			</array>
			<key>dhcp_router</key>
			<string>192.168.205.1</string>
			<key>interface</key>
			<string>bridge100</string>
			<key>lease_max</key>
			<integer>86400</integer>
			<key>lease_min</key>
			<integer>86400</integer>
			<key>name</key>
			<string>192.168.205/24</string>
			<key>net_address</key>
			<string>192.168.205.0</string>
			<key>net_mask</key>
			<string>255.255.255.0</string>
			<key>net_range</key>
			<array>
				<string>192.168.205.2</string>
				<string>192.168.205.254</string>
			</array>
		</dict>
	</array>
	<key>bootp_enabled</key>
	<false/>
	<key>detect_other_dhcp_server</key>
	<array>
		<string>bridge100</string>
	</array>
	<key>dhcp_enabled</key>
	<array>
		<string>bridge100</string>
	</array>
	<key>dhcp_ignore_client_identifier</key>
	<true/>
	<key>ignore_allow_deny</key>
	<array>
		<string>bridge100</string>
	</array>
	<key>use_server_config_for_dhcp_options</key>
	<true/>
</dict>
</plist>
f
Thanks, looks completely normal
q
I noticed that before I had the issue 
rdctl shell ip a show rd0
returned 
192.168.205.2
which is in
Copy code
<key>net_range</key>
			<array>
				<string>192.168.205.2</string>
				<string>192.168.205.254</string>
			</array>
Now I get 
192.168.178.118
f
Are you sure? 
192.168.205.2
is from the "shared" network subnet which would be used by 
rd1
. 
192.168.178.118
should be from your local LAN DHCP
When you go to "System Settings" on your machine and search for "Profiles", do you have anything installed there, e.g. some security profile from Jamf Pro or similar? If yes, can you scroll through the entries in the profile if anything seems related?
Otherwise, do you have any 3rd-party firewall software installed on the machine?
I've asked my fellow Lima maintainers, and they don't have any concrete suggestions either 😞
q
You're right. 
192.168.205.2
was from 
rd1
. Sorry but I'm not very experienced with the network stuff. what is the difference between rd0 and rd1?
f
rd0
is a bridged network and 
rd1
is a local shared network with a NAT gateway. We only defined 
rd1
because 
rd0
sometimes doesn't get an IPv4 address. E.g. some networks don't allow multiple IP addresses on a single MAC address.
This is not a diagram for Rancher Desktop but it does show the way networks are configurable with Lima:
q
Could this have happened when I went to the office on Friday? I normally work from home.
f
Rancher Desktop uses 
192.168.205.0/24
instead of 
192.168.105.0/24
for the shared network to be separate from other Lima instances
Yes, that is totally possible, at least for 
rd0
to not get an IP address. But you should always get one for 
rd1
(or for 
vznat
when using VZ).
The bridged network gets the address from your LAN, which is out of our control. But the shared network is local to your machine, and I don't understand why it wouldn't get an IP, regardless of what the LAN is trying to enforce because it is not directly connected to the LAN, but only through the NAT gateway
Maybe you should do a reboot to make sure any remaining effects from the office network are forgotten, and then see which networks get IP addresses.
I will have to drop real soon though, as it is after midnight here right now
q
Ok. thanks for helping. My day just started 🙂. See you 👋
8 Views
Open in Slack
PreviousNext
Powered by