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 13:30 schrieb Thompson, Jeff:
> There is also SharkTap, which I use.

Right. I also use that (the USB version) sometimes. It has the same
downside of stripping priority-only VLAN tags, though, which can be a
pain if you're debugging that. Also, if I remember correctly, I think it
breaks LLDP as it contains a switch, so it's not a real tap.

But for this issue, it should probably be good enough.

Regards,
Simon

>
> http://www.midbittech.com/index.html
>
> Jeff Thompson  |  Senior Electrical Engineer-Firmware
> +1 704 752 6513 x1394
> www.invue.com
> -----Original Message-----
> From: lwip-users <lwip-users-bounces+jeffthompson=invue.com@nongnu.org> On 
> Behalf Of goldsimon@gmx.de
> Sent: Friday, January 29, 2021 06:39
> To: Mailing list for lwIP users <lwip-users@nongnu.org>
> Cc: Dejan Spasovski <spasovski.dejan@gmail.com>
> 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
>
> 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
>>
>
>
> _______________________________________________
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> _______________________________________________
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>