-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Socket error on client <unknown>, disconnecting. ARMv7 subscriber only #1385
Comments
You never send a subscribe. I'd check the way you are trying to handle the "has the subscriber been initialized yet?" |
I do, it is only hidden in a If statement. and i know that this method works because i got subscribtion messages when i subscribe with my i686 device.
|
Can I check, if you're building from source I presume you're on version 1.6.4? Is that correct? |
that is correct |
Yes, I wouldn't expect a subscrube request in wireshark as it's not shown int eh broker logs either. Are you sure you actually make the subscribe call? Add an else clause so you get a print regardless? |
As far as i can see it does resolve the subscribe function succesfully. It return the client <unknown> error is given at |
Does the |
It does send a subscribe according to the on_log. |
I have tried to build it on another build environment with another toolchain and also updated the linux version on de ARMv7 target. It still gives the same error. |
The example code you provide is incomplete, is it possible to have a full working example that shows the problem? |
yes, i tried it this time to build on a yocto ubuntu 18.04. and with updated system libraries on my device. unfortunatly the problem still persist. I use a custom build linux OS which is higly based on debian wheezy. it uses kernel 3.10 which gave some trouble, but i created a workaround for that. i use that workaround on both devices, and it works on both. I will provide a working copy later today |
I debuged the library and encountered an problem. In my case on the ARMv7 chip the library runs into a race condition where it internaly returns //loop.c
int mosquitto_loop_forever(struct mosquitto *mosq, int timeout, int max_packets)
{
usleep(400);
int run = 1;
int rc;
unsigned int reconnects = 0;
unsigned long reconnect_delay;
... It is an ugly solution but for now it helps. It may be good to check if the reconnect function does work when the first connection is not performed well. EDIT |
Good find! Are you able to check with the latest |
I tried the fixes branch, but it doesn't resolve the problem. |
I haven't been able to reproduce this, but I think I can tell where the most likely cause for this is. I've just pushed a commit which may fix it. |
This is a regression for me on both desktop linux (glibc, x86_64) and openwrt (musl-libc, mips32/ath79) I use connect_async() followed by loop_start, and I simply never receive my on_connect callback. I'm using libevent2 for my own portion of the application, and if I send a signal that I'm handling via libevent2 (ctrl-c to cleanly exit) I finally see the connect callback firing before immediately my clean exit handler disconnecting and exiting. |
test case for connect_async available at etactica@f7e04bf |
There's an updated fix in the |
Currently I'm working on a project where i need to use MQTT on an ARMv7 and i686 device. The current problem is that specificly on the ARMv7 device some problems arise.
i am running on both of the devices Debian 7 Wheezy.
When i try to connect the ARMv7 device to the broker it seems to connect but doesn't receive anything at all. The broker returns the following
The I686 devices show the following notice
after little research i noticed that the broker does not forward anything to the ARMv7 device. i don't know it this is a bug of something else.
Both devices use the same codebase, but are built with seperate compilers.
Thanks in advance.
Nick
The text was updated successfully, but these errors were encountered: