lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] [lwip-devel] [bug #59966] After several hours of workin


From: address@hidden
Subject: Re: [lwip-users] [lwip-devel] [bug #59966] After several hours of working, need router reset to be able to send mqtt msg bigger than 1460 bytes
Date: Fri, 29 Jan 2021 11:08:53 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

[Moved here from an invalid bug report]

Am 29.01.2021 um 10:56 schrieb Dejan:
> [..]
> Hi,
>
> We are company producing seismic sensors based on STM32H7 mcu's running lwip
> and we use mqtt to connect to our own cloud server. On starrup devices send a
> series of short messages and then after this usual handshake with the server
> they start streaming bigger packets of sensor data on a specific mqtt topic.
> The message size is usually from 4KB up to 32 KB sent each second. Everything
> seems to work fine until after several hours (usually 12 to 24 hrs), we find
> that we need to restart the main router, otherwise the streaming of mentioned
> packets will be blocked from the router to the server. However the device is
> still able to send tcp mqtt packets that fit in one TCP frame. Once the TCP
> message is to be fragmented in more than one frame (is bigger than 1460 buyes)
> the router will not let it through untill we reset it and we get another day
> of a working device.
>
> This behaviour is our several months nightmare and we cannot wrap our heads
> arroud it...
>
> If any of you experts have an idea what could be the problem please reply.
>
> We tried:
> New server/ broker, different port numbers, different MCU series.
>
> Can it be that our low level protocol for TCP is doing something wrong so the
> router remembers this device mac address and wont let it send fragmented
> msgs?
>
> The last thing we tried is to change the MAC address of the device during the
> blockage mode and then communication went through until several hours later to
> fall in the same state.
>
> Please throw any ideas you have in mind we need to deliver this product soon
> but its obviously no good as it is.

Have you tried monitoring the connection between your device and the
router using wireshark? That should be the first thing to do, so you
know what actually happens. Without that, you're practically sitting in
the dark, doing blind accusations ;-)

Regards,
Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]