Re: missing STOP records

Stephen Fisher (lithium@cia-g.com)
Tue, 1 Jul 1997 14:28:18 -0600 (MDT)

What you have to realize is that you are looking at the syslog entries
which are very brief and *not guaranteed* to be sent to the server. This
is because the Portmaster just fires off the message in unreliable UDP
format to the server's syslog daemon which listens on port 514. I use
this for quick reference and changed the syslogging on the Portmasters to
go to local5.info and set syslog.conf to put all of that information in
its own file.

When you want to do accounting you need to use the Radius accounting logs,
by default on my system they are stored in /var/log/radacct/ as specified
by the "-a [directory name]" command line option when starting radiusd.

The radius daemon will then create a directory for each of the portmasters
that are in its clients file and put a file called "detail" in each with
much more information than the syslog such as this:

The START record:

Mon Jun 30 22:21:38 1997
Acct-Session-Id = "4600001A"
User-Name = "peaches"
NAS-IP-Address = 206.206.153.5
NAS-Port = 30
NAS-Port-Type = Async
Acct-Status-Type = Start
Acct-Authentic = RADIUS
Connect-Info = "24000 LAPM/V42BIS"
Service-Type = Login-User
Login-Service = Rlogin
Login-IP-Host = 206.206.162.5
Acct-Delay-Time = 0
Timestamp = 867730898

And the STOP record:

Mon Jun 30 22:25:26 1997
Acct-Session-Id = "4600001A"
User-Name = "peaches"
NAS-IP-Address = 206.206.153.5
NAS-Port = 30
NAS-Port-Type = Async
Acct-Status-Type = Stop
Acct-Session-Time = 227
Acct-Authentic = RADIUS
Connect-Info = "24000 LAPM/V42BIS"
Acct-Input-Octets = 194
Acct-Output-Octets = 43051
Acct-Terminate-Cause = Host-Request
Service-Type = Login-User
Login-Service = Rlogin
Login-IP-Host = 206.206.162.5
Acct-Delay-Time = 0
Timestamp = 867731126

(Note that the ammount of information given in each record varies, most
visible is probably the "Connect-Info =" entry which is only available on
the PM3).

You'll also want to note that this type of accounting is almost 100%
reliable because the Portmaster sends the accounting packet to the Radius
server and then it waits for the Radius server to verify back to the
Portmaster that it was received. If not it will keep resending.

Hope this helps,

Steve

On Tue, 1 Jul 1997, Ilya Etingof wrote:

> Our PM2eR30 with ComOS 3.5 / 4MB RAM sometimes doesn't seem to terminate
> slip/ppp dialin sessions:
>
> Jul 1 13:13:15 pm1 dialnet: port S8 aloginov ppp succeeded dest 195.218.254.15
> Jul 1 13:13:18 pm1 dialnet: port S8 connection succeeded dest ppp615.glas.apc.o
> Jul 1 13:17:55 pm1 portmaster: port S8 Login succeeded for ksrayif
> Jul 1 13:19:27 pm1 portmaster: port S8 session disconnected user ksrayif
>
> e.g. preffy often we have no record like:
>
> Jul 1 13:21:35 pm1 dialnet: port S8 session disconnected dest ppp615.glas.apc.org
>
> in our syslog file.
>
> In consequence, and what is really annoying, our pm doesn't send accounting
> stop records so sometimes our users are charged for longer sessions than they
> actually had! Here is a quote from our Radius log:
>
> Tue Jul 1 13:13:20 1997: Authentication: 214/23 'aloginov ppp' via pm1 from pm1 port 8 PPP - OK
> Tue Jul 1 13:13:24 1997: Accounting: 216/94 'aloginov ppp' via pm1 from pm1 port 8 Start - OK
> Tue Jul 1 13:18:00 1997: Authentication: 228/27 'ksrayif ' via pm1 from pm1 port 8 dumb - OK
> Tue Jul 1 13:18:00 1997: Accounting: 229/106 'ksrayif ' via pm1 from pm1 port 8 Start - OK
> Tue Jul 1 13:19:32 1997: Accounting: 234/109 'ksrayif ' via pm1 from pm1 port 8 Stop - OK