esp8266 client not connecting on local broker (re-open) about umqttbroker HOT 2 CLOSED

hi,
having spent some hours convincing my setup to get all debug-logs out of lwip, I conclude that the problem is (not totally surprising) the missing 'loopback' support of the lwip stack. Strangely there seems to be some code inside lwip to support loopback devices (which is deactivated by #defines), but even if activated in the lwip code, the netif for 'lo' is not registered by default.
Calling the respective routine (netif_init()) ultimately results in crashes. So I suspect that the code is either incomplete, broken otherwise or I just used it wrongly.
I didn't check lwip2, as there's the 5 connection limit - a show stopper for me.

I have no clue, why it works on my Fritzbox featured WiFi. I found a dependency to mDNS. If this is not used in my esp-code, it even doesn't work on this Fritzbox WiFi. With my limited understanding, I guess (which my be totally wrong) that the mDNS/Service register broadcasts trigger some magic in my router, which helps my esp8266 finding itself on the network.

So I give up for now, move to another client (with full TLS support) and need to setup a separate broker - experimenting with a public now (myqtthub).

I'd be happy to support here to make it work - however, this may need some profound understanding of the inner workings of IP (lwip). Another solution could be to have 'bypass' lwip in the uMQTT client directly into the local uMQTT broker, if a loopback scenario is somehow detected. This could be a rather slim change by 'just' calling some callbacks, expected to be called from the IP stack? @martin-ger, what do you think?

Anyway, I appreciate all the work here very much. Thanks to @martin-ger and the community. Let me know if I can help to test/debug or even contribute...
pottendo

from umqttbroker.

hi again,
I've revisited the uMQTTBroker examples and found the direct API calls of the broker to subscribe/publish.
So my suggestion from above to have a 'shortcut' is already there - not in the shipped mqtt-client but still fine for my use case.

Now my architecture works as expected - even more stable, as it seems, compared to the usage of the mqtt client; but this needs to be confirmed; I have some tests running now.
Spending the time to investigate the (finally non-)problem was not useless for me. Learned alot about the arduino platform, platform IO and mqtt.

bye, pottendo

from umqttbroker.