On 25.11.2014 13.22, Arthur Konovalov wrote: > and there a problem arise - address not properly converted. > Trace level 4 output for this AVP shows as: > Served-Party-IP-Address: VM., > <0><2>*<0><22><224><0>0<0><1><4><190>T/<30><17><238>s
Decoder for IPv4 addresses does the conversion from binary to textual format. However, for other address families the attribute value is returned directly including the first two octets that specify the address family. > For Diameter dictionary entry for this AVP: > VANDORATTR 10415 Server-Party-IP-Address 848 Address This looks good. You need to have the type as Address to trigger the correct decoder/encoder. I suggest locating decoder for 'address' type from Radius/DiaAttrList.pm and adding this: return Radius::Util::inet_ntop($a) if $at == 2; This goes just after the line that handles $at == 1; > For Radius converted: > VANDORATTR 10415 Server-Party-IP-Address 80 string > > Radiator version 4.9 in use. > > Is there any suggestion how to implement how to store both ip addresses > variants to SQL? > Does upgrading Radiator might help there? It does not help yet. We will add the respective change in the current patches so that the patched 4.13 and the next release will decode IPv6 addresses correctly. Note: with 4.9 the textual address will get 'ipv6:' prefix. This will not happen with the patched version. Thanks for reporting this. Heikki -- Heikki Vatiainen <[email protected]> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
