Freeradius DHCP and "Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1)"
I use Freeradius 3.0.21 on Ubuntu 18.04 x64 LTS. It is started under freerad:freerad, acts as DHCP as well listen to 0.0.0.0 IP and accept broadcast on one of two interfaces and listen to 192.168.0.254 and not accept broadcast on other one interface. During DHCP conversation with clients using broadcast accepting (IP 0.0.0.0) interface, the following message is got and DHCP don' t assign to the client: "Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1)" I don' t want to launch Freeradius under either root user or root/admin group. What is the best solution to avoid the error under freerad:freerad and move on ?
On Jul 29, 2021, at 7:30 PM, CpServiceSPb <cpservicespb@gmail.com> wrote:
I use Freeradius 3.0.21 on Ubuntu 18.04 x64 LTS.
It is started under freerad:freerad, acts as DHCP as well listen to 0.0.0.0 IP and accept broadcast on one of two interfaces and listen to 192.168.0.254 and not accept broadcast on other one interface.
During DHCP conversation with clients using broadcast accepting (IP 0.0.0.0) interface, the following message is got and DHCP don' t assign to the client: "Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1)"
I don' t want to launch Freeradius under either root user or root/admin group.
What is the best solution to avoid the error under freerad:freerad and move on ?
Linux capabilities. See sites-available/dhcp. Look for "setcap". If it's not there, upgrade to a more recent version. Alan DeKok.
On 30/07/2021 01:17, Alan DeKok wrote:
On Jul 29, 2021, at 7:30 PM, CpServiceSPb <cpservicespb@gmail.com> wrote:
During DHCP conversation with clients using broadcast accepting (IP 0.0.0.0) interface, the following message is got and DHCP don' t assign to the client: "Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1)"
I don' t want to launch Freeradius under either root user or root/admin group.
What is the best solution to avoid the error under freerad:freerad and move on ?
Linux capabilities. See sites-available/dhcp. Look for "setcap". If it's not there, upgrade to a more recent version.
Would be worth seeing if this PR fixes it https://github.com/FreeRADIUS/freeradius-server/pull/4150 Or just launch as root and let FreeRADIUS drop privs, as it has done just fine for years before systemd barged on to the scene and broke everything. -- Matthew
I tried sudo setcap cap_net_admin=ei /usr/sbin/freeradius. Then I checked that it is set up by getcap /usr/sbin/freeradius and it was /usr/sbin/freeradius = cap_net_admin+ei But there is still Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1) Also I tried to freerad ALL = (root) NOPASSWD: /usr/sbin/arp to sudoers.d file, result is negative. Only launching from root user (commenting user = freerad) helps. But I don' t run it from root. пт, 30 июл. 2021 г. в 02:30, CpServiceSPb <cpservicespb@gmail.com>:
I use Freeradius 3.0.21 on Ubuntu 18.04 x64 LTS.
It is started under freerad:freerad, acts as DHCP as well listen to 0.0.0.0 IP and accept broadcast on one of two interfaces and listen to 192.168.0.254 and not accept broadcast on other one interface.
During DHCP conversation with clients using broadcast accepting (IP 0.0.0.0) interface, the following message is got and DHCP don' t assign to the client: "Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1)"
I don' t want to launch Freeradius under either root user or root/admin group.
What is the best solution to avoid the error under freerad:freerad and move on ?
On Aug 1, 2021, at 5:18 PM, CpServiceSPb <cpservicespb@gmail.com> wrote:
I tried sudo setcap cap_net_admin=ei /usr/sbin/freeradius. Then I checked that it is set up by getcap /usr/sbin/freeradius and it was /usr/sbin/freeradius = cap_net_admin+ei
That should work.
But there is still Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1)
It might be an issue with the OS. Maybe also try upgrading FreeRADIUS. But... this is all complex, and to be honest, Linux capabilities are not entirely simple. We're doing our best, but it's impossible to know for sure if it works everywhere.
Also I tried to freerad ALL = (root) NOPASSWD: /usr/sbin/arp to sudoers.d file, result is negative.
The server doesn't run the "arp" command. That change isn't necessary.
Only launching from root user (commenting user = freerad) helps. But I don' t run it from root.
You shouldn't run it as root. Alan DeKok.
Then I checked that it is set up by getcap /usr/sbin/freeradius and it was /usr/sbin/freeradius = cap_net_admin+ei
That should work.
But there is still Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1)
Hi I ran into this issue and did some investigation. What I found was that if you set the permissions as follows: setcap cap_net_admin,cap_net_bind_service=eip /usr/local/sbin/radiusd This works as long as you do not launch FreeRADIUS as root. So for example I have a normal user called "radius" specified in radiusd.conf: security { user = radius group = radius ... } This does not work: root@computer# radiusd -X This works: radius@computer$ radiusd -X So what seems to be happening is that although we assign the capabilities to the radiusd executable, if we launch as a different user to what is in radiusd.conf then those capabilities are lost when FreeRADIUS switches user. I also tried adding "ambient" capabilities as follows: capsh --caps="cap_setpcap,cap_setuid,cap_setgid,cap_net_admin,cap_net_bind_service+eip" --keep=1 --user=radius --addamb=cap_net_admin,cap_net_bind_service -- -c "/usr/local/sbin/radiusd -X" This also works fine. -- Benjamin Thompson
I may be wrong. But I detected that the issue appears for udp 0 0.0.0.0:67 only. If there is udp unicast_IP:67 (for example udp 192.168.0.254:67 - packets receiving from relays) , there is no such issue. I tried sudo setcap cap_net_admin=ei /usr/sbin/freeradius. Then I checked that it is set up by getcap /usr/sbin/freeradius and it was /usr/sbin/freeradius = cap_net_admin+ei But there is still Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1) Also I tried to freerad ALL = (root) NOPASSWD: /usr/sbin/arp to sudoers.d file, result is negative. Only launching from root user (commenting user = freerad) helps. But I don' t run it from root. пт, 30 июл. 2021 г. в 02:30, CpServiceSPb <cpservicespb@gmail.com>:
I use Freeradius 3.0.21 on Ubuntu 18.04 x64 LTS.
It is started under freerad:freerad, acts as DHCP as well listen to 0.0.0.0 IP and accept broadcast on one of two interfaces and listen to 192.168.0.254 and not accept broadcast on other one interface.
During DHCP conversation with clients using broadcast accepting (IP 0.0.0.0) interface, the following message is got and DHCP don' t assign to the client: "Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1)"
I don' t want to launch Freeradius under either root user or root/admin group.
What is the best solution to avoid the error under freerad:freerad and move on ?
On Aug 2, 2021, at 3:57 PM, CpServiceSPb <cpservicespb@gmail.com> wrote:
I may be wrong. But I detected that the issue appears for udp 0 0.0.0.0:67 only. If there is udp unicast_IP:67 (for example udp 192.168.0.254:67 - packets receiving from relays) , there is no such issue.
Yes... if the address is unicast, then ARP works. FreeRADIUS could create DHCP packets itself and send them. But that also requires opening a "raw" socket. So it will still need special permissions. Alan DeKok.
participants (4)
-
Alan DeKok -
Benjamin Thompson -
CpServiceSPb -
Matthew Newton