On 02/03/2026 03:36, Kat via Freeradius-Users wrote:
Based on your email, I took another look and I found reference to Framed-MTU in the etc/raddb/users file, so I uncommented that in and tried to set it to 1024. I saved the changes and restarted the server in -x. And then reconnected to check the logs. A subset of logs are provided below the email.
Framed-MTU is being set to 1002 or 994, not 1024.
eg: (24) Framed-MTU += 994 (24) Framed-MTU = 1002 (24) &session-state:Framed-MTU = 994
I've put comments into the logs below to show what these mean. It's important to remember you have different lists of attributes at play here, and the different operators (=, :=, += etc) are important and have different behaviour.
Google Gemini tells me it is because of this line: (24) [files] = noop
and that the default setting of Framed-MTU that I brought back in is being disregarded because the supplicant has an identity.
A "noop" return from the files module means it did nothing.
So do I need to put that identity in the users file and set the Framed-MTU there specifically?
You're getting lost in the weeds of AI unhelpfulness. I would strongly recommend not using Gemini for this - it is getting more wrong that right. There is no one correct way to set a reply attribute - it all depends on your requirements. The files module provides a text database which can be used to map attributes in the request to setting attributes in the reply (that's a very over simplified description)
If you are running into issues with fragmentation on the packets from client to server, then usually the key is getting path MTU discovery to work correctly.? Failing that, it is a matter of ensuring that fragments are not getting dropped by firewalls.
I would like to set the Framed-MTU because I have been asked to do so. I don't know if it will help them or not but I want to do it because I have been asked to do so.
Sometimes you have to do something you know will not work to prove that it won't work - this sounds like one of those cases.
Why they want to set Framed-MTU is because Freeradius is returning many debug lines that look like this:
(458002) Cleaning up request packet ID 112 with timestamp +945036 due to cleanup_delay was reached
That is a perfectly normal message from FreeRADIUS. When FreeRADIUS sends a reply, it caches that reply for a period, determined by cleanup_delay. This is so that if it receives a retransmit of the original packet, it can send the reply without re-processing the packet. So - no amount of setting reply attributes will get rid of those debug messages - they are perfectly normal.
Example logs: (24) Received Access-Request Id 193 from 172.17.0.1:52424 to 172.17.0.2:1812 length 243 (24) Framed-MTU = 1002
This instance of Framed-MTU is in the packet received from the client - all the attributes presented indented under the "Recevice..." line are the incoming packet.
(24) Restoring &session-state (24) &session-state:Framed-MTU = 994 Here a value of Framed-MTU in the session-state list is being restored - so that has been set at some point in a previous packet exchange which formed part of the exchange
(24) post-auth { ... (24) update { (24) &reply::Framed-MTU += &session-state:Framed-MTU[*] -> 994 Here the an instance of Framed-MTU in the reply is being set from the session-state instance.
(24) Sent Access-Accept Id 193 from 172.17.0.2:1812 to 172.17.0.1:52424 length 173 (24) MS-MPPE-Recv-Key = 0x9e7d6bc3e620c918df655f5b6f3df6354afb8a122a23d067e577eeceef5d41dd (24) MS-MPPE-Send-Key = 0x30c4a64e47a5fadfdbe66e814dda937c5a16d504439fdb0c7e21602acbc3664b (24) EAP-Message = 0x03f50004 (24) Message-Authenticator = 0x00000000000000000000000000000000 (24) User-Name = "redacted" (24) Framed-MTU += 994 (24) Finished request
So the reply contains the value set from the session-state data. You have two choices: 1) Look through the full debug for the client - there will be several Access-Request -> Access-Challenge exchanges before this one - and somewhere in that Framed-MTU is being added to session-state. Fix that to be what you want it to be. 2) In post-auth, after the policy which is copying session-state to reply, add an update section to override the value of Framed-MTU in the reply. Make sure you use := as the operator to override any existing values. Nick -- Nick Porter