I've tried various google searches, I've tried searching the
mailing list, and I've tried delving (in a surface kind of way) into the
What I *want* is for there to be valid byte (or octet)
counts (send and receive) in the radius accounting records that racoon
emits. I'd be satisfied with intermediate records emitted as SAD records
die (that does sound SAD!) so long as at the end of the day, I have (or
can compute) usable total connection start and stop times, , user names,
AND byte counts.
The byte counts are what's killing me. In particular,
how to get them out of the kernel and store them someplace correct so
that at the end of a session I know what they were, can include them in
the radius accounting records, and can reasonably assert that the counts
Has anyone tried this? Does anyone have working code, or
a suggestion as to how to do it? I might be able to get some money to
pay someone to do it if someone was just waiting for a good reason to
put this in....
I'm using 0.8.0 on 8.1-RELEASE FreeBSD (updated).
Thanks for any help you can give!
messages to "ipsec-devel (at) track.pupworks.com". Thanks.
Nat Howard <nrh+ipsectools@...> writes:
> What I *want* is for there to be valid byte (or octet)
> counts (send and receive) in the radius accounting records that racoon
> Has anyone tried this? Does anyone have working code, or
> a suggestion as to how to do it?
The data you want is available in the 'current' lifetime extension
sent from the kernel to racoon (at least on Linux) when the
kernel-equivalent of a phase2 SA goes away. This happens in
pk_recvexpire/ pfkey.c, purge_remote/ isakmp.c and purge_ipsec_spi/
isakmp_inf.c (in 0.7.3). Details of the message format are in the
PF_KEY v2 RFC,
If you want per-user accounting, my suggestion would be to add byte
counter members to the ph1handle structure, update these whenever a
ph2 goes away and create 'accounting output' of some kind when the ph1
goes away (Yes, I do have working code for that. But it is based on an
older version of ipsec-tools [unlikely to be ever updated because of
some 'differences in technical opinion', eg, in the areas of NAT
traversal support, ph2 deletion and DPD] and part of a proprietary