One more bug fix, to make it work with 'users' file entry:

	One more bug fix, to make it work with 'users' file entry:

bob	Auth-Type := Local, User-Password == "bob", Login-Service =~ "Telnet|LAT"
	Tunnel-Client-Auth-Id:0 += `(uid=%{Stripped-User-Name:-%{User-Name:-none}})`,
	Tunnel-Client-Auth-Id:0 += `%{User-Name}`,
	Tunnel-Client-Auth-Id:0 += `UPDATE ${acct_table1} SET FramedIPAddress = '%{Framed-IP-Address}', NASIPAddress='%{NAS-IP-Address}'`

	and test packet:

User-Name = "bob", User-Password = "bob", Calling-Station-Id = "555", Login-Serv
ice = Telnet,  Framed-IP-Address = 1.2.3.4, NAS-IP-Address = 5.6.7.8

	and receiving reply:

rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=206, length=101
        Tunnel-Client-Auth-Id:0 = "(uid=bob)"
        Tunnel-Client-Auth-Id:0 = "bob"
        Tunnel-Client-Auth-Id:0 = "UPDATE  SET FramedIPAddress = '1.2.3.4', NASIPAddress='5.6.7.8'"

	As a note, the 'xlat' implementation appears to be overly complicated.
	Using 'for (...p++)' in the loop, instead of 'while (*p)', means
	that 'p' is incremented ALWAYS, instead of only when it's needed.

	The previous code was easy when we only had xlat'd strings of %U,
	but for more complicated ones, it caused a lot of problems.

	Also, updated the error message for unknown xlat functions/attributes,
	to print out only if there is no xlat function of that name, AND
	there is no dictionary attribute of that name.

	This helps to minimize the errors which were confusing people,
	when xlat was previously complaining about unknown attributes, when
	the named attribute was in the dictionary, but no in the incoming
	request.