Not completely true - because host, and therefore the container, is using kernel 5.10.
The mentioned new test-container (replicated by zfs), has been directly created on
devuan host using kernel 6.5 and does not have that problem running on the debian
host with kernel 5.10.
And indeed, it is strange - there will be no users, but services running as non-root.
I keep it in mind, when my new squid will come (which uses ping and so far I remember
right, form the non-root running process).

Regards,
Manfred

Slightly odd though that you don't have the same with your debian setup, but perhaps that non-root user is more capable(?). (As we often find repeated: the packages in devuan are mostly debian's packages directly and not changed, other than the few that are forked and compiled by devuan)

Found someone, who knows the bug.
Part of the message appears, if ipv6 has been disabled (everywhere in my infra), and I know this.
Came to the idea, to supply the "-4" switch (not neccessary) - and this show a complete different message:

$ pc2 -4 192.168.26.88
ping: socktype: SOCK_RAW
ping: socket: Operation not permitted                            <===
ping: => missing cap_net_raw+p capability or setuid?  <===

This was the same as in an older forum message with the same symptom, but this was hardware,
not a container. I compared working and non-working container, with no ideas.
But the leads to another websearch, which reveals the bug in a googl group:

After I set this value into sysctl.conf and applied, it works!
Have never seen or used it and like the poster said:

from the default images repository

So this came from install sources.
I just duplicated another working container using zfs send/recv (from devu5 container on devu5 hardware) to
debian (where the devuan container live). The only change I had to do, was to replace:

lxc.include = /usr/share/lxc/config/devuan.common.conf
to:
lxc.include = /usr/share/lxc/config/debian.common.conf

So its not the "copying" of the container.

But thanks for all help!
Regards,
Manfred

@ralf, the interfaces are defined in the containers config file like this:

lxc.net.0.type = veth
lxc.net.0.name = eth0
lxc.net.0.veth.pair = ct-eth0
lxc.net.0.link = hovmbr
lxc.net.0.flags = up

#lanbr - optional, but now under test

lxc.net.1.type = veth
lxc.net.1.name = eth1
lxc.net.1.veth.pair = ct-eth1
lxc.net.1.link = lanbr
lxc.net.1.flags = up

Both end up in a bridge of the host (the first terminates at the host).
This usually works always and I rarely need others (but used macvtap, hardware).
All containers using this schema (debian + devuan), the debian'eses are working.
Using 'ip link' they appear like an ethernet interface.
Exact the same works on a devuan5 container on a devuan hardware.
For root, it works. For other usual users not (added another one for testing).
The users are only in their own and in the users group.
All firewall restriction have been removed on container AND host.
No ping is going out, ether which interface (destionation addr will be used).
A tcpdump does not show any outgoing packets (not even arp).
And the shown destination address has been random (though existing, running node),
it effects all - the routes are correct too (root has no different routing and it works).
---
@trinidad, that address is not my gateway, have never been it and something
linke wlan is NOT present.

Regards,
Manfred

If it uses some pcap connection (like "user" networking in qemu), then it would only support IP level networking and ICMP would not be supported. I agree it's an LXC (on Devuan) issue although it may also be an admin choice of local networking. (I don't know LXC well enough to tell).

How is your networking set up?

The container has been created by zfs send/recv, which worked in my experience.
BTW, the other containers, using debian 10/11/12 use exactly this same kernel.
Why should ping work with them?
Why can I even install a devuan-lxc on the same box?

Thanks,
Manfred

Probably someone could shed some light onto this:

ping -c2 192.168.26.252
ping: socktype: SOCK_DGRAM
ping: socket: Address family not supported by protocol

System:

~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 5 (daedalus)
Release:	5
Codename:	daedalus
Linux devu5test 5.10.0-0.bpo.9-amd64 #1 SMP Debian 5.10.70-1~bpo10+1 (2021-10-10) x86_64 GNU/Linux

This not an exception - I am "on the road" to replace my debian infra with devuan and starting
with containers. All behave the same.
Wether on debian 10/11/12 lxc-containers have that problem.
There are no firewall/iptables restrictions in use making this tests.
I read in another thread (from 2024 in galaxy) that this even happend on hardware,
which - at least - my first and only hardware installtion does not have.
I generally install iputils-ping. it has nothing to do with interfaces and routes, I use
always the same structures.

Thanks,,
Manfred