radiusd debug understanding help needed (EAP session for state 0x... did not finish)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, please, help me to be sure I understand `radiusd -X' output right way ... some period of time, FR with EAP-TLS + LDAP was working in "test mode" ... now it is not and I'm trying to understand why FR: server is v.2.2.6 on FreeBSD 10.1R WS: wpa_supplicant client on FreeBSD 10.1R network (LAN) topology: FR <-> 100Mb Switch <-> WS FR configured with EAP + LDAP and EAP/md5 for MAC auth works fine. but EAP/tls spawns: WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING: !! EAP session for state 0x8c1a57f7885a5afa did not finish! WARNING: !! Please read http://wiki.freeradius.org/guide/Certificate_Compatibility WARNING: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! on this wiki page for this case it is told: - - - Follow the instructions given above. it is what I have folowed - - - Consider to decreasing the tunnel MTU there is no tunnel, but decreasing MTU on NIC didn't help last time I faced this very problem on my VPN and MTU decreasing to 1250 helped well, but now it is not ... in `radiusd -X' I see this: - - ---[ quotation start ]------------------------------------------- ... [files] expand: %{User-Name}, you have came from %{NAS-IP-Address} copper port %{NAS-Port}. -> jdoe-eap, you have came from 192.168.0.1 copper port 14. ++[files] = ok ++[expiration] = noop ++[logintime] = noop ++[pap] = noop [ldap] performing user authorization for jdoe-eap [ldap] expand: %{Stripped-User-Name} -> [ldap] ... expanding second conditional [ldap] expand: %{User-Name} -> jdoe-eap [ldap] expand: (&(cn=%{%{Stripped-User-Name}:-%{User-Name}})(|(authorizedService=802.1x-mac@xyz)(authorizedService=802.1x-eap@xyz)(authorizedService=802.1x@xyz))) -> (&(cn=jdoe-eap)(|(autho rizedService=802.1x-mac@xyz)(authorizedService=802.1x-eap@xyz)(authorizedService=802.1x@xyz))) [ldap] expand: ou=People,dc=xyz -> ou=People,dc=xyz [ldap] ldap_get_conn: Checking Id: 0 [ldap] ldap_get_conn: Got Id: 0 [ldap] performing search in ou=People,dc=xyz, with filter (&(cn=jdoe-eap)(|(authorizedService=802.1x-mac@xyz)(authorizedService=802.1x-eap@xyz)(authorizedService=802.1x@xyz))) [ldap] performing search in cn=ethernet,ou=rad-profiles,dc=xyz, with filter (objectclass=radiusprofile) [ldap] radiusTunnelMediumType -> Tunnel-Medium-Type:0 = IEEE-802 [ldap] radiusTunnelType -> Tunnel-Type:0 = VLAN [ldap] radiusSessionTimeout -> Session-Timeout = 900 [ldap] looking for check items in directory... [ldap] userPassword -> Cleartext-Password == "jdoe-eap" [ldap] userPassword -> Password-With-Header == "jdoe-eap" [ldap] looking for reply items in directory... [ldap] radiusTunnelPrivateGroupId -> Tunnel-Private-Group-Id:0 = "3495" [ldap] radiusTunnelMediumType -> Tunnel-Medium-Type:0 = IEEE-802 [ldap] radiusTunnelType -> Tunnel-Type:0 = VLAN [ldap] radiusServiceType -> Service-Type = Framed-User [ldap] ldap_release_conn: Release Id: 0 ++[ldap] = ok - - ---[ quotation end ]------------------------------------------- so, am I correct? here it is written that LDAP auth performed successfully further: - - ---[ quotation start ]------------------------------------------- ++? if (notfound) ? Evaluating (notfound) -> FALSE ++? if (notfound) -> FALSE ++? if (reject) ? Evaluating (reject) -> FALSE ++? if (reject) -> FALSE +} # group authorize = updated Found Auth-Type = EAP # Executing group from file /usr/local/etc/raddb/sites-enabled/default +group authenticate { [eap] Request found, released from the list [eap] EAP/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS [tls] Received TLS ACK [tls] ACK handshake fragment handler [tls] eaptls_verify returned 1 [tls] eaptls_process returned 13 ++[eap] = handled +} # group authenticate = handled ... - - ---[ quotation end ]------------------------------------------- what does these rows mean? - - ---[ quotation start ]------------------------------------------- [tls] eaptls_verify returned 1 [tls] eaptls_process returned 13 ++[eap] = handled +} # group authenticate = handled - - ---[ quotation end ]------------------------------------------- wpa_supplicant debug shows this: - - ---[ quotation start ]------------------------------------------- ... 1434988426.933490: SSL: (where=0x1001 ret=0x1) 1434988426.933492: SSL: SSL_connect:SSLv3 read server hello A 1434988426.933731: TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=1 buf='/C=AU/ST=SDN/L=Sidney/O=RADIUS/OU=RADIUS/CN=changeme/emailAddress=security@xyz' 1434988426.933736: igb0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=AU/ST=SDN/L=Sidney/O=RADIUS/OU=RADIUS/CN=xyz-ca/emailAddress=security@xyz' 1434988426.933738: EAP: Status notification: remote certificate verification (param=success) 1434988426.933814: TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=0 buf='/C=AU/ST=SDN/L=Sidney/O=RADIUS/OU=RADIUS/CN=office1.xyz/emailAddress=security@xyz' 1434988426.933818: igb0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=AU/ST=SDN/L=Sidney/O=RADIUS/OU=RADIUS/CN=office1.xyz/emailAddress=security@xyz' 1434988426.934102: EAP: Status notification: remote certificate verification (param=success) 1434988426.934106: SSL: (where=0x1001 ret=0x1) 1434988457.029252: SSL: SSL_connect:SSLv3 write finished A 1434988457.029254: SSL: (where=0x1001 ret=0x1) 1434988457.029255: SSL: SSL_connect:SSLv3 flush data 1434988457.029257: SSL: (where=0x1002 ret=0xffffffff) 1434988457.029258: SSL: SSL_connect:error in SSLv3 read finished A 1434988457.029260: SSL: SSL_connect - want more data 1434988457.029262: SSL: 2750 bytes pending from ssl_out 1434988457.029264: SSL: 2750 bytes left to be sent out (of total 2750 bytes) 1434988457.029266: SSL: sending 1398 bytes, more fragments will follow 1434988457.029268: EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL 1434988457.029270: EAP: EAP entering state SEND_RESPONSE 1434988457.029272: EAP: EAP entering state IDLE 1434988457.029273: EAPOL: SUPP_BE entering state RESPONSE 1434988457.029274: EAPOL: txSuppRsp 1434988457.029276: TX EAPOL: dst=01:80:c2:00:00:03 1434988457.029278: TX EAPOL - hexdump(len=1412): 01 00 ... ... 1 09 01 16 0c 73 65 63 75 72 69 74 79 40 69 62 73 30 1e 17 0d 31 34 30 33 31 30 31 1434988457.030267: EAPOL: SUPP_BE entering state RECEIVE ... 1434989781.980570: igb0: RX EAPOL from 34:db:fd:81:43:2b 1434989781.980571: RX EAPOL - hexdump(len=46): 01 00 00 04 04 cf 00 04 00 00 ... 1434989781.980579: EAPOL: Received EAP-Packet frame 1434989781.980580: EAPOL: SUPP_BE entering state REQUEST 1434989781.980581: EAPOL: getSuppRsp 1434989781.980582: EAP: EAP entering state RECEIVED 1434989781.980584: EAP: Received EAP-Failure 1434989781.980585: EAP: Status notification: completion (param=failure) 1434989781.980587: EAP: EAP entering state FAILURE 1434989781.980589: igb0: CTRL-EVENT-EAP-FAILURE EAP authentication failed 1434989781.980590: EAPOL: SUPP_PAE entering state HELD 1434989781.980591: EAPOL: Supplicant port status: Unauthorized 1434989781.980593: EAPOL: SUPP_BE entering state RECEIVE 1434989781.980594: EAPOL: SUPP_BE entering state FAIL 1434989781.980595: EAPOL: SUPP_BE entering state IDLE 1434989781.980596: EAPOL authentication completed unsuccessfully ... - - ---[ quotation end ]------------------------------------------- looks like OpenSSL related something, is it? so, may somebody advise where to look at? how to know who is guilty? - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWIPtsACgkQr3jpPg/3oyoZIwCg5AcO12uDdmpWBPvLskHTp4ct X3IAn0QOx/e0dLm+6erzEMKeTW6LB5Z2 =DtVP -----END PGP SIGNATURE-----
On Jun 22, 2015, at 12:59 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
Signed PGP part hi,
please, help me to be sure I understand `radiusd -X' output right way ...
I agree, it does look like an MTU issue. But that's v2 output, which we no longer support. Upgrade to v3.0.x preferably v3.0.x HEAD as I just added a bunch of useful debug output, and provide debug output from that. -Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
please, help me to be sure I understand `radiusd -X' output right way ... I agree, it does look like an MTU issue. But that's v2 output, which we no longer support. Upgrade to v3.0.x preferably v3.0.x HEAD as I just added a bunch of useful debug output, and provide debug output from that.
I have upgraded to freeradius3-3.0.8 (not head since I install it from ports and it the last one available) and result looks the same ... PKI used is the one, created during the installation bellow is the output: in `radiusd -X' I see this ---[ quotation start ]------------------------------------------- ... (141) files: Processing radiusGroupName value "ethernet" as a group name rlm_ldap (ldap): Released connection (24) (141) files: User is not a member of "bootp" (141) files: users: Matched entry DEFAULT at line 288 (141) files: EXPAND %{User-Name}, you have came from %{NAS-IP-Address} copper port %{NAS-Port}. (141) files: --> jdoe-eap, you have came from 192.168.0.1 copper port 14. (141) [files] = ok rlm_ldap (ldap): Reserved connection (24) (141) ldap: EXPAND (&(cn=%{%{Stripped-User-Name}:-%{User-Name}})(|(authorizedService=802.1x-mac@xyz)(authorizedService=802.1x-eap@xyz)(authorizedService=802.1x@xyz))) (141) ldap: --> (&(cn=jdoe-eap)(|(authorizedService=802.1x-mac@xyz)(authorizedService=802.1x-eap@xyz)(authorizedService=802.1x@xyz))) (141) ldap: Performing search in "ou=People,dc=xyz" with filter "(&(cn=jdoe-eap)(|(authorizedService=802.1x-mac@xyz)(authorizedService=802.1x-eap@xyz)(authorizedService=802.1x@xyz)))", scope "sub" (141) ldap: Waiting for search result... (141) ldap: User object found at DN "uid=jdoe-eap,authorizedService=802.1x-eap@xyz,uid=it-jdoe,ou=People,dc=xyz" (141) ldap: Processing user attributes (141) ldap: control:Password-With-Header += 'jdoe-eap' (141) ldap: reply:Tunnel-Type := VLAN (141) ldap: reply:Tunnel-Medium-Type := IEEE-802 (141) ldap: reply:Tunnel-Private-Group-ID := '3495' rlm_ldap (ldap): Released connection (24) (141) [ldap] = updated (141) [expiration] = noop (141) [logintime] = noop (141) pap: No {...} in Password-With-Header, re-writing to Cleartext-Password (141) pap: Removing &control:Password-With-Header (141) pap: WARNING: Auth-Type already set. Not setting to PAP (141) [pap] = noop (141) if (notfound){ (141) if (notfound) -> FALSE (141) if (reject){ (141) if (reject) -> FALSE (141) } # authorize = updated (141) Found Auth-Type = EAP (141) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (141) authenticate { (141) eap: Expiring EAP session with state 0x6aedf5cd69e3f8dd (141) eap: Finished EAP session with state 0x6aedf5cd69e3f8dd (141) eap: Previous EAP request found for state 0x6aedf5cd69e3f8dd, released from the list (141) eap: Peer sent method TLS (13) (141) eap: EAP TLS (13) (141) eap: Calling eap_tls to process EAP data (141) eap_tls: Authenticate (141) eap_tls: processing EAP-TLS (141) eap_tls: Received TLS ACK (141) eap_tls: Received TLS ACK (141) eap_tls: ACK handshake fragment handler (141) eap_tls: eaptls_verify returned 1 (141) eap_tls: eaptls_process returned 13 (141) eap: EAP session adding &reply:State = 0x6aedf5cd6ee2f8dd (141) [eap] = handled (141) } # authenticate = handled (141) Using Post-Auth-Type Challenge (141) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (141) Sent Access-Challenge Id 0 from 192.168.0.254:1812 to 192.168.0.1:49205 length 1032 (141) Reply-Message = 'jdoe-eap, you have came from 192.168.0.1 copper port 14.' (141) Tunnel-Type := VLAN (141) Tunnel-Medium-Type := IEEE-802 (141) Tunnel-Private-Group-Id := '3495' (141) EAP-Message = 0x010f03790d8000000b33696361746520417574686f7269747982 ... (141) Message-Authenticator = 0x00000000000000000000000000000000 (141) State = 0x6aedf5cd6ee2f8dd653acce97afb91c3 (141) Finished request Waking up in 0.3 seconds. Waking up in 4.6 seconds. (141) <done>: Cleaning up request packet ID 0 with timestamp +1513 Ready to process requests ... ---[ quotation end ]------------------------------------------- wpa_supplicant debug shows this: ---[ quotation start ]------------------------------------------- ... 1435088855.951675: EAPOL: Received EAP-Packet frame 1435088855.951676: EAPOL: SUPP_BE entering state REQUEST 1435088855.951677: EAPOL: getSuppRsp 1435088855.951678: EAP: EAP entering state RECEIVED 1435088855.951683: EAP: Received EAP-Request id=106 method=13 vendor=0 vendorMethod=0 1435088855.951685: EAP: EAP entering state METHOD 1435088855.951687: SSL: Received packet(len=889) - Flags 0x80 1435088855.951688: SSL: TLS Message Length: 2867 1435088855.951706: SSL: (where=0x1001 ret=0x1) 1435088855.951708: SSL: SSL_connect:SSLv3 read server hello A 1435088855.951922: TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=1 buf='/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificate Authority' 1435088855.951932: igb0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificate Authority' 1435088855.951934: EAP: Status notification: remote certificate verification (param=success) 1435088855.952016: TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=0 buf='/C=FR/ST=Radius/O=Example Inc./CN=Example Server Certificate/emailAddress=admin@example.com' 1435088855.952020: igb0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=FR/ST=Radius/O=Example Inc./CN=Example Server Certificate/emailAddress=admin@example.com' 1435088855.952302: EAP: Status notification: remote certificate verification (param=success) 1435088855.952308: SSL: (where=0x1001 ret=0x1) 1435088855.952310: SSL: SSL_connect:SSLv3 read server certificate A 1435088855.952395: SSL: (where=0x1001 ret=0x1) 1435088855.952397: SSL: SSL_connect:SSLv3 read server key exchange A 1435088855.952416: SSL: (where=0x1001 ret=0x1) 1435088855.952417: SSL: SSL_connect:SSLv3 read server certificate request A 1435088855.952419: SSL: (where=0x1001 ret=0x1) 1435088855.952420: SSL: SSL_connect:SSLv3 read server done A 1435088855.952506: SSL: (where=0x1001 ret=0x1) 1435088855.952509: SSL: SSL_connect:SSLv3 write client certificate A 1435088855.953325: SSL: (where=0x1001 ret=0x1) 1435088855.953328: SSL: SSL_connect:SSLv3 write client key exchange A 1435088855.955164: SSL: (where=0x1001 ret=0x1) 1435088855.955167: SSL: SSL_connect:SSLv3 write certificate verify A 1435088855.955232: SSL: (where=0x1001 ret=0x1) 1435088855.955234: SSL: SSL_connect:SSLv3 write change cipher spec A 1435088855.955251: SSL: (where=0x1001 ret=0x1) 1435088855.955252: SSL: SSL_connect:SSLv3 write finished A 1435088855.955256: SSL: (where=0x1001 ret=0x1) 1435088855.955257: SSL: SSL_connect:SSLv3 flush data 1435088855.955259: SSL: (where=0x1002 ret=0xffffffff) 1435088855.955260: SSL: SSL_connect:error in SSLv3 read finished A 1435088855.955262: SSL: SSL_connect - want more data 1435088855.955263: SSL: 2651 bytes pending from ssl_out 1435088855.955266: SSL: 2651 bytes left to be sent out (of total 2651 bytes) 1435088855.955267: SSL: sending 1398 bytes, more fragments will follow 1435088855.955269: EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL 1435088855.955271: EAP: EAP entering state SEND_RESPONSE 1435088855.955273: EAP: EAP entering state IDLE 1435088855.955274: EAPOL: SUPP_BE entering state RESPONSE 1435088855.955275: EAPOL: txSuppRsp 1435088855.955277: TX EAPOL: dst=01:80:c2:00:00:03 1435088855.955279: TX EAPOL - hexdump(len=1412): 01 00 05 80 ... 1435088885.940665: EAPOL: Received EAP-Packet frame 1435088885.940667: EAPOL: SUPP_BE entering state REQUEST 1435088885.940668: EAPOL: getSuppRsp 1435088885.940669: EAP: EAP entering state RECEIVED 1435088885.940676: EAP: Received EAP-Request id=106 method=13 vendor=0 vendorMethod=0 1435088885.940678: EAP: EAP entering state RETRANSMIT 1435088885.940680: EAP: EAP entering state SEND_RESPONSE 1435088885.940681: EAP: EAP entering state IDLE 1435088885.940682: EAPOL: SUPP_BE entering state RESPONSE 1435088885.940683: EAPOL: txSuppRsp 1435088885.940685: TX EAPOL: dst=01:80:c2:00:00:03 1435088885.940687: TX EAPOL - hexdump(len=1412): 01 ... ... ---[ quotation end ]------------------------------------------- MTU tried (inteface is ethernet, not tun) are 1500 and 1250 what am I missing? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
On Jun 23, 2015, at 4:32 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
please, help me to be sure I understand `radiusd -X' output right way ... I agree, it does look like an MTU issue. But that's v2 output, which we no longer support. Upgrade to v3.0.x preferably v3.0.x HEAD as I just added a bunch of useful debug output, and provide debug output from that.
I have upgraded to freeradius3-3.0.8 (not head since I install it from ports and it the last one available) and result looks the same ...
Upgrade to v3.0.x HEAD as I just added a bunch of useful debug output, and provide the debug output from that. -Arran
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Upgrade to v3.0.x HEAD as I just added a bunch of useful debug output, and provide the debug output from that.
I have upgraded to the rev 627f748a0f
radiusd -v radiusd: FreeRADIUS Version 3.0.9, for host amd64-portbld-freebsd10.1, built on Jun 24 2015 at 11:20:18
test shows the same behaviour :( since overal size of debug is rather big, I uploaded it to dropbox, here is URL: https://www.dropbox.com/sh/ts63g3iv4ckwsof/AADkbTFJGUvqbvGlN9gSFXaSa?dl=0 - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWLsyAACgkQr3jpPg/3oypTEQCgkG7HKb6EleYrnz8BbLumVP18 jP8AnjMsni5P6yBRIMSr3k+amqJ2CxTs =fn0c -----END PGP SIGNATURE-----
On 25 Jun 2015, at 03:52, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
Signed PGP part Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Upgrade to v3.0.x HEAD as I just added a bunch of useful debug output, and provide the debug output from that.
I have upgraded to the rev 627f748a0f
radiusd -v radiusd: FreeRADIUS Version 3.0.9, for host amd64-portbld-freebsd10.1, built on Jun 24 2015 at 11:20:18
test shows the same behaviour :( since overal size of debug is rather big, I uploaded it to dropbox, here is URL:
https://www.dropbox.com/sh/ts63g3iv4ckwsof/AADkbTFJGUvqbvGlN9gSFXaSa?dl=0
I answered you off list yesterday... The other issue you may want to look for is whether IP fragmentation is being performed correctly, so you'll need PCAPs from the AP and intermediary routers up to the RADIUS server. For the benefit of the list users, here's my original response: Mmm, but with better debugging. The key bits of extra info, are the flags set in the EAP-TLS fragments, the indicated size and actual size of the fragments, and the incoming/outgoing EAP packet IDs. The key with MTU issues is to look at the last request/response between the supplicant. Usually you'll see a packet go out from the server, and never reach the supplicant, or a packet be sent by the supplicant and never reach the server. In this case it's the supplicant's fragment not reaching the server. We see it respond to the EAP request with ID 153, by packing up the first fragment of its certificate chain, and sending it. The size of that fragment, is pretty big, 1398 bytes. I think only fragments up to 1020 bytes are guaranteed to be handled by the authenticator. 1435137443.632654: EAP: EAP entering state RECEIVED 1435137443.632657: EAP: Received EAP-Request id=154 method=13 vendor=0 vendorMethod=0 1435137443.632659: EAP: EAP entering state METHOD 1435137443.632660: SSL: Received packet(len=889) - Flags 0x80 1435137443.632661: SSL: TLS Message Length: 2867 1435137443.632685: SSL: (where=0x1001 ret=0x1) 1435137443.632686: SSL: SSL_connect:SSLv3 read server hello A 1435137443.632988: TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=1 buf='/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificat e Authority' 1435137443.632996: igb0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificate Authority' 1435137443.632999: EAP: Status notification: remote certificate verification (param=success) 1435137443.633114: TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=0 buf='/C=FR/ST=Radius/O=Example Inc./CN=Example Server Certificate/emailAddress=admin@example.com' 1435137443.633120: igb0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=FR/ST=Radius/O=Example Inc./CN=Example Server Certificate/emailAddress=admin@example.com' 1435137443.633297: EAP: Status notification: remote certificate verification (param=success) 1435137443.633307: SSL: (where=0x1001 ret=0x1) 1435137443.633309: SSL: SSL_connect:SSLv3 read server certificate A 1435137443.633421: SSL: (where=0x1001 ret=0x1) 1435137443.633423: SSL: SSL_connect:SSLv3 read server key exchange A 1435137443.633444: SSL: (where=0x1001 ret=0x1) 1435137443.633446: SSL: SSL_connect:SSLv3 read server certificate request A 1435137443.633447: SSL: (where=0x1001 ret=0x1) 1435137443.633449: SSL: SSL_connect:SSLv3 read server done A 1435137443.633541: SSL: (where=0x1001 ret=0x1) 1435137443.633544: SSL: SSL_connect:SSLv3 write client certificate A 1435137443.634368: SSL: (where=0x1001 ret=0x1) 1435137443.634372: SSL: SSL_connect:SSLv3 write client key exchange A 1435137443.636241: SSL: (where=0x1001 ret=0x1) 1435137443.636245: SSL: SSL_connect:SSLv3 write certificate verify A 1435137443.636315: SSL: (where=0x1001 ret=0x1) 1435137443.636317: SSL: SSL_connect:SSLv3 write change cipher spec A 1435137443.636336: SSL: (where=0x1001 ret=0x1) 1435137443.636338: SSL: SSL_connect:SSLv3 write finished A 1435137443.636345: SSL: (where=0x1001 ret=0x1) 1435137443.636346: SSL: SSL_connect:SSLv3 flush data 1435137443.636348: SSL: (where=0x1002 ret=0xffffffff) 1435137443.636349: SSL: SSL_connect:error in SSLv3 read finished A 1435137443.636351: SSL: SSL_connect - want more data 1435137443.636353: SSL: 2651 bytes pending from ssl_out 1435137443.636356: SSL: 2651 bytes left to be sent out (of total 2651 bytes) 1435137443.636358: SSL: sending 1398 bytes, more fragments will follow 1435137443.636360: EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL 1435137443.636362: EAP: EAP entering state SEND_RESPONSE 1435137443.636363: EAP: EAP entering state IDLE 1435137443.636364: EAPOL: SUPP_BE entering state RESPONSE 1435137443.636365: EAPOL: txSuppRsp 1435137443.636368: TX EAPOL: dst=01:80:c2:00:00:03 1435137443.636370: TX EAPOL - hexdump(len=1412): 01 00 05 80 02 9a 05 80 0d c0 00 00 0a 5b ... In request 6, we'd expect to see the server receiving that TLS fragment, but we don't. We instead see the supplicant restarting authentication. Looking at the timestamps, probably after timing out receiving a response from the server. So yes, this is definitely an MTU issue on the path from the Supplicant to the RADIUS server. I'm guessing as you have wpa_supplicant set to wired, you're doing wired 802.1X? So your switch is junk, and you either need to call the vendor and complain, or get a new switch. I've seen this exact same problem problem with Meraki access points. There's absolutely nothing you can do to fix it, because there's no MTU negotiation mechanism in EAP, and most supplicants do not expose an MTU control. So a vendor fix is the only option. The issue only shows up when doing EAP-TLS because all the packets sent supplicant to authenticator for PEAP and TTLS-PAP are relatively small. EAP-TLS however, requires the supplicant to send large chunks of certificate. Could you provide the make/model of the device (if it really is a switch), or the version if it's a software authenticator, just for my own edification. If it's software we might be able to submit a patch. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
The size of that fragment, is pretty big, 1398 bytes. I think only fragments up to 1020 bytes are guaranteed to be handled by the authenticator.
Excellent analysis, just wondering about that sentence? The RADIUS side of the authenticator has to be prepared to get 4k RADIUS packets (with arbitrarily much of that being EAP-Message), and the EAPoL side of the authenticator needs to support sending the local link's MTU minus EAPoL headers as payload. I don't recall any "grace" boundaries below that. Can you cite where they would come from? FWIW, our eduroam Monitoring intentionally sends 4k RADIUS to test for proper fragmentation support. Not sure how much we stuff into the EAP-Messages inside those big packets though. Stefan
1435137443.632654: EAP: EAP entering state RECEIVED 1435137443.632657: EAP: Received EAP-Request id=154 method=13 vendor=0 vendorMethod=0 1435137443.632659: EAP: EAP entering state METHOD 1435137443.632660: SSL: Received packet(len=889) - Flags 0x80 1435137443.632661: SSL: TLS Message Length: 2867 1435137443.632685: SSL: (where=0x1001 ret=0x1) 1435137443.632686: SSL: SSL_connect:SSLv3 read server hello A 1435137443.632988: TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=1 buf='/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificat e Authority' 1435137443.632996: igb0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin@example.com/CN=Example Certificate Authority' 1435137443.632999: EAP: Status notification: remote certificate verification (param=success) 1435137443.633114: TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=0 buf='/C=FR/ST=Radius/O=Example Inc./CN=Example Server Certificate/emailAddress=admin@example.com' 1435137443.633120: igb0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=FR/ST=Radius/O=Example Inc./CN=Example Server Certificate/emailAddress=admin@example.com' 1435137443.633297: EAP: Status notification: remote certificate verification (param=success) 1435137443.633307: SSL: (where=0x1001 ret=0x1) 1435137443.633309: SSL: SSL_connect:SSLv3 read server certificate A 1435137443.633421: SSL: (where=0x1001 ret=0x1) 1435137443.633423: SSL: SSL_connect:SSLv3 read server key exchange A 1435137443.633444: SSL: (where=0x1001 ret=0x1) 1435137443.633446: SSL: SSL_connect:SSLv3 read server certificate request A 1435137443.633447: SSL: (where=0x1001 ret=0x1) 1435137443.633449: SSL: SSL_connect:SSLv3 read server done A 1435137443.633541: SSL: (where=0x1001 ret=0x1) 1435137443.633544: SSL: SSL_connect:SSLv3 write client certificate A 1435137443.634368: SSL: (where=0x1001 ret=0x1) 1435137443.634372: SSL: SSL_connect:SSLv3 write client key exchange A 1435137443.636241: SSL: (where=0x1001 ret=0x1) 1435137443.636245: SSL: SSL_connect:SSLv3 write certificate verify A 1435137443.636315: SSL: (where=0x1001 ret=0x1) 1435137443.636317: SSL: SSL_connect:SSLv3 write change cipher spec A 1435137443.636336: SSL: (where=0x1001 ret=0x1) 1435137443.636338: SSL: SSL_connect:SSLv3 write finished A 1435137443.636345: SSL: (where=0x1001 ret=0x1) 1435137443.636346: SSL: SSL_connect:SSLv3 flush data 1435137443.636348: SSL: (where=0x1002 ret=0xffffffff) 1435137443.636349: SSL: SSL_connect:error in SSLv3 read finished A 1435137443.636351: SSL: SSL_connect - want more data 1435137443.636353: SSL: 2651 bytes pending from ssl_out 1435137443.636356: SSL: 2651 bytes left to be sent out (of total 2651 bytes) 1435137443.636358: SSL: sending 1398 bytes, more fragments will follow 1435137443.636360: EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL 1435137443.636362: EAP: EAP entering state SEND_RESPONSE 1435137443.636363: EAP: EAP entering state IDLE 1435137443.636364: EAPOL: SUPP_BE entering state RESPONSE 1435137443.636365: EAPOL: txSuppRsp 1435137443.636368: TX EAPOL: dst=01:80:c2:00:00:03 1435137443.636370: TX EAPOL - hexdump(len=1412): 01 00 05 80 02 9a 05 80 0d c0 00 00 0a 5b ...
In request 6, we'd expect to see the server receiving that TLS fragment, but we don't. We instead see the supplicant restarting authentication. Looking at the timestamps, probably after timing out receiving a response from the server.
So yes, this is definitely an MTU issue on the path from the Supplicant to the RADIUS server.
I'm guessing as you have wpa_supplicant set to wired, you're doing wired 802.1X? So your switch is junk, and you either need to call the vendor and complain, or get a new switch.
I've seen this exact same problem problem with Meraki access points. There's absolutely nothing you can do to fix it, because there's no MTU negotiation mechanism in EAP, and most supplicants do not expose an MTU control. So a vendor fix is the only option.
The issue only shows up when doing EAP-TLS because all the packets sent supplicant to authenticator for PEAP and TTLS-PAP are relatively small. EAP-TLS however, requires the supplicant to send large chunks of certificate.
Could you provide the make/model of the device (if it really is a switch), or the version if it's a software authenticator, just for my own edification.
If it's software we might be able to submit a patch.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 25, 2015, at 12:09 PM, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
The size of that fragment, is pretty big, 1398 bytes. I think only fragments up to 1020 bytes are guaranteed to be handled by the authenticator.
Excellent analysis,
The extra debug really helps. There was much cursing when I discovered (at a customer site) that FreeRADIUS didn't print the outbound request IDs, or length of the request packets, or any of the fragmentation information, or the what the various return codes from eaptls_verify meant.
just wondering about that sentence? The RADIUS side of the authenticator has to be prepared to get 4k RADIUS packets (with arbitrarily much of that being EAP-Message), and the EAPoL side of the authenticator needs to support sending the local link's MTU minus EAPoL headers as payload.
TBH I was parroting Alan's analysis of the RFC. If you don't agree that 1020 is the minimum EAP MTU, then you're more than welcome to continue that conversation with him :) RFC 3748 - Extensible Authentication Protocol (EAP) Section 3.1 assumption [4]. 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. Taking into account the overhead of EAP-TLS which is 6 or 10 bytes, depending on whether it's the first in a sequence of fragments and the TLS Message Length is included. In the absence of link MTU information the maximum TLS fragment size would be 1010 bytes in the first packet, and 1014 in subsequent ones. If the supplicant did have link MTU information available, then RFC 3748 does hint that the supplicant could send larger packets. IEEE 802.1X-2001 is silent on EAP fragments, other than describing the Framed-MTU attribute, which represents the EAP MTU between the Supplicant and Authenticator. -Arran
Hi,
TBH I was parroting Alan's analysis of the RFC. If you don't agree that 1020 is the minimum EAP MTU, then you're more than welcome to continue that conversation with him :)
RFC 3748 - Extensible Authentication Protocol (EAP)
Section 3.1 assumption [4].
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.
Taking into account the overhead of EAP-TLS which is 6 or 10 bytes, depending on whether it's the first in a sequence of fragments and the TLS Message Length is included.
In the absence of link MTU information the maximum TLS fragment size would be 1010 bytes in the first packet, and 1014 in subsequent ones.
If the supplicant did have link MTU information available, then RFC 3748 does hint that the supplicant could send larger packets.
IEEE 802.1X-2001 is silent on EAP fragments, other than describing the Framed-MTU attribute, which represents the EAP MTU between the Supplicant and Authenticator.
Right; there's next to always a Framed-MTU available, so this limit doesn't "usually" hurt in real life. 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 (and the preceding documentation text speaks about "half of 4096") Here's a pull request: https://github.com/restena-sw/freeradius-server/pull/1 Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Degrade the server due to a few broken NAS in the world? The broken kit should go in the bin. ...or the admin read the docs and set their default value. Not everyone else suffer. alan
Hi,
Degrade the server due to a few broken NAS in the world? The broken kit should go in the bin. ...or the admin read the docs and set their default value. Not everyone else suffer.
Well the server is already degraded - current default is 1024, while the most useful spot would probably close to 1500. Lowering by a few bytes (14) doesn't hurt much, but can help lots if you are facing such gear. Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Yes but in a federated world we ALL face that kit. So if in eg eduroam a single SO has that kit in place then ALL the IDPs would have to change their configuration to have that lower frag value. I'm not even sure some servers can set that value let alone the logistics. Put broken kit in the bin. alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Winter <stefan.winter@restena.lu> wrote:
Right; there's next to always a Framed-MTU available, so this limit doesn't "usually" hurt in real life.
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
yes, it was absent in my configuration, now I have set it but nothing changed ... no Framed-MTU mentioning in debug ... - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWNFVEACgkQr3jpPg/3oypBOQCgtvLxg38tPRwFt+f6ftN6cY2u w/QAn3ryQ2dG2mezATt4vs43WPmlhIqp =cjwq -----END PGP SIGNATURE-----
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
That default works. IIRC, it used to be larger, and things broke.
(and the preceding documentation text speaks about "half of 4096")
Here's a pull request:
If it works for you, we can look at changing the defaults. But I’m not going to do that in the main FR release until I know it won’t break peoples systems. Alan DeKok.
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? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
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
Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
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.
absolutely do not know why didn't I provided this info yet ... the switch FR and supplicant connected to is: Cisco SF300-24 24-Port 10/100 Managed Switch -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
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.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
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.
will it be enough just tcpdump -ni interfase-for-auth host my.freeradius.foo on both FR and supplicant? since both of them are FreeBSD boxes, and the switch they are connected to has no tool to capture packets ... -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
On Jun 26, 2015, at 3:16 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
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.
will it be enough just
tcpdump -ni interfase-for-auth host my.freeradius.foo
on both FR and supplicant?
since both of them are FreeBSD boxes, and the switch they are connected to has no tool to capture packets ...
No, it's not enough. Buy a 10/100 hub and use that to mirror the packets. http://www.ebay.ca/itm/NetGear-DS309-9-Port-10-100-Dual-Speed-Hub-Network-Sw... These things are invaluable for diagnostics. -Arran
On Jun 26, 2015, at 3:29 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Jun 26, 2015, at 3:16 PM, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
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.
will it be enough just
tcpdump -ni interfase-for-auth host my.freeradius.foo
on both FR and supplicant?
since both of them are FreeBSD boxes, and the switch they are connected to has no tool to capture packets ...
No, it's not enough.
Buy a 10/100 hub and use that to mirror the packets.
http://www.ebay.ca/itm/NetGear-DS309-9-Port-10-100-Dual-Speed-Hub-Network-Sw...
These things are invaluable for diagnostics.
and it has to be a *HUB* not a switch. this is a possibly cheaper alternative. https://greatscottgadgets.com/throwingstar/ -Arran
greetings, thanks to everybody very much! the problem resolution, in my case, was too simple ... firmware upgrade ... firmware with EAP-TLS issue was Sx300_FW_Boot_1.3.5.58.ros and firmware upgrade to Sx300_FW_Boot_1.4.1.03.ros fixed the issue -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users- bounces+jmdanner=samford.edu@lists.freeradius.org] On Behalf Of Zeus Panchenko Sent: Friday, June 26, 2015 2:17 PM To: FreeRadius users mailing list Subject: Re: radiusd debug understanding help needed (EAP session for state 0x... did not finish)
Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
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.
will it be enough just
tcpdump -ni interfase-for-auth host my.freeradius.foo
on both FR and supplicant?
since both of them are FreeBSD boxes, and the switch they are connected to has no tool to capture packets ...
The Cisco switch you mentioned supports port mirroring. Set up the appropriate mirror and use Wireshark on a laptop to capture.
-- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Right; there's next to always a Framed-MTU available, so this limit doesn't "usually" hurt in real life.
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
(and the preceding documentation text speaks about "half of 4096")
Here's a pull request:
Needs to be against the FreeRADIUS repo, but looks good :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Jun 25, 2015, at 12:09 PM, Stefan Winter <stefan.winter@restena.lu> wrote:
The size of that fragment, is pretty big, 1398 bytes. I think only fragments up to 1020 bytes are guaranteed to be handled by the authenticator.
Excellent analysis, just wondering about that sentence?
The specs say that the EAP peers (supplicant and AP) have to handle 1020 byte packets. My experience has been that some AP vendors interpret that to mean NO MORE THAN 1020 bytes. So when they get an EAPoL packet of 1300 bytes, the AP runs around in circles screaming... and discards the packet. It's 2015 for crying out loud. The AP should be able to handle 4K EAPoL packets. Memory isn't expensive, even for small APs.
The RADIUS side of the authenticator has to be prepared to get 4k RADIUS packets (with arbitrarily much of that being EAP-Message), and the EAPoL side of the authenticator needs to support sending the local link's MTU minus EAPoL headers as payload.
Yes. But why do that when you can read the spec, discover that 1020 bytes is OK, and then discard packets which are smaller than MTU, but larger than 1020 bytes?
I don't recall any "grace" boundaries below that. Can you cite where they would come from?
FWIW, our eduroam Monitoring intentionally sends 4k RADIUS to test for proper fragmentation support. Not sure how much we stuff into the EAP-Messages inside those big packets though.
If Framed-MTU is set, then the EAP packet size is limited by Framed-MTU. Alan DeKok.
participants (6)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Danner, Mearl -
Stefan Winter -
Zeus Panchenko