You are probably correct. However it appears to listening on the DHCP ports and dnsmasq isn’t.
Note LXD runs its own dnsmasq so avoid running your own or make sure it’s not listening on all interfaces.
Hm, I’ve checked rfc. And it says dhcp client should live on port 68. That is what dhcpcd is doing there. It doesn’t look wrong to me. Wouldn’t any Ubuntu/Debian have some sort of dhcp client sitting on port 68 by default? So anyone who installs lxd with built-in dnsmasq would have a conflict?
I stopped dhpcd.service and restarted snap.lxd.daemon. dnsmasq was still sitting on port 67. I restarted container and it didn’t get its ip. So I assigned a static ip to a container and restarted it. It didn’t get ip again.
Does it look as correct config with a static ip?
rock@rockpi4a:~$ lxc config show postgresql --expanded
architecture: aarch64
config:
image.architecture: arm64
image.description: Alpine 3.10 arm64 (20201118_13:00)
image.os: Alpine
image.release: "3.10"
image.serial: "20201118_13:00"
image.type: squashfs
image.variant: default
user.network-config: |
version: 1
config:
- type: physical
name: eth0
subnets:
- type: dhcp
ipv4: true
volatile.base_image: 03dd52a03cdc01c2c0d61672cc4eb817a982a665cea3d56f88b53bf3e569847b
volatile.eth0.host_name: veth81f7ca1e
volatile.eth0.hwaddr: 00:16:3e:25:56:ef
volatile.idmap.base: "0"
volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
volatile.last_state.power: RUNNING
volatile.uuid: 9653378f-803d-410a-845b-0a855df67871
devices:
eth0:
ipv4.address: 10.99.10.42
name: eth0
nictype: bridged
parent: lxdbr0
type: nic
root:
path: /
pool: rock_pool
type: disk
ephemeral: false
profiles:
- privatenetwork
stateful: false
description: ""
Assigning a static IP via LXD config isn’t going to check whether network is working and its just DHCP that is broken as LXD static IP assignments are just static DHCP leases, i.e it needs DHCP to work.
Use ip a add x.x.x.x.x/24 dev eth0 inside your container instead and then try to ping the lxdbr0 address.
As for dhcpc, I double checked and you’re right, its not listening on port 67, only dnsmasq is, so that is a mistake, I read the wrong line when horizontally scrolling the output.
Although for what its worth I see no persistent dhcp client process listening on port 68 on my ubuntu desktop, but either way it shouldnt affect dnsmasq.
Also have you tried running a manual dhcp client inside your container, just to check its not a configuration issue cause by cloud-init in your profile?
Should x.x.x.x.x/24 be the same as what I defined for lxdbr0 on a host machine? I assumed, yes…
So now I have this in my container.
~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:16:3E:25:56:EF
inet addr:10.163.223.1 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::216:3eff:fe25:56ef/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:60 errors:0 dropped:0 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10008 (9.7 KiB) TX bytes:1925 (1.8 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:528 (528.0 B) TX bytes:528 (528.0 B)
Did you mean to ping lxdbr0 from a container or from a host?
rock@rockpi4a:~$ lxc list
+------------+---------+---------------------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------------+---------+---------------------+------+-----------+-----------+
| postgresql | RUNNING | 10.163.223.1 (eth0) | | CONTAINER | 0 |
+------------+---------+---------------------+------+-----------+-----------+
I don’t think Alpine has a dhcp client there… I can try another image actually. But my main goal is alpine really.
No it shouldnt be 10.163.223.1 as that is the same IP as the bridge, if you do that you will guarantee conflicts with the bridge address and break connectivity.
You should choose any IP apart from that in the same /24 subnet as lxdbr0.
So I tried another ip
rock@rockpi4a:~$ lxc list
+------------+---------+---------------------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------------+---------+---------------------+------+-----------+-----------+
| postgresql | RUNNING | 10.163.223.2 (eth0) | | CONTAINER | 0 |
+------------+---------+---------------------+------+-----------+-----------+
rock@rockpi4a:~$ ping 10.163.223.2
PING 10.163.223.2 (10.163.223.2) 56(84) bytes of data.
From 10.163.223.1 icmp_seq=1 Destination Host Unreachable
From 10.163.223.1 icmp_seq=2 Destination Host Unreachable
From 10.163.223.1 icmp_seq=3 Destination Host Unreachable
From 10.163.223.1 icmp_seq=4 Destination Host Unreachable
Here’s an example.
- Simulate a DHCP fault on the host by disabling DHCP services on lxdbr0:
lxc network set lxdbr0 ipv4.dhcp false
- Launch alpine container and check for no IPv4:
lxc launch images:alpine/3.12 c1
lxc ls
+------+---------+------+-----------------------------------------------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+---------+------+-----------------------------------------------+-----------+-----------+
| c1 | RUNNING | | fd42:6433:2aa7:637d:216:3eff:fed7:e8b2 (eth0) | CONTAINER | 0 |
+------+---------+------+-----------------------------------------------+-----------+-----------+
- Add manual IP to container and test ping to bridge:
lxc exec c1 -- ip a add 10.143.8.2/24 dev eth0
lxc exec c1 -- ping 10.143.8.1
PING 10.143.8.1 (10.143.8.1): 56 data bytes
64 bytes from 10.143.8.1: seq=0 ttl=64 time=0.104 ms
64 bytes from 10.143.8.1: seq=1 ttl=64 time=0.153 ms
- Re-enable DHCP on network and test manual DHCP client:
lxc stop c1
lxc start c1
lxc network set lxdbr0 ipv4.dhcp true
lxc exec c1 -- udchpc
lxc ls
+------+---------+--------------------+-----------------------------------------------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------+---------+--------------------+-----------------------------------------------+-----------+-----------+
| c1 | RUNNING | 10.143.8.84 (eth0) | fd42:6433:2aa7:637d:216:3eff:fed7:e8b2 (eth0) | CONTAINER | 0 |
+------+---------+--------------------+-----------------------------------------------+-----------+-----------+
Can you show ip r inside container once you have added address please I want to check you specified the subnet correctly.
My mistake. You are right. Wrong subnet. Now I can ping from the host at least.
rock@rockpi4a:~$ lxc exec postgresql /bin/ash
~ # ip a add 10.163.223.2/24 dev eth0
~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
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
6: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:16:3e:25:56:ef brd ff:ff:ff:ff:ff:ff
inet 10.163.223.2/24 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe25:56ef/64 scope link
valid_lft forever preferred_lft forever
~ # exit
rock@rockpi4a:~$ lxc list
+------------+---------+---------------------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------------+---------+---------------------+------+-----------+-----------+
| postgresql | RUNNING | 10.163.223.2 (eth0) | | CONTAINER | 0 |
+------------+---------+---------------------+------+-----------+-----------+
rock@rockpi4a:~$ ping 10.163.223.2
PING 10.163.223.2 (10.163.223.2) 56(84) bytes of data.
64 bytes from 10.163.223.2: icmp_seq=1 ttl=64 time=0.475 ms
64 bytes from 10.163.223.2: icmp_seq=2 ttl=64 time=0.215 ms
64 bytes from 10.163.223.2: icmp_seq=3 ttl=64 time=0.220 ms
And does manually removing that IP and manually running the dhcp client like I showed you work?
I think I have more serious problems in my setup or in rockhip image rather than dhcp.
rock@rockpi4a:~$ lxc exec c1 -- ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
ping: permission denied (are you root?)
Are you running a non-standard kernel?
This reminds me of this thread:
Yes. I think it is a custom kernel. I raised the question on Radxa forum to see if they can confirm that there might be a problem with how capabilities are read in kernel for example.
I think radxa’s kernel sources are here. I can see that they have this check in af_inet.c:
capable(CAP_NET_RAW)
But instead they should have used
ns_capable(net->user_ns, CAP_NET_RAW)
Is that correct?
Sounds correct to me.
You may find running a privileged container works on your current kernel, albeit less secure.
In privileged mode container gets an ipv4 address.
1 Like