Druid
November 21, 2020, 12:08am
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
tomp
(Thomas Parrott)
November 21, 2020, 12:09am
22
And does manually removing that IP and manually running the dhcp client like I showed you work?
Druid
November 21, 2020, 8:42pm
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?)
tomp
(Thomas Parrott)
November 23, 2020, 9:06am
24
Are you running a non-standard kernel?
This reminds me of this thread:
Hey Forum – this feels like a basic question with a basic networking answer that I ought to be able to find with google, but I’ve so far struck out.
I’m running Linux for Tegra (based on Ubuntu 18.04) on an NVIDIA Jetson TX2. I’m trying to make use of LXD containers for a few topics and am struggling with networking. Here’s my setup steps:
sudo snap install lxd
sudo lxd init
[accept the defaults for all values]
lxc launch ubuntu:18.04 test
lxc ls
The output of lxc ls shows that my container h…
Druid
November 23, 2020, 10:33am
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.
Druid
November 24, 2020, 11:10pm
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?
tomp
(Thomas Parrott)
November 24, 2020, 11:29pm
27
Sounds correct to me.
You may find running a privileged container works on your current kernel, albeit less secure.
Druid
November 25, 2020, 2:58pm
28
In privileged mode container gets an ipv4 address.
1 Like