August 2020 - Freeradius-Users - lists.freeradius.org

query on freeradius-server ocsp function and rlm_unbound
by SIMON BABY 19 Aug '20

19 Aug '20

Hello, My name is Simon and I am new to this group. I have some basic queries regarding the ocsp functionality in freeradius-server code. I am referring to the file freeradius-server-3.0.17/src/main/tls.c with below code sample. RDEBUG2("ocsp: Using responder URL \"http://%s:%s%s\"", host, port, path); /* Check host and port length are sane, then create Host: HTTP header */ if ((strlen(host) + strlen(port) + 2) > sizeof(hostheader)) { RWDEBUG("ocsp: Host and port too long"); goto skipped; } snprintf(hostheader, sizeof(hostheader), "%s:%s", host, port); /* Setup BIO socket to OCSP responder */ cbio = BIO_new_connect(host); 1. How are we resolving the OCSP responder IP address from the name server ? Are we using DNS/DNSSEC (unbound APIs) ? 2. Do we really need to do DNSSEC validation for resolving OCSP domain names? 3. May I know in which file the BIO_ APIs are implemented? 4. what is the use of the rlm_unbound module in freeradius-server package? Can I use it for resolving OCSP name servers? If so, May I know the process to use it. Thank you for you time. Regards Simon

3 5

FR 3.0.21 on Debian Buster delivering strange cert+chain?
by Martin Pauly 19 Aug '20

19 Aug '20

Hi all, I'm getting an obscure effect with FR 3.0.21 on a fresh Debian Buster installation (I compiled myself from the download package). Despite an identical config (as compared to the predecessor with FR 3.017 on Debian Jessie), some clients will not match the server cert to the chain provided. Seemingly, these are all Apple supplicants and also eapol_test, see attached output Any idea what's going wrong? I've just seen there is FR 3.0.21 on buster-backports, are there any related changes in there? TIA, Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly(a)HRZ.Uni-Marburg.DE D-35032 Marburg

3 9

Having issues interpreting ldap search/filter attributes
by Steve Phillips 19 Aug '20

19 Aug '20

Hi There I’m really hoping someone out there can help, Freeradius version: 3.0.13 (installed via rpm on rhel 7) I have a reasonably simple (to my mind) setup that for some reason doesn’t seem to exist on the internet after much fruitless searching. In essence, I am performing PAP auth to free radius which then binds as the user to AD via LDAP and performs an authentication It then is supposed to return the groups the user is a member of and then I use the “files” directive to match a group and return a reply attribute I’m now busy pulling my hair out trying to work out how to debug what’s going on in the background, as I am having amazingly bad luck trying to work out how the group filter works (and yes, I did read the ldap module comments and couldn’t work anything out from this, or the rlm_ldap wiki) Running radiusd -X gives some information that it is attempting to check groups but claims the user is not a group member (see below for the log) So far I’ve tried #groupfilter = '(objectclass=*)' #groupmembership_filter = "(&(objectClass=group)(member=%{Ldap-UserDN}))" #groupmembership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))" #groupmembership_filter = "(|(&(objectClass=group)(member=%{control:Ldap-UserDn})))" #groupmembership_filter = '(|(member=%{control:LDAP-UserDN})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))' groupmembership_attribute = 'memberOf' #groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))" #groupmembership_filter = "(sAMAccountName=%{User-Name})" groupmembership_filter = "(&(objectcategory=group)(member:1.2.840.113556.1.4.1941:=%{control:Ldap-UserDn}))" With some of these just hoping to get _anything_ to return (#groupmembership_filter = "(sAMAccountName=%{User-Name})") About the only thing I’ve had success in plugging into ldapsearch was the “(sAMAccountName=<my username>)” hence the attempt at doing that because it DID actually return “memberOf” attributes. I guess what I’m trying to do, is work out what I am supposed to plug into ldap search as every time I try it returns nothing. Is there a way to tell freeradius to print out what it thinks the various variables are? Like, %{Ldap-UserDN} I can see from the “sites-enabled” file as I can see it being set with.. update control { Ldap-UserDN := "%{User-Name}(a)xample.com" Auth-Type := LDAP } Is there an easy to follow guide for ldapsearch that describes that the (|(&(<attribute>=<value>)(<attribute>=<value>))) bits even mean? (primarily the (|(&( bit, as I can do a single <attribute>=<value> Search and get that to work) -- log from radisud -X – Ready to process requests (1) Received Access-Request Id 1 from 10.0.0.5:50847 to 10.0.0.10:1812 length 53 (1) User-Name = "username123" (1) User-Password = "password123" (1) NAS-IP-Address = 1.2.3.4 (1) # Executing section authorize from file /etc/raddb/sites-enabled/default (1) authorize { (1) auth_log: EXPAND /var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d (1) auth_log: --> /var/log/radius/radacct/10.0.0.5/auth-detail-20200810 (1) auth_log: /var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/10.0.0.5/auth-detail-20200810 (1) auth_log: EXPAND %t (1) auth_log: --> Mon Aug 10 15:15:19 2020 (1) [auth_log] = ok (1) if (&User-Password) { (1) if (&User-Password) -> TRUE (1) if (&User-Password) { (1) update control { (1) EXPAND %{User-Name}(a)exmple.com (1) --> username123(a)example.com (1) Ldap-UserDN := username123(a)example.com (1) Auth-Type := LDAP (1) } # update control = noop (1) } # if (&User-Password) = noop (1) ... skipping else: Preceding "if" was taken (1) files: Searching for user in group "access_2fa" rlm_ldap (ldap): Reserved connection (5) (1) files: Using user DN from request "username123(a)example.com" rlm_ldap (ldap): Released connection (5) Need 3 more connections to reach min connections (5) rlm_ldap (ldap): Opening additional connection (7), 1 of 8 pending slots used rlm_ldap (ldap): Connecting to ldap://10.0.0.50:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful (1) files: User is not a member of "ost_access_2fa" (1) files: Searching for user in group "OST_ACCESS_2FA" rlm_ldap (ldap): Reserved connection (6) (1) files: Using user DN from request "username123(a)example.com" rlm_ldap (ldap): Released connection (6) (1) files: User is not a member of " ACCESS_2FA" . . (note: The user in question IS in the group access_2fa and it isn’t a nested group)

2 3

Wrong type of Attribute ERX-Inner-Tag-Protocol-Id is octets should be string
by Daniel Finger 18 Aug '20

18 Aug '20

Hi! Our Juniper MX does not understand the Attribute ERX-Inner-Tag-Protocol-Id. I put ERX-Inner-Tag-Protocol-Id := 0x88a8 in our Database, but the MX logged: Inner-Vlan-Tag-Protocol-Id (Juniper-ERX-VSA), Err:"Attribute value is invalid" Decoded-val:0(0x0) authd_radius_parse_message: Error parsing common avps Framework - module(radius) return: MALFORMED DATA When I change the type from octets to string it works like a charm: -ATTRIBUTE ERX-Inner-Tag-Protocol-Id 211 octets +ATTRIBUTE ERX-Inner-Tag-Protocol-Id 211 string Their documentation states: hexadecimal string: - range = 0x600 through 0xffff. - 0x8100 = Inner VLAN tag for designated L2BSA subscribers Could you please change the dictionary.erx to use string instead of octets? TIA, Daniel Finger

2 1

after reinstallation of Freeradius on Ubuntu 20.04, cannot start service
by Gareth Tomlinson 17 Aug '20

17 Aug '20

Removed / purged freeradius after discovering daloradius didn't do what I needed, reinstalled and now cannot start the service. The issue SEEMS to be a missing shared library: freeradius.service - FreeRADIUS multi-protocol policy server Loaded: loaded (/lib/systemd/system/freeradius.service; disabled; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Mon 2020-08-17 17:38:53 EDT; 15ms ago Docs: man:radiusd(8) man:radiusd.conf(5) http://wiki.freeradius.org/ http://networkradius.com/doc/ Process: 11756 ExecStartPre=/usr/sbin/freeradius $FREERADIUS_OPTIONS -Cxm -lstdout (code=exited, status=127) Processing triggers for systemd (245.4-4ubuntu3.2) ... garetht@ecxbackup:/usr/lib$ sudo freeradius -v freeradius: error while loading shared libraries: libfreeradius-server.so: cannot open shared object file: No such file or directory garetht@ecxbackup:/usr/lib$ locate freeradius-server.so /usr/lib/freeradius/libfreeradius-server.so freeradius -CX freeradius: error while loading shared libraries: libfreeradius-server.so: cannot open shared object file: No such file or directory

2 1

Failover with Active Directory
by Robert Miller 17 Aug '20

17 Aug '20

Hello all, I have been doing a lot of research and reading to set up freeradius to work with my situation. The final issue I'm not able to solve is failover. It seems when I test by disabling the network card on one of my Active Directory servers, freeradius no longer works correctly. When watching the debug it is usually super quick, when one AD is down the debug is really slow. I believe that it being slow is the reason why the authorizations fail, they timeout. As soon as I bring either one of the downed ADs back online it works well. In both default and inner-tunnel I have failover setup like this: authorized { redundant { ldap1 ldap2 } I have also setup ldap1 and ldap2 pool { start = 0 My end goal with freeradius is to use AD for authorization, then freeradius will to the authentication. I have one policy setup to find allowed groups for the user. CentOS 8 with Freeradius 3.0.17 Thanks, Rob

2 4

Send Logs to Remote Log server
by Muhammed Buvaydani 17 Aug '20

17 Aug '20

Hello , I want to send freeradius's logs to another host , that host has Remote Log server , Rsyslog, or Graylog , how can I configure freeradius to do that . thank you

2 1

FreeRadius with Google PAM - Hardcode LDAP Servers for rlm_ldap
by Brandt Winchell 14 Aug '20

14 Aug '20

Hello, I have an issue which I am sure is easy to fix but I cannot find the correct file/setting. Let me explain: Environment: Active Directory - backend authentication. The AD environment is setup as a hub & spoke design. This means not all domain controllers (GC) are accessible from everywhere (by design & security) Freeradius - CentOS7 server FreeRadius-3.0.13 Source Setup: It is basically a setup following this site: https://kb.hillstonenet.com/en/wp-content/uploads/2019/09/SSLVPN-Two-factor… Validations: SSSD = Server joined to the domain fine. Can login to the local server with a domain account. ident tests resolve fine DNS = hostname and any GC server resolves correctly AD search results = **while in subnet80, works correctly** Google Authenticator PAM = **while in subnet80, works correctly** Issue: When I have the FreeRadius server in subnet80 (172.16.80.0/24 hub site and can talk to any GC server), the configuration works fine. So I know the basic configurations are working as designed. When I move the FreeRadius server into subnet 99 (172.16.99.0/24 restricted site that can only talk to 172.16.80.0/24), radius fails to get any results from GC servers. There is a firewall between these subnets. I have configured the following files to specify which GC servers FreeRadius should use: /etc/raddb/mods-available/ldap ldap { server = 'dc01.domain.local' server = 'dc02.domain.local' start_tls = no port = 389 identity = 'CN=ad-read-account,DC=domain,DC=local' password = 'xxxxxxx' base_dn = 'DC=domain,DC=local' /etc/sssd/sssd.conf [sssd] domains = domain.local services = nss, pam [domain/domain.local] id_provider = ad access_provider = ad ad_server = dc01.domain.local ad_backup_server = dc02.domain.local krb5_realm = DOMAIN.LOCAL krb5_server = dc01.domain.local kerb5_backup_server = dc02.domain.local ldap_uri = ldap://dc01.domain.local /etc/krb5.conf [libdefaults] dns_lookup_realm = false dns_lookup_kdc = false [realms] DOMAIN.LOCAL = { kdc = dc01.domain.local kdc = dc02.domain.local [domain_realm} domain.local = DOMAIN.LOCAL .domain.local = DOMAIN.LOCAL When I run "radiusd -CX". I get an ready to process requests for configuration check. When I run "radiusd -X", this is the where the process fails/hangs: rlm_ldap (ldap): Connecting to ldap://dc01.domain.local:389 ldap://dc02.domain.local:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful rlm_ldap (ldap): Reserved connection (5) (0) EXPAND (userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}}) (0) --> (userPrincipalName=user1(a)domain.local) (0) Performing search in "DC=domain,DC=local" with filter "(userPrincipalName=user1(a)domain.local)", scope "sub" (0) Waiting for search result... This will sit there until the LDAP search times out. When I perform a packet capture during this time, what I see: 1 radius performs a DNS query for forestdnszones.domain.local SOA dc01.domain.local 2 dns server responds with records of ALL GC servers 3 radius then tries to connect to a GC server it does not have access to (due to the security restrictions) Resolution: It seems that the FreeRadius LDAP module is trying to find the SRV record for LDAP. Of course DNS responds with all LDAP SRV records. What I need to be able to do is restrict what LDAP servers FreeRadius is trying to use. This seems very similar to SSSD Service Discovery. Any assistance on this one would be appreciated. btw... I cannot post full debug logs due to security but will provide any additional info that might assist with this Thanks

3 4

No Response from radius server
by mohamad buvaydanı 14 Aug '20

14 Aug '20

I have freeradius 3.0 which is installed on ubuntu 18.10 , I am working on hotspot system using Mikrotik with freeradius , I was able to send login Request from Mikrotik to radius server without any problem , but then I enabled Ufw in ubuntu machine , then I disabled UFW , Now Mikrotik can send request to freeradius but freeradius can not send response to Mikrotik , I don't know what is the problem , I disabled UFW and even I removed it from the server ,but still Mikrotik Can not get response from Radius this is the debug of Freeradius (0) [expiration] = noop (0) [logintime] = noop (0) accessperiod: WARNING: Couldn't find check attribute, control:Access-Period, doing nothing... (0) [accessperiod] = noop (0) pap: WARNING: Auth-Type already set. Not setting to PAP (0) [pap] = noop (0) } # authorize = ok (0) Found Auth-Type = Accept (0) Auth-Type = Accept, accepting the user (0) # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default (0) post-auth { (0) update { (0) No attributes updated (0) } # update = noop (0) sql: EXPAND .query (0) sql: --> .query (0) sql: Using query template 'query' rlm_sql (sql): Reserved connection (2) (0) sql: EXPAND %{User-Name} (0) sql: --> test (0) sql: SQL-User-Name set to 'test' (0) sql: EXPAND INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '%{SQL-User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S') (0) sql: --> INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'test', '0x8da5209f622859ac89fd640527cb56139a', 'Access-Accept', '2020-08-12 21:07:21') (0) sql: Executing query: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'test', '0x8da5209f622859ac89fd640527cb56139a', 'Access-Accept', '2020-08-12 21:07:21') (0) sql: SQL query returned: success (0) sql: 1 record(s) updated rlm_sql (sql): Released connection (2) (0) [sql] = ok (0) [exec] = noop (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else { (0) [noop] = noop (0) } # else = noop (0) } # policy remove_reply_message_if_eap = noop (0) } # post-auth = ok (0) Sent Access-Accept Id 23 from 172.16.1.148:1812 to 172.16.1.252:40180 length 0 as u see from the last line , Freeradius sending Access-accept to Mikrotik , but this response not received by mikroitk and Mikrotik through Login Feild No Response From Radius I tested Mikrotik with another freeradius server and it is working without any problem So , I think there are somethings which prevent the response packet to Mikrotik .

2 1

Seeing dhcp packet drops in latest master
by Chinnapaiyan, Nagamani 13 Aug '20

13 Aug '20

We are seeing packet drops frequently in latest 4.x version(#8c2e4122572a12f43d4ec294d3258a2f0da07b1d). We are not doing scale test, just ~10 DORAs. If I run some 10 testcases(10 DORAs each test case), it fails randomly at any one of the tests. The same testcases were passing around one month before. We have Client -> Freeradius dhcp Relay agent(Load Balancer) -> freeradius dhcp server. I could not capture issue clearly with debug mode as it is slower. So I enabled some of the debug logs in the code. ---------------- diff --git a/src/lib/io/network.c b/src/lib/io/network.c index 7276606..3850725 100644 --- a/src/lib/io/network.c +++ b/src/lib/io/network.c @@ -684,6 +684,7 @@ static void fr_network_read(UNUSED fr_event_list_t *el, int sockfd, UNUSED int f s->listen->fd, sockfd)) return; DEBUG3("Reading data from FD %u", sockfd); + ERROR("DEBLOGJK: Reading data from FD %u", sockfd); if (!s->cd) { cd = (fr_channel_data_t *) fr_message_reserve(s->ms, s->listen->default_message_size); @@ -751,6 +752,7 @@ next_message: s->cd = NULL; DEBUG3("Read %zd byte(s) from FD %u", data_size, sockfd); + ERROR("DEBLOGJK: Read %zd byte(s) from FD %u", data_size, sockfd); nr->stats.in++; s->stats.in++; diff --git a/src/modules/proto_dhcpv4/proto_dhcpv4_udp.c b/src/modules/proto_dhcpv4/proto_dhcpv4_udp.c index 89e7ac9..38736fe 100644 --- a/src/modules/proto_dhcpv4/proto_dhcpv4_udp.c +++ b/src/modules/proto_dhcpv4/proto_dhcpv4_udp.c @@ -159,6 +159,7 @@ static ssize_t mod_read(fr_listen_t *li, void **packet_ctx, fr_time_t *recv_time &address->src_ipaddr, &address->src_port, &address->dst_ipaddr, &address->dst_port, &address->if_index, recv_time_p); + ERROR("DEBLOGJK: proto_dhvpv4_udp"); if (data_size < 0) { DEBUG2("proto_dhvpv4_udp got read error %zd: %s", data_size, fr_strerror()); return data_size; @@ -203,6 +204,9 @@ static ssize_t mod_read(fr_listen_t *li, void **packet_ctx, fr_time_t *recv_time DEBUG2("proto_dhcpv4_udp - Received %s XID %08x length %d %s", dhcp_message_types[message_type], xid, (int) packet_len, thread->name); + ERROR("DEBLOGJK: proto_dhcpv4_udp - Received %s XID %08x length %d %s", + dhcp_message_types[message_type], xid, + (int) packet_len, thread->name); return packet_len; } ------------------- Below are tcpdump and radiusd logs in success case and failure cases. normal time (success case): Client side:(tcpdump) 12:12:36.039499 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 311 12:12:36.106401 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 768 12:12:36.107826 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 323 12:12:36.113856 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 768 12:12:36.439471 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 311 12:12:36.442614 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 328 12:12:36.442895 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 323 12:12:36.445647 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 328 Relay Agent side:(tcpdump) 12:12:36.041608 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 311 12:12:36.041851 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 312 12:12:36.109916 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 323 12:12:36.110206 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 324 12:12:36.441579 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 311 12:12:36.441894 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 312 12:12:36.444965 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 323 12:12:36.445130 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 324 DHCP server side: (tcpdump + enabled radiusd logs) 12:12:36.041788 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 312 <<tcpdump line Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 <<< added error logs Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Discover XID 00000000 length 312 dhcpv4_udp server 10.43.18.48 port 67 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Read 312 byte(s) from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-DISCOVER giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3a 12= 50= 55=DHCP-Subnet-Mask,DHCP-Broadcast-Address,DHCP-Time-Offset,DHCP-Router-Address,DHCP-Domain-Name,DHCP-Domain-Name-Server,DHCP-Hostname 60= 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100=82.1 <<< logs from our module's config Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: (77) ldap - Closing connection (3): Hit idle_timeout, was idle for 207.534324944s Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: rlm_ldap (ldap) - Directory type: OpenLDAP Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-LDAP_FOUND LDAP option43 string found for MAC 00:a0:bc:6c:7d:3a. Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: (77) redis_ippool - Closing connection (5): Hit idle_timeout, was idle for 212.217780777s 12:12:36.108074 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 768 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-OFFER giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3a yiaddr=172.21.0.181 1=255.255.0.0 3=172.21.0.1 6=72.173.31.41,72.173.31.42 43=0x010300a0bc0209555400000000000007030e55543200000000000307030a0009041155545f332e372e332e31302e392e62696e05040a4fff0f1444010002010311050044004407004300430101020103060701bd01bd0101020107008700880101020106c0a8640018070016001701010201031106c0a86400180700a100a11901012642687474703a2f2f6163732e6465762e636d742e7669617361742e696f3a393637352f6c6976652f4350454d616e616765722f435045732f67656e657269635452363927020005280207d02a0e55542e352e322e322e31303530332b040a4fff0f2c0e55542e352e322e322e3130333933330c5554320000000000000029083601ff3b0e55543200000000000307030a00093c125554325f332e372e332e31302e392e62696e3d040a4fff0f3e3c687474703a2f2f31302e37392e3235352e31362f7075622f7677615f696d616765732f7677615f55542e352e322e322e31303530332e7461722e677a3f3c687474703a2f2f31302e37392e3235352e31362f7075622f7677615f696d616765732f7677615f55542e352e322e322e31303339332e7461722e677a400100 51=120 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= 12:12:36.110060 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 324 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Request XID 00000000 length 324 dhcpv4_udp server 10.43.18.48 port 67 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Read 324 byte(s) from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-REQUEST giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3a ciaddr=10.43.18.32 12= 50=172.21.0.181 55=DHCP-Subnet-Mask,DHCP-Broadcast-Address,DHCP-Time-Offset,DHCP-Router-Address,DHCP-Domain-Name,DHCP-Domain-Name-Server,DHCP-Hostname 60= 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-LDAP_FOUND LDAP option43 string found for MAC 00:a0:bc:6c:7d:3a. Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: (78) Closing connection (7): Hit idle_timeout, was idle for 207.588781775s 12:12:36.115554 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 768 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-ACK giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3a yiaddr=172.21.0.181 1=255.255.0.0 3=172.21.0.1 6=72.173.31.41,72.173.31.42 12= 43=0x010300a0bc0209555400000000000007030e55543200000000000307030a0009041155545f332e372e332e31302e392e62696e05040a4fff0f1444010002010311050044004407004300430101020103060701bd01bd0101020107008700880101020106c0a8640018070016001701010201031106c0a86400180700a100a11901012642687474703a2f2f6163732e6465762e636d742e7669617361742e696f3a393637352f6c6976652f4350454d616e616765722f435045732f67656e657269635452363927020005280207d02a0e55542e352e322e322e31303530332b040a4fff0f2c0e55542e352e322e322e3130333933330c5554320000000000000029083601ff3b0e55543200000000000307030a00093c125554325f332e372e332e31302e392e62696e3d040a4fff0f3e3c687474703a2f2f31302e37392e3235352e31362f7075622f7677615f696d616765732f7677615f55542e352e322e322e31303530332e7461722e677a3f3c687474703a2f2f31302e37392e3235352e31362f7075622f7677615f696d616765732f7677615f55542e352e322e322e31303339332e7461722e677a400100 51=300 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= 12:12:36.441821 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 312 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Discover XID 00000001 length 312 dhcpv4_udp server 10.43.18.48 port 67 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Read 312 byte(s) from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-DISCOVER giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3b 12= 50= 55=DHCP-Subnet-Mask,DHCP-Broadcast-Address,DHCP-Time-Offset,DHCP-Router-Address,DHCP-Domain-Name,DHCP-Domain-Name-Server,DHCP-Hostname 60= 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= 12:12:36.444307 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 328 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-OFFER giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3b yiaddr=172.18.16.112 1=255.0.0.0 3=172.16.0.1 6=72.173.31.41,72.173.31.42 43= 51=92 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= 12:12:36.444982 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 324 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Request XID 00000001 length 324 dhcpv4_udp server 10.43.18.48 port 67 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Read 324 byte(s) from FD 51 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-REQUEST giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3b ciaddr=10.43.18.32 12= 50=172.18.16.112 55=DHCP-Subnet-Mask,DHCP-Broadcast-Address,DHCP-Time-Offset,DHCP-Router-Address,DHCP-Domain-Name,DHCP-Domain-Name-Server,DHCP-Hostname 60= 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= 12:12:36.447348 IP 10.43.18.48.67 > 10.43.18.32.67: BOOTP/DHCP, Reply, length 328 Aug 13 12:12:36 citests01-dhcp-01-alpha radiusd[30937]: DHCP-ACK giaddr=10.43.18.32 chaddr=00:a0:bc:6c:7d:3b yiaddr=172.18.16.112 1=255.0.0.0 3=172.16.0.1 6=72.173.31.41,72.173.31.42 12= 43= 51=300 61=0x01afac00000000 82.1=0x0000804bff66 82.2=0x00a0bc6c7d3a 82.6=00a0bc000001(a)perf.test.viasat 82.100= Packet drop: Client side: 12:41:16.748120 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 311 12:41:17.148104 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 311 Relay agent side: 12:41:16.750013 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 311 12:41:16.750285 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 312 12:41:17.150006 IP 10.43.18.32.67 > 10.43.18.31.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 311 12:41:17.150258 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 312 DHCP server side: 12:41:16.750292 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3a, length 312 Aug 13 12:41:16 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:41:16 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:41:16 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Discover XID 00000000 length 312 dhcpv4_udp server 10.43.18.48 port 67 Aug 13 12:41:16 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Read 312 byte(s) from FD 51 12:41:17.150273 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3b, length 312 Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Discover XID 00000001 length 312 dhcpv4_udp server 10.43.18.48 port 67 12:41:17.350309 IP 10.43.18.31.67 > 10.43.18.48.67: BOOTP/DHCP, Request from 00:a0:bc:6c:7d:3c, length 312 Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: Network 0 - DEBLOGJK: Reading data from FD 51 Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhvpv4_udp Aug 13 12:41:17 citests01-dhcp-01-alpha radiusd[30931]: DEBLOGJK: proto_dhcpv4_udp - Received DHCP-Discover XID 00000002 length 312 dhcpv4_udp server 10.43.18.48 port 67 seems packet is delivered to DHCP server, but radiusd is not responding and there are no other error logs in that time. I tried my best to corner out the problem. But, could not tackle the exact use case as it is happening randomly. I suspected these two logs, ldap - Closing connection (3): Hit idle_timeout, was idle for 207.534324944s redis_ippool - Closing connection (5): Hit idle_timeout, was idle for 212.217780777s I tried tweaking that parameter from 60, to 600 then to infinite(0) in redis, redis_ippool and ldap. That didnt help. Please help. Regards, Nagamani Chinnapaiyan

2 1