attaching:
incident/client.pcap tcpdump capture from port 1812 at client side incident/radius.pcap tcpdump capture from port 1812 at server side incident/radius.log radius -X output incident/wpa_supplicant.conf client config
In this recorded test - yes client sends traffic directly to server via cisco sg350 switch both connected to ethernet.Are your APs sending traffic direct to ethernet (like standard home-type ones) or is there a tunnel involved (as some of the business type APs with a controller do)? Without the debug output from radiusd (and maybe also packet dumps) it's hard to give any more targetted suggestions.
I have setup with engenius ap and engenius controller - however the behaviour the same. If set fragment_size at client to lower value - it works.
Thank you. On 3/6/23 16:37, Stuart Henderson wrote:
On 2023/03/06 14:33, Mikhael Lialin wrote:Hello Stuart. I've created a separate thread about this in misc with Subject:(fragmented ipv4[udp] ignored by server.) . And sorry for this. Don't know why posts to this thread was not accepted. Basic set-up, recommended by you previously already working. Also if setIs that basic set-up as in radtest or is it eapol_test with one of the simpler EAP methods?fragment_size to less lower value - for example 1212 in wpa_supplicant.conf - this eap tls too works. Question - how to avoid client configuration by fragments_size and get it working? Cause some clients could not be altered so easily.Are your APs sending traffic direct to ethernet (like standard home-type ones) or is there a tunnel involved (as some of the business type APs with a controller do)? Without the debug output from radiusd (and maybe also packet dumps) it's hard to give any more targetted suggestions.Also certificate key size is 2048b. Thank you. On 3/6/23 12:03, Stuart Henderson wrote:On 2023/03/02 17:24, Mikhael Lialin wrote:Hello and good day. Finally found the actual reason. The outer client is failed eap tls because of packet fragmentation. on interface mtu is set as 1500, and packet is 1514. from tshark: RADIUS 1514 Access-Request id=4[BoundErrorUnreassembled Packet] RADIUS 1514 Access-Request id=4, Duplicate Request[BoundErrorUnreassembled Packet] RADIUS 1514 Access-Request id=4, Duplicate Request[BoundErrorUnreassembled Packet] RADIUS 1514 Access-Request id=4, Duplicate Request[BoundErrorUnreassembled Packet]What do you see from freeradius debug output when this happens?if set fragment_size to wpa_supplicant.conf to a little below value, it helps and eap_tls is successful. It's good for configurable client, however how about phones where all parameters are default ?It doesn't help you, but the RADIUS client is not the device trying to connect to wifi, it's the AP. It wasn't clear from your report, does it work with non-cert-based methods e.g. EAP MSCHAPv2 or not? If that's working and the problem is only with certificate auth, one thought, are you able to shrink the certs at all? If you're using 3072/4096 bit RSA keys, try 2048bit instead. I would try asking on the freeradius mailing list too. Be clear exactly what you're testing (e.g. show the config on the client) and include the full radiusd debug output, maybe also include packet dumps (full rather than just the 1-line summary you showed here). I don't think this is likely to be openbsd-specific.
incident.tgz
Description: Binary data
