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
Stefan Winter wrote:
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)
No. It's Ethernet segment size. When the AP talks to the supplicant, it's via EAPoL (EAP over LAN). The EAP packets are put into the data portion of Ethernet packets. Since Ethernet packets can't be fragmented, there's a limit to the maximum EAP packet size.
If it is about fragmented and re-assembled UDP: that would mean those APs can't re-assemble UDP properly (-> again implementation problem)
That happens, too. It's easier to add code on the server than to fix buggy AP's.
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).
There is often additional information (VLAN, etc.) that can shrink the maximum Ethernet segment size.
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.
That's why it's configurable. Others have reported issues with fragment sizes larger than 1024. Some even need it to be less. Alan DeKok.
Hello On 24 Sep 2007, at 09:58, Alan DeKok wrote:
Stefan Winter wrote:
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)
The problem is that neither EAP per se nor EAPOL support fragmentation/reassembly, only certain EAP methods do. These however, by design, are not implemented on the NAS (i.e. AP). So you get a problem on the link when exceeding link MTU.
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.
That's why it's configurable. Others have reported issues with fragment sizes larger than 1024. Some even need it to be less.
Alan DeKok.
Set it to 1500 and try it out. If it works with your APs, fine. The RFC 3748 and the RFC 4017 only dictate Minumum MTU: From RFC3748 (interesting reading, explains the situation) [4] Minimum MTU. EAP is capable of functioning on lower layers that provide an EAP MTU size of 1020 octets or greater. EAP does not support path MTU discovery, and fragmentation and reassembly is not supported by EAP, nor by the methods defined in this specification: Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6), and expanded Nak Response (254) Types. Typically, the EAP peer obtains information on the EAP MTU from the lower layers and sets the EAP frame size to an appropriate value. Where the authenticator operates in pass-through mode, the authentication server does not have a direct way of determining the EAP MTU, and therefore relies on the authenticator to provide it with this information, such as via the Framed-MTU attribute, as described in [RFC 3579], Section 2.4. While methods such as EAP-TLS [RFC 2716] support fragmentation and reassembly, EAP methods originally designed for use within PPP where a 1500 octet MTU is guaranteed for control frames (see [RFC 1661], Section 6.1) may lack fragmentation and reassembly features. EAP methods can assume a minimum EAP MTU of 1020 octets in the absence of other information. EAP methods SHOULD include support for fragmentation and reassembly if their payloads can be larger than this minimum EAP MTU. However, I read once somewhere (cant' recall where) that in practice, it is *not* recommended to exceed approx. 1200 bytes MTU. Artur
participants (3)
-
Alan DeKok -
Artur Hecker -
Stefan Winter