Handle accounting stop with zero session length

[Stefan Möding]

Hi!

We are upgrading our current Freeradius servers from Ubuntu-14 to
Ubuntu-18. Using the Ubuntu provided Freeradius package this means
stepping from 2.1.12 to 3.0.16.

I think I pretty much got the config changes done on the old version
into the new setup and the system works mostly as expected. But there
seems to be a change from version 2 to version 3 that creates additional
accounting records with zero session length.

We used radsniff to observe that our NAS does send an accounting request
stop after receiving an access reject from Freeradius:

2020-04-22 08:16:38.392369 (9) Access-Request Id 169 ens192:192.168.225.20:1645 -> 192.168.227.10:1812 +2.015
        User-Name = "testuser153 at test.net"
        CHAP-Password = 0x0275dd4d90353ec539963c8aa22d2caa4e
        NAS-IP-Address = 192.168.225.20
        NAS-Port = 121
        Service-Type = Framed-User
        Framed-Protocol = PPP
        NAS-Port-Type = Virtual
        Connect-Info = "1000000000"
        NAS-Port-Id = "Uniq-Sess-ID121"
        Authenticator-Field = 0x174eaf56fd80857b520aa893da81c1e8
2020-04-22 08:16:39.395955 (10) Access-Reject Id 169 ens192:192.168.225.20:1645 <- 192.168.227.10:1812 +3.019 +1.003
        Authenticator-Field = 0xf1917ec032bf848906f021074d267cd7
2020-04-22 08:16:39.396846 (11) Accounting-Request Id 11 ens192:192.168.225.20:1646 -> 192.168.227.10:1813 +3.020
        User-Name = "testuser153 at test.net"
        NAS-IP-Address = 192.168.225.20
        NAS-Port = 121
        Service-Type = Framed-User
        NAS-Port-Type = Virtual
        Acct-Status-Type = Stop
        Acct-Delay-Time = 0
        Acct-Input-Octets = 0
        Acct-Output-Octets = 0
        Acct-Session-Id = "001E2FED"
        Acct-Authentic = RADIUS
        Acct-Session-Time = 0
        Acct-Input-Packets = 0
        Acct-Output-Packets = 0
        Acct-Terminate-Cause = User-Error
        Acct-Tunnel-Connection = "2058273712"
        Tunnel-Type:0 = L2TP
        Tunnel-Medium-Type:0 = IPv4
        Tunnel-Client-Endpoint:0 = "192.168.254.2"
        Tunnel-Server-Endpoint:0 = "192.168.254.3"
        Tunnel-Assignment-Id:0 = "TEST_LAC"
        Tunnel-Client-Auth-Id:0 = "ALAC01"
        Tunnel-Server-Auth-Id:0 = "BLNS01"
        Connect-Info = "1000000000"
        NAS-Port-Id = "Uniq-Sess-ID121"
        PMIP6-Home-HN-Prefix = 3541:3238:3238::/52
        Cisco-AVPair = "ppp-disconnect-cause=User failed CHAP authentication"
        Cisco-AVPair = "connect-progress=Auth Failed"
        Cisco-AVPair = "nas-tx-speed=1000000000"
        Cisco-AVPair = "nas-rx-speed=1000000000"
        Cisco-AVPair = "disc-cause-ext=PPP CHAP Fail"
        Authenticator-Field = 0x20c83037e2d128ec2a6ba6be1519e1ef

This accounting record shows up in the database which it didn’t do when
Freeradius 2 was used.

I searched the archives and found a discussion where someone (I thing it
was Alan) said, that the NAS is broken if it does this. I agree but
currently this is how it is.

Using Freeradius 2 we got the follwing log messages:
[sql_acct] stop packet with zero session length. [user '', nas '192.168.225.20']

Looking a the source code I got the impression that this is where things
changed from version 2 to version 3. In version 2 the log message
indicates the the zero length stop message was ignores. In version 3 the
code changed and the accounting recored is written to the database.

Can we do anything about this?

I’m thinking about using the following unlang code in the accounting
section to avoid these records to show up in the database:

  accounting {
    if (&Acct-Status-Type == "Stop" && &Acct-Terminate-Cause == "User-Error" && &Acct-Session-Time == 0) {
      attr_filter.accounting_response
      return
    }

    sql_acct
    attr_filter.accounting_response
  }

Does this look reasonable? Do I miss anything?

Thanks!
Stefan