[rockchip][lxd] Yet another "I cannot get IPv4 assigned to a container"

LXD
,
#21

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
#22

And does manually removing that IP and manually running the dhcp client like I showed you work?

#23

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?)
#24

Are you running a non-standard kernel?

This reminds me of this thread:

#25

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.

#26

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?

#27

Sounds correct to me.

You may find running a privileged container works on your current kernel, albeit less secure.

#28

In privileged mode container gets an ipv4 address.

1 Like