> > The problem is ALWAYS the same. The Wiki page describes the problems, > and the solutions. >
That particular error is known to pop out when a Windows client uses a misconfigured certificate, or the MTU is too high. This case is neither one nor the other. > Try setting up the second server as a brand new server with brand new > certificates. Follow the *documented* process of setting up a new > server with EAP-TLS / PEAP. It *will* work. > I have no heavy modifications of the original configuration, just the minimum required for eap-peap-mschapv2 to work. Which has been copied from a working server. It's probably the cert. > I suspected that, but I'm making no progress with it, and I've ended with the process pretty much automated. I will continue doing tests, but i felt i was missing something else. If it's NOT the cert, then you need to investigate the AP/switch or the > client; FreeRADIUS is not receiving the next packet, so either the client > or the AP/switch has dropped / ignored it. > Maybe, but the only change made was the address where to point at. However, i should check that too. > One thing to check is MTU; you've trimmed the debug so it's hard to know, > but usually the next EAP packet would be large(-ish). > Framed-MTU = 1100 << from debug fragment_size = 1024 << eap.conf (default setting) Also check the client - look in the logs, or use tcpdump to check the > client actually receives the EAP packet, and sends a reply. Likewise the > AP/switch. > > Also check any firewalls inbetween. > Yes, it shows a conversation, so no dropped packets inbetween. -- Alberto Martínez Setién Servicio Informático Universidad de Deusto Avda. de las Universidades, 24 48007 - Bilbao (SPAIN) Phone: +34 - 94 413 90 00 Ext 2684 Fax: +34 - 94 413 91 01
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html