Freeradius Framed-MTU

[Nick Porter]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20260302/a21514ae/attachment.sig>