Panic when connecting to enterprise wifi

[m-dahl]

Bug description

Hi, sorry for the lack of details I had to work around the issue as it arose in production. Since then I have not been able to test more. But I captured the following backtrace and I think it could be interesting for you:

panicked at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/esp-wifi-0.10.1/src/compat/misc.rs:163:45:
called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }

Backtrace:

0x42031e5a
0x42031e5a - core::result::Result<T,E>::unwrap
    at ~/.rustup/toolchains/nightly-2024-08-06-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/result.rs:1102
0x4206c5c2
0x4206c5c2 - eap_mschapv2_failure_txt
    at /COMPONENT_WPA_SUPPLICANT_DIR/src/eap_peer/eap_mschapv2.c:382

To Reproduce

Not familiar with how the authentication protocol works but what happened is that my credentials needed a new password (password needs to be rotated every n months) and this caused a panic in esp-wifi. I assume this is communicated back during handshaking with the client and this path is not handled properly. With an updated password the panic went away.

Try to connect to enterprise wifi with expired authentication details

Didn't try on main but was running 0.21.0 which is recent.

Environment

• Target device: esp32c3
• Crate name and version: 0.21.0

[bjoernQ]

Thanks for reporting this. I will try to reproduce and fix this as soon as possible

[bjoernQ]

I wasn't able to reproduce the crash - I assume it depends on the radius server used (I'm using FreeRadius) when trying to parse a negative response from the server

However, the backtrace was useful to spot a problematic / too optimistic implementation of atoi