No radsecproxy in this production setup, tested with 2 APs (Aruba 305 and Mist) establishing a connection directly to the server. When debugging this, we did run tests with eapol_test going through radsecproxy to the upgraded server running locally, and strangely this succeeded. I have switched the OS to the latest version of Ubuntu and this seems to work. The code is in version control and could craft a reproducible test case. On Thu, 16 Sep 2021 at 00:17, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 15, 2021, at 7:32 AM, Emile Swarts <emile.swarts123@gmail.com> wrote:
Had a look at that C code, but understanding why it's not doing the right thing is a bit beyond me I'm afraid.
Looking at the C code won't help. The issue is inside of OpenSSL, and how we're using their (rather opaque) API.
I have a packet capture from the server as well:
Hmm... that's not really a packet capture. It's a CSV file with IP addresses as double quoted strings. :(
In order to track this down, it will be necessary to look into the TLS protocol internals. Looking at a high level of "IP 1 sent packet to IP 2" doesn't give enough information to find out what's going wrong.
Which version of radsecproxy are you using?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html