How to set "Don't fragment" flag LWIP short TCP paquets

[JMarq.1]

Hello,

I am sending very short TCP paquets (600 bytes maximum) in a PC <=> MCU transfer scenario. I wish the software running on the PC to answer using an empty (len=0) TCP flag ACK packet as soon as it gets every TCP packet.

Using an STM32F207ZG and LWIP stack on STM32CubeIDE, TCP packets are sent correctly but PC software answers an ACK after 50ms approximately. This is too much.

Using an MCU from another brand with a TCP/IP stack different than LWIP, I can send paquets setting "Don't fragment" flag and the receiving software on the PC answers every packet with an ACK in less than 10us.

How can I send packets on LWIP forcing to be set "Don't fragment" flag?

[LCE]

Please post it here, when you find out what's going on.

Good hunting!

[Pavel A.]

Then maybe you need a better network sniffer than wireshark. Something professional ( = expensive) that sees more low level (very short packets, bad crc or preamble...)  Poke in the PHY with a scope and look for anomalies.

[Piranha]

It seems that the topic author has confused the IP fragmentation with TCP segments. As the TCP is a stream (not message) based protocol, it doesn't have a requirement for segment size to be related to the size of user provided data chunks. And there is no strictly defined behavior and timeouts to sending ACKs either. Even if you will find a pattern, which triggers a specific behavior on, for example, Windows PC, there is no guarantee that this holds true for MacOS, Linux or other systems. And there is no even guarantee that the same behavior holds true for the same system after some OS or driver update!

There once was a bug in the HAL driver for the PHY LAN8742

@LCE , why are you saying "once was"? For non-reworked drivers, which are still the only available ones for F1 and F2 series, it's still there, because ST doesn't care.

@Pavel A. , PHY and the physical layer in general has nothing to do with packet sizes and delays for a higher layers like TCP.

[Pavel A.]

> PHY and the physical layer in general has nothing to do with packet sizes

Hmm.... Things happen. Packet sizes translate to transmission times; the longer the time the more is the window for a glitch... or something like that.

[Piranha]

With such an approach the number and models of switches and even the wire length has to be "tested"... You mean the ST's broken bloatware freezing and corrupting and dropping frames? Yes, that is possible. Though typically such a behavior is more of an erratic type, but the reported behavior seems to be consistent. Most likely the "issue" is not a real issue, just the lack of understanding of TCP functionality.

@JMarq.1 , in English the "paquets" is spelled as "packets". 😉

[Pavel A.]

Sure, everything should be tested, and there are serious tools for this (from Chariot to automated logic analyzers, of course you know). No, I mean the external PHYs, their clocks, power supply schemes, shielding and so on.

[Piranha]

Such hardware issues result in dropped packets, which can be detected easily by a software test. Those test tools are necessary for those, who implement Ethernet hardware on ASIC or FPGA. No, I don't have or even know those tools, because I don't need those. Of course, I have a decent oscilloscope, but I haven't even used it as an aid in the development of Ethernet related code. While hardware issues are definitely possible, searching for some unlikely ones just because of a behavior of a clearly broken bloatware is just a waste of time.

Which means that absence of bugs can be reached only by this:

programs should be composed correctly, not just debugged into correctness

https://amturing.acm.org/award_winners/dijkstra_1053701.cfm

[waclawek.jan]

As Piranha said, there are no guarantees over network layers timing in PC, usually it's dealt with by handwaving ("fast enough"). Also an often overlooked fact is, that switches can impose delays, too - they are usually deemed as "oh it's just hardware", but it's not.

JW