On 13.2.2015 17.59, Bruno Tiago Rodrigues wrote: > By changing the vendorByNum function at RDict.pm we managed to get it > working, but it doesn't feel right to be changing the code for something > that oughta be backwards compatible.
You are correct, that change should not be needed. For example, this function has not changed since release 4.9 I tried replicating the problem but could not get it to fail. Can you make sure you are using a radpwtst from Radiator 4.14? The header in radpwtst has $Id: ...$ string which tells the version of radpwtst file. > The release notes mention something about changes on the way Starent > attributes are handled, but it doesn't make sense, since all we're doing > is using the dictionary to convert the textual attribute to a attribute > number, encoding it and sending it through radpwtst. It wasn't supposed > to be broken. There's now goodies/dictionary.starent-vsa1 that uses different encoding for Starent vendor specific attributes. Please see the file for more. In short: Radiator default dictionary Starent VSAs use the same encoding in 4.9 and 4.14. If there's a need to use alternative encoding, then the goodies dictionary should be used. Thanks, Heikki -- Heikki Vatiainen <h...@open.com.au> 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 radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
