lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [bug #59966] After several hours of working, need router re


From: Dejan
Subject: [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 04:56:57 -0500 (EST)
User-agent: Mozilla/5.0 (Linux; Android 10; SM-A515F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Mobile Safari/537.36

URL:
  <https://savannah.nongnu.org/bugs/?59966>

                 Summary: After several hours of working, need router reset to
be able to send mqtt msg bigger than 1460 bytes
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: dejandigitex
            Submitted on: Fri 29 Jan 2021 09:56:54 AM UTC
                Category: None
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: 2.1.0

    _______________________________________________________

Details:

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.




    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?59966>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

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