[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 14:02:37 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 |
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
>