Network bindings not working after network downtime

Hi guys,
I’m using OH for a few years now and while I’m migrating to OH 3.2 I was hoping that a bug which hits me @OH2.5.12 is fixed with OH3.2.0. However, it isn’t.
Platform: Debian 10 (OH2.5.12, 4GB RAM, J3060 CPU) as well as Debian 11 (OH3.2.0, 4GB RAM, VM on N6005 CPU). Java: Zulu11-64

Issue:
I’m having a few bindings which collect data from the network (openweathermap, avmfritz, tr064). Normally everything is running just fine. However, sometimes I have to restart my firewall (opnsense) which takes ~1min. Almost everytime (99%) the openweathermap stops working after that, sometimes also avmfritz, tr064. Note: Both systems OH2.5 and 3.2 are not directly connected to the firewall (OH->switch->firewall->avm router).

First thing on OH3.2 was trying to restart just the bindings (bundle:restart ), but that doesn’t help. Next thing I was starting the TRACE on the openweathermap binding, but you get no errors and the THING keeps saying ONLINE, even though the data is not getting updating anymore.

Using the TRACE logs and github I think I may found something (Github OpenWeatherMap binding)

Line 397 (I see in the OH logs): logger.trace(“OpenWeatherMap request: URL = ‘{}’”, uglifyApikey(url));
Line 404 (not in the OH logs): logger.trace(“OpenWeatherMap response: status = {}, content = ‘{}’”, httpStatus, content);
Conclusion: The binding hangs between line 398 and line 403, which is probably the request itself (ContentResponse contentResponse = httpClient.newRequest(url).method(GET).timeout(10, TimeUnit.SECONDS).send();.)

Knowing that I found a way to get the bindings back to work without having to restart the openhab service. Solution:

Bundle:restart org.openhab.core.io.net

I suppose this resets the network connections and theirfore all the bindings using this bundle are working again (reason why I thing this is not a openweather issue).

Note: If I restart the switch I don’t see this issue (maybe because the OS then notices that the network is down).

Now the best thing of course is not having to restart the OH service nor the core-bundle everytime I need to restart the firewall. Does anyway have noticed the same issue or is interested in finding this bug (?).

Thank you,
Timo