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

[address@hidden]

Am 29.01.2021 um 12:26 schrieb Dejan Spasovski:
> From: *Dejan Spasovski* <spasovski.dejan@gmail.com
> <mailto:spasovski.dejan@gmail.com>>
> Date: Fri, Jan 29, 2021 at 12:23 PM
> Subject: Re: [lwip-devel] [bug #59966] After several hours of working,
> need router reset to be able to send mqtt msg bigger than 1460 bytes
> To: <goldsimon@gmx.de <mailto:goldsimon@gmx.de>>
>
>
> Many thanks for the reply,
>
> Can you tell me please how to setup wireshark between a hardware device
> and router, do I need a switch working in promiscuous mode?
>
> I have microtik router in hand I am checking to see if it has this
> mode... in between any other ideas?

I guess what you're looking for is a "mirror port" on a swich?

You might want to invest in a TAP if you do this more often. A mirror
port on a switch is not that ideal as it migth get the timing wrong (or
even migth drop packets, you never know).

So, either by an expensive TAP (e.g. search for ProfiTAP), a cheap TAP (
tested one for ~150 EUR and it worked quite nice, although it strips
VLAN tags) or build one yourself (with the downside that you need 2
network cards to monitor, one for TX and one for RX) like here:
https://www.securityforrealpeople.com/2014/09/how-to-build-10-network-tap.html
(only works for 100 mbit/s, not for gigabit).

The cheapest solution might be to create a software bridge using a
windows or Linux PC (just google it) and then using wireshark on the
bridge netif.

Regards,
Simon

>
> Dejan Spasovski
>
>
> Senior Embedded Software & Electronics Systems Design Engineer, 
>
> CEO at eXtremeEmbedded,
>
> https://www.xembed.com <https://www.xembed.com>
>
> phone: +389 75 215 449
>
> st. Mariovska 3, 20-1/8
> Skopje, Republic of North Macedonia
>
>    
>
> On Fri, Jan 29, 2021, 11:09 goldsimon@gmx.de <mailto:goldsimon@gmx.de>
> <goldsimon@gmx.de <mailto:goldsimon@gmx.de>> wrote:
>
>     [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
>