Hi, eap.conf states: # This can never exceed the size of a RADIUS # packet (4096 bytes), and is preferably half # that, to accomodate other attributes in # RADIUS packet. On most APs the MAX packet # length is configured between 1500 - 1600 # In these cases, fragment size should be # 1024 or less. # # fragment_size = 1024 I wonder what the sentence about MAX packet size on APs is about. Is it their maximum allowed length of a RADIUS packet? Frankly, that would be quite stupid because packets can legitimately be much larger than that. (-> RADIUS implementation problem on AP) If it is about fragmented and re-assembled UDP: that would mean those APs can't re-assemble UDP properly (-> again implementation problem) finally, if it's about the max layer-2 size for the EAP conversation: then a fragment size of 1500 would be okay on a 1500 MTU on layer 2 (and if one only authenticates 802.3 LANs and 802.11 WLANs, both of them handle 1500 just fine). So I wonder, why does anything impose specifically 1500-1600 on the AP side, and why does that imply 1024 is an upper bound for the fragment size? That question doesn't come from thin air: higher fragment size reduces amount of round-trips for an EAP auth (even though it generates more UDP packets on the wire, sure). And with EAP-TLS, there are supplicants that fill their 1500 on the layer 2 unconfigurably, and it appears to work well - if there's no firewall that discards the second fragment of the RADIUS message. So if the above holds true, I would much rather set fragment size to 1500, and fix any upcoming impl problems that have nothing to do with EAP frag size, rather than yield with my frag size. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473