It's eapol_test with eap tls, however basic set-up too implemented and
it works well.
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
> 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.
In this recorded test - yes client sends traffic directly to server via
cisco sg350 switch both connected to ethernet.
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 set
> Is 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.
No comments:
Post a Comment