On Jun 26, 2015, at 2:31 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
On Jun 26, 2015, at 2:05 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
Then again, if it gets filtered out, then the server should ship with a sane default, right? Looks like the current default isn't:
raddb/mods-available/eap -> tls-common: fragment_size = 1024
please, what am I missing? I configured fragment_size in raddb/mods-available/eap and raddb/mods-available/tls but still unable to see any Framed-MTU in debug ... why?
I'm going to bullet point this for simplicity: * fragment_size controls TLS Fragment size sent *TO* the supplicant *FROM* the RADIUS server. * Framed-MTU is optional. Your NAS doesn't need to send it. * The size of the fragments *FROM* the supplicant *TO* the RADIUS server are controlled by the supplicant, which it should infer from the link MTU. * The size of the fragments from your supplicant, are likely correct for the link MTU. * Your NAS is likely discarding packets from your supplicant because it's broken, or the network between your NAS and the RADIUS server is broken, and not doing UDP fragment transfer/reassembly properly. What you should do: 1. Provide packet captures from the supplicant. 2. Provide packet captures from the port on your NAS connected to the supplicant. 3. Provide packet captures from the uplink of your NAS, on which RADIUS traffic is sent. 4. Provide packet captures from the RADIUS server. We can then tell you where the problem lies for certain. Other things you should do: 1. Work with your NAS vendor for a fix. 2. Provide the make and model of your NAS so the vendor can be named and shamed. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2