Hello, I have a setup where a proxied-to virtual server sets the attribute Session-Timeout with := and then the calling server sets it subsidiary to a different value with = in post-proxy. The reply_log for both servers shows that the first value is set ok, but the second = operator *adds* the Session-Timeout attribute a second time. This effectively leads to FreeRADIUS sending back a malformed packet because it now contains two Session-Timeout attributes. The reply_log/post_proxy_log contents look like this: Sat Apr 6 12:17:25 2019 Packet-Type = Access-Reject Session-Timeout = 604800 <-- as set with := Timestamp = 1554545845 Sat Apr 6 12:17:25 2019 Packet-Type = Access-Reject Cisco-Account-Info = "ASERVICE_INTERNET-DEFAULT" Session-Timeout = 86400 <-- extra addition in post-proxy Idle-Timeout = 7200 Session-Timeout = 604800 <-- should prevail Timestamp = 1554545845 The post-proxy configuration of the caller is: post-proxy { update reply { Cisco-Account-Info = "ASERVICE_INTERNET-DEFAULT", Session-Timeout = 86400, Idle-Timeout = 7200 } post_proxy_log } This seems to be a bug: Session timeout is already set, and the = operator should refrain from changing the existing value. And also, it should detect that it is doing something non-RFC compliant by adding it twice. The actual reply as seen by radtest is: Received Access-Reject Id 196 from 127.0.0.1:1812 to 127.0.0.1:49664 length 71 Cisco-Account-Info = "ASERVICE_INTERNET-DEFAULT" Session-Timeout = 86400 Idle-Timeout = 7200 Session-Timeout = 604800 (0) -: Expected Access-Accept got Access-Reject So the incorrect attribute list actually made it onto the wire. Greetings, Stefan Winter