david-cermak

@michaelgaehwiler Thanks for the feedback. Yes, I think the user-event would be provided before implementing separate locking.

Yes, the event is posted after locking the client, but that should not prevent from calling other client's API. Same as the default example publishes in the event handler: https://github.com/espressif/esp-idf/blob/release/v4.4/examples/protocols/mqtt/ssl/main/app_main.c#L86...

> will there be any negative consequences from these setting for people that do not use code that requires them? Yes, negative effect on WiFi throughput. And yes, mainly the...

@egnor @ESP-YJM Thanks for taking the time and effort in posting the changes and reviewing. There were indeed few issues with the mqtt client, but the changes are very much...

This is a known limitation in IDF/lwip (also documented in: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/lwip.html#adapted-apis) This will be handled on `esp_netif` layer in https://github.com/espressif/esp-idf/issues/6270 (closing this one as a duplicated issue)

Hi @not-my-real-name Thanks for the detailed analysis and proposing a solution. I took a quick look and your patch looks okay to me, would you mind posting it as a...

Thanks for the reply and checking the PR process. I would probably then apply similar changes to the lasted `mdns`. I think the while loop in the Tx packet processing...

Update: * the transmit problem has been addressed and fixed in https://github.com/espressif/esp-protocols/pull/533 * the allocation caps of mdns packets is still open and will be covered in this issue

Hi @kanjiviroja1991 If I understand the problem correctly, you're correctly getting the LL address after the IP6CP negotiation, but are not able to access internet, as that address is not...

Thanks for sharing the log, looks like the same issue on my end, also seeing this weird packet on PPP netif: ``` [2024-06-03 12:38:54.148] ip6_input: packet accepted on interface pp...