On Feb 9, 2026, at 2:35 PM, Dave Wang <dave.ftnt@gmail.com> wrote:
I noticed that in our aruba switch, it refused to work after eap-tls if I left the default config for EAP-TLS fragment_size.
"refused to work" could mean a lot of things.
And what happened is, aruba switch does not send Framed-MTU in radius request,
That's fine. It should still work.
freeradius uses the fragment_size to do calculation, but in the Access-Accept response, it sends a radius attribute Framed-MTU, with value calculated based on fragment_size.
Yes.
However, I do not understand why freeradius sends the Framed-MTU based on the fragment_size, as it seems these two are not directly linked.
It's a suggestion from the RADIUS server to limit the EAP fragment size. The switch doesn't have to respect it.
The Framed-MTU is more or less used to set the MTU for this user for the following traffic. but the fragment_size is used to decide how we do the fragment in eap, and the value is restricted by the link between NAS and freeradius.
Sort of. The difficulty is that there are no real standards around this subject. And there is no standard way for the RADIUS server to signal an expected EAP fragment size to the supplicant.
Suppose the max-MTU between NAS and freeradius is 1000, so we need to set the fragment_size to be a smaller value in order to make the EAP works, but if the other links the NAS used have a higher max-MTU (say 1500), there is no reason to restrict the max-MTU to be 1000 in the end.
Any reason behind how the Framed-MTU is set in the EAP-TLS case based on the fragment_size?
The switch should use the Framed-MTU in the Access-Accept. If there's a Framed-MTU in the Access-Challenge, that shouldn't affect user traffic. Or, you can change the FreeRADIUS configuration to delete the Framed-MTU from the replies. Alan DeKok.