can subscribe topic, receive publish from ext, but external can not connect/subscribe about umqttbroker HOT 15 CLOSED

Did yu use the setting "lwip Variant: 1.4 High Bandwidth" in the "Tools" menu?

If not, this causes the the uMQTT-Broker to hang...

from umqttbroker.

Yes.
By the way my app runs also a web server, so I can see it is running.
If I send messages from PC, broker keeps receiving them in onData, so half of it is perfectly working.
Max Heap: 34896 so there is memory.

from umqttbroker.

With logg() I write the log to a file and I can see it with http://192.168.1.20/l

[2020-05-21 21:30.06] G 24<az
192.168.1.3
[2020-05-21 21:30.06] G 24<az
hub-cmd-verde:anotherTest

I tried to look at the sources but it looks a bit complicated... but if you tell me something that I can try I will try...

from umqttbroker.

Does the uMQTTBrokerSampleFullOO work for you?
For me it does - Publishing and subscribing the same topic with the mosquitto clients (from the same Linux host) just do what they are supposed to do...

from umqttbroker.

hummmm I will search for another ESP to burn with the example.......

from umqttbroker.

Sorry. Identical behavior. New ESP with your example is on 192.168.1.19.
It correctly receives publish from PC/mosquito (same as above "anotherTest3" instead of STATE)
e:\programmi\mosquitto>mosquitto_pub -h 192.168.1.19 -i ciccio -t hub-cmd-verde
-m anotherTest3

If I attempt to subscribe with mosquito, same topic, nothing, timeout.
E:\programmi\mosquitto>mosquitto_sub -h 192.168.1.19 -t hub-out-verde
Also external device on .7 can not connect, says error -4 (timeout); as before (I forgot to say) I see some 192.168.1.7 connected
(device is attempting to reconnect; but always says timeout and not connected; that device works if I run it with the mosquito broker on PC; by the way now the broker on PC is not running)

.........
WiFi connected
IP address: 192.168.1.19
Starting MQTT broker
received topic 'broker/counter' with data '0'
received topic 'broker/counter' with data '1'
received topic 'broker/counter' with data '2'
received topic 'broker/counter' with data '3'
received topic 'broker/counter' with data '4'
192.168.1.3 connected
Username/Password: /
received topic 'hub-cmd-verde' with data 'anotherTest3'
received topic 'broker/counter' with data '5'
received topic 'broker/counter' with data '6'
192.168.1.3 connected
Username/Password: /
received topic 'hub-cmd-verde' with data 'anotherTest3'
received topic 'broker/counter' with data '7'
received topic 'broker/counter' with data '8'
received topic 'broker/counter' with data '9'
received topic 'broker/counter' with data '10'

from umqttbroker.

I tried to compile with:
v.1.4 higher bandw (as suggested - this was the one in the examples above
v.2 lower memory (identical behavior with .19
v.2 higher band (identical behavior with .19

from umqttbroker.

Sorry, I cannot reproduce the error. Just double checked it (updated to the latest ESP Arduino 2.7.1). I just works for me...

Any chance to get a wireshark trace of the connection?

from umqttbroker.

OK. One problem appears solved. PrivateFirewall on PC was blocking mosquitto_sub (but yesterday it worked... what the &&%%£$$ !!!! ).
But the device on 192.168.1.7 is a ESP so it has no firewalls........
I am using PubSubClient on that ESP, and it works correctly as MQTT client (publish/subscribe) when using mosquitto broker.......... and now it doesn't. Will investigate further...

from umqttbroker.

how can I know the ESP version installed such as 2.7.1 I just don't remember?
Also I am sorry for not having seen the firewall but with 2 devices not working I did not double check, maybe this topic will be useful for other dumb people like me.
I am still on the fog as for the other device...

from umqttbroker.

I looked in board manager in the board settings. There you can see the installed versions and possible updates.

from umqttbroker.

OK, I made it working also the second thing but...... I have found a bug for you, and this time it could be really on your side :-)
The first thing that I noticed is that when I subscribed (OK) with Mosquito on x.x.x.3 (the PC) the test application was printing
192.168.1.3 connected
Username/Password: /
Instead, for the automatic attempts of x.x.x.7 (the mysterious ESP using the PubSubClient library) it wrote:
192.168.1.7 connected
and stop here; this while the ESP x.x.x.7 said timeout, cant'connect.
As now I don't check the pass, well why not to add a fake user/pass in the ESP, just to test.
Now it prints:
192.168.1.7 connected
Username/Password: abc/aaaa
and after this it is really connected, and works.....!!!
By the way the mysterious ESP is my new DoorOpen (sorry it is still only in Italian http://www.soluzionisemplici.com/serratura_elettronica_airbnb_booking.htm ) now that I discovered that it is not its own fault I can say it :-)

I guess that at present your library somewhat REQUIRES who is connecting to send user/pass, even if they are empty, otherwise it drops the connection (or something like this...).
Probably mosquito_sub sends user/pass even if they are empty, bypassing this thing, while the ESP library PubSubClient is apparently NOT sending them if they are empty.
Probably this is a correct choice in order to save bytes, and should be legal as the Mosquito Broker is able to work in both cases.

Yes I've checked PubSubClient (it's just one file so smaller than your code!) if no pass or user it does not write them, and also puts some flag for this
if(user != NULL) {
v = v|0x80;
if(pass != NULL) {
v = v|(0x80>>1);
}
}
by the way for quickness and peace of mind I am working with Strings and so without user/pass I had (say) user="" and pass="" and I am passing user.c_str() and pass.c_str() to PubSubClient
Ok it's
if (client.connect(clientId.c_str(),mqtt_user.c_str(),mqtt_pass.c_str()))
All the rest is like basic PubSubClient examples.
I never checked if actually with user="" then user.c_str() is NULL but I guess so.

from umqttbroker.

OOOK I have it: when you call the "connect" procedure of PubSubClient passing a .c_str() like this

client.connect(clientId.c_str(),mqtt_user.c_str(),mqtt_pass.c_str()))

even if the String is "", it appears that you are NOT passing NULL, so PubSubClient sets
MQTT_CONNECT_FLAG_USERNAME
MQTT_CONNECT_FLAG_PASSWORD
active...
but then... it passes you strings with 0 LEN (or maybe 1 as it would be just a \0 I suppose)
Your code at present in this case disconnects:
MQTT_server_disconnectClientCon(clientcon);

because it finds "an error".

If I make sure to pass NULL NULL if user/pass empty, everything runs fine.
So I don't know if you want to make a less strict check but at least now you know.
Maybe this could just be listed in a topic with better title - this could save some hours of attempts to people that will have my same problem.

from umqttbroker.

workaround for PubSubClient users that love to use Strings to store their parameters

    const char* user=NULL;
    const char* pass=NULL;
    if ((mqtt_user!="") && (mqtt_pass!="")) {
      user=mqtt_user.c_str();
      pass=mqtt_pass.c_str();
    }
    if (client.connect(clientId.c_str(),user,pass)) {
....

from umqttbroker.

basically the problem that gives the title to this issue was solved (it was a firewall) so I believe we can mark it CLOSED.
Other people with same problem with easily find the solution looking at this (possibly) last post.
For the other problem I opened #43 to help you keeping things more in order!
Thank you again for your great library!

from umqttbroker.