Hello,
I've set up a strongswan 4.6.2 test instance to test the new radius
accounting feature. It works great an I'm really happy since we've
wanted that feature for some time. :)
I've noticed though that the tickets do not contain information about
the tunnel outer ip address, typically in the
Hi Claude,
I've noticed though that the tickets do not contain information about
the tunnel outer ip address, typically in the Calling-Station-Id field.
Is there a precise reason that this field is missing, or would it be
possible to add it in a future release ?
No, there is no specific
I've noticed though that the tickets do not contain information about
the tunnel outer ip address, typically in the Calling-Station-Id field.
Is there a precise reason that this field is missing, or would it be
possible to add it in a future release ?
No, there is no specific reason, I
Hello Gerd
while you are at it: wouldn't it make sense to store the port number too,
like
ip:port?
Hm, might make sense in some setups, try the attached patch.
I've used our strongSwan Host/Port notation (192.168.1.5[4500]), as
using a colon with IPv6 is very confusing.
Maybe we should
Hi Martin,
while you are at it: wouldn't it make sense to store the port number too,
like ip:port?
Hm, might make sense in some setups, try the attached patch.
I've used our strongSwan Host/Port notation (192.168.1.5[4500]), as
using a colon with IPv6 is very confusing.
good idea.
Hello Martin,
Thanks a lot for the patches, they work great.
kind regards,
Claude
--
Claude Tompers
Ingénieur réseau et système
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la
Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
Tel: +352 424409 1
Fax:
Hi Martin,
On Friday, 24. February 2012 10:58:54 Martin Willi wrote:
Hm, might make sense in some setups, try the attached patch.
While looking at the patch out of curiosity, I noticed two things
regarding the snprintf() usage:
- If the source string is larger than the destination buffer,
Hello Thomas,
C99 states it will always be zero terminated IIRC.
So this is not a real issue.
I think it is save to snprintf() to short buffers, as long as you don't
rely on the return value for length calculations.
- Return value of snprintf() is the number of bytes that would
have been