On 27/02/2026 05:24, Kat via Freeradius-Users wrote:

Google Gemini is insisting quite strongly that, after changing fragment size in the /etc/raddb/mods-enabled/eap, I also need to put something in the post-auth part.

The problem is that sometimes AI can be wrong and I cannot find alternate sources that back this claim up. My Google-fu may be weak.

This is a case of AI being confidently wrong - but there is wrong information out there which was probably part of the training set. Setting fragment size determines the largest EAP fragment which FreeRADIUS will send in an Access-Challenge - so controlling the RADIUS server -> client packet. There is some incorrect information out there which claims that setting Framed-MTU will influence the client -> server EAP fragment sizes.  That is simply not the case.  That attribute can be used in an Access-Accept for setting the MTU on the connection which is being authenticated, but it has nothing to do with the packets involved in doing the authenticated. It is a common issue with EAP authentication where the packet sizes grow beyond the MTU and get fragmented. In a well behaved network, the fragments will get re-assembled, but there are cases where fragments get dropped by firewalls and so the authentication fails.

into /etc/raddb/sites-enabled/default in the post-auth section. Gemini points to a comment block that says: "# Please do not put "unlang" configurations into the "authenticate" # section. Put them in the "post-auth" section instead. That's what # the post-auth section is for."

That is completely wrong - authenticate is another process section just like "authorize" and "post-auth" which contains unlang.  Usually it's only module calls to the modules performing the authentication, but it can have more complex policy.  It's all about where in the packet processing you need to perform given actions.

In a previous email, https://lists.freeradius.org/pipermail/freeradius-users/2022-March/101630.ht...,  to this list, it sounds like it could be in sites-available/default

Aren't they symlinks?

Usually sites-available contains symlinks to files in sites-enabled - but it can have normal files as well.  The sites-available / sites-enabled construct is simply a way to provide a load of sample virtual servers and then just use a symlink to enable the relevant ones to the system. So, you can add that update section to post-auth if you want to - but it is not likely to be achieving what you want. 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. Nick -- Nick Porter