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