Dear Alan, The tcpdump output from FR3.0.23 server listening on the interface enp5s0 (the only interface of the server) definitely shows that FR has received Status-Server message: $ sudo tcpdump -i enp5s0 port 1812 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes 10:08:51.557705 IP 192.168.1.13.54094 > politex.radius: RADIUS, Status-Server (12), id: 0x00 length: 38 10:09:22.557619 IP 192.168.1.13.54094 > politex.radius: RADIUS, Status-Server (12), id: 0x00 length: 38 10:09:48.557700 IP 192.168.1.13.54094 > politex.radius: RADIUS, Status-Server (12), id: 0x00 length: 38 192.168.1.13 is the FLR server which configured as a client to server politex (192.168.1.130). 192.168.1.13 sends three Status-Server requests to 192.168.1.130 host with installed FR3.0.23, but no response. Regards, Talgat On Wednesday, June 16, 2021, 07:01:54 PM GMT+6, Alan DeKok <aland@deployingradius.com> wrote: On Jun 16, 2021, at 6:38 AM, Tal Nur via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Recently I installed FR 3.0.23 as Eduroam IdP&SP server for one university in my country. Installation was ok. But when I tested the exchange of Radius messages between country federated level radius server (192.168.1.13) and the university FR (192.168.1.130) I didn't see responses to Status-Server request. The another university FR3.0.16 responded with Access-Accept message according rfc5997.
It works for me when I test it here.
Here is two output:
Output of FR3.0.23 without response admin@politex:~$ sudo tcpdump -i enp5s0 port 1812
We don't need to see tcpdump output. See http://wiki.freeradius.org/list-help
Below the output of FR3.0.23 freeradius -X: ... Ready to process requests
Which doesn't show it receiving any packets. See http://wiki.freeradius.org/list-help My guess is that FreeRADIUS isn't receiving the Status-Server packets. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html