Some points regarding new version 3.2.0.

[Alan DeKok]

On Aug 20, 2022, at 6:11 PM, CpServiceSPb <cpservicespb at gmail.com> wrote:
> 
> There is Ubuntu 18.04 LTS x64 noGUI with kernel 5.4.0-124.
> I built deb packages from sources using deb rules downloaded
> freeradius_3.2.0+dfsg-1.debian.tar.xz
> <http://archive.ubuntu.com/ubuntu/pool/main/f/freeradius/freeradius_3.2.0+dfsg-1.debian.tar.xz>

  There's also the packages available at http://packages.networkradius.com.  Those work.

> Having done some changes, and created some patches I successfully built
> Freeradius of 3.2.0 version as well as launched successfully on my system.
> But there are some different points in comparison with 3.0.25 one.
> 
> 1. If  Freeradius is launched from freerad user (non-root) and interface/IP
> binding is set up, ,error is got:
> Failed binding to interface eth0: Operation not permitted
> Error: /etc/freeradius/sites-enabled/default[59]: Error binding to port for
> 192.168.0.254 port 1812

  That's a local OS / security problem.  It has nothing to do with FreeRADIUS.

  Something on your system says that normal programs can't bind to a particular interface.  You can fix this by fixing your local OS so that it doesn't prevent FreeRADIUS from working.

  i.e. the server isn't binding to a privileged port.  So there shouldn't be any issue with opening a socket.

> Uncommenting of
> #AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST
> CAP_NET_RAW CAP_SETUID CAP_SETGID CAP_CHOWN CAP_DAC_OVERRIDE
> didn' t solve the situation.

  That's a systemd file which doesn't come with FreeRADIUS.  It's local to your OS.  You'll have to see the systemd documentation for how to allow this.

> Run setcap cap_net_admin=ei /usr/bin/freeradius
> didn' t solve the situation.

  That's similarly an issue with the local OS.  

> Changing of User=freerad to User=root in freeradius.service solved this.

  While that works, it's generally not a good idea to run anything as root.

> During this, user in radiusd.conf wasn' t touched at all, that is it
> remained freerad.

  That only applies after the server has started, IF it's started as root.

> At the time freeradius is shown as launched from freerad user.
> Is this correct ?

  Maybe.  What's happening now is that systemd is starting FreeRADIUS as root.  FreeRADIUS is then opening the ports it needs.  And then FreeRADIUS switches to user "freerad".

> Or what way is the right one to solve this situation ?

  Poke at the systemd / setcap documentation to see how to configure them,

> 2. There is /usr/sbin/freeradius -f in the processes list, not simply
> /usr/sbin/freeradius as was with the previous version (for example 3.0.21) .
> As follows, pid file is not created.
> Is this correct ?

  That's how systemd works, yes.

> 3. File cache_eap absence among available modules as it was with previous
> versions.
> Is it correct ?

  I don't understand this kind of question.  There are a lot of changes between various versions of the server.  So?  What's the problem?

  Are you using the cache_eap module?  If not, why waste your time a	asking questions about it?

  If you are using it, then ask a GOOD question, like "I'm using this module, why was it deleted, and what else can I use?"

> 4. What is the best value for "key' in the ippool module for pxe and common
> dhcp clients ?
> With value "%{NAS-IP_Address} %{NAS-Port}" IP addresses sometimes are not
> assigned at all to clients.

  You can't use the same ipppool module configuration for RADIUS and for DHCP.  You need to configure two modules, one for RADIUS, and one for DHCP.

> Why, I don' t understand.
> Deleting the DB, restarting  Freeradius and repeated requests (for example
> ipconfig /renew) temporarily helped me with it.

  Reading the debug output would help here.  Randomly restarting things doesn't help you understand what's going wrong.

  Alan DeKok.