I see what must be broadcasts (well, whatever gets routed through a switch) roughly every 1-2 seconds.
Inevitably, some of these will end up in the ETH RX buffer list at the same time as a real data packet.
This is OK if there are 3+ RX buffers (each buffer is MTU-size btw) but it was the 2 buffer case which was comprehensively breaking stuff.
I'd like to understand the mechanism for this problem, because those RX buffers are at the PHY level. They all rank equally until they reach LWIP. So two data packets (addressed to the same IP) should have the same effect as 1 data packet and 1 multicast. Is this wrong?
Also I noticed that when I opened up a VPN to another site, more multicast packets appeared - as one would probably expect.
The issue of
high speed multicasts making a device grind to a halt, I am happy with. It's not possible to guard against this completely while achieving a decent speed - because even an RX ISR will need to implement a rate limit otherwise a stream of multicasts will totally hang up the box. I don't need
dare to come back with some sourcecode because the 32F4 can dump broadcasts internally (but that breaks things totally - see below).
The Q is then: is there a legitimate scenario where we do want broadcasts to reach LWIP? There is a lot online about this. This
https://stackoverflow.com/questions/35130743/how-to-create-a-service-that-sends-receives-udp-broadcasts-on-multiple-interfacesuggests that LWIP passes broadcasts back to every open socket.
This suggests that some ST CPUs have a broadcast filter already
https://stackoverflow.com/questions/50132454/stm32-lwip-mcu-load-due-to-broadcast-packetThis seems quite similar to my problem but he fixed it without ever finding out how - could just be a different # of rx buffers (the H7 has/had loads of ETH issues)
https://stackoverflow.com/questions/72323318/lwip-netconn-recv-netbuf-overwritten-from-browser-broadcast-messageBased on this
https://community.st.com/s/question/0D50X0000ALu7XqSQJ/how-configure-lwip-to-receive-udp-broadcast-using-stm32cubemx-I've done this, in case it helps to dump broadcasts earlier
// Disable broadcasts being received
#define IP_SOF_BROADCAST 1
#define IP_SOF_BROADCAST_RECV 1
Everything still works, and indeed I don't have any LWIP application receiving broadcasts.
I cannot find anything re LWIP
itself needing broadcasts for anything.
As usual we've done this before
https://www.eevblog.com/forum/microcontrollers/any-micros-with-eth-and-hardware-incoming-packet-filtering-by-ip/which led me to BFD of ETH_MACFFR:
Bit 5 BFD: Broadcast frames disable
When this bit is set, the address filters filter all incoming broadcast frames.
When this bit is reset, the address filters pass all received broadcast frames.and I disabled broadcasts using using ETH_BROADCASTFRAMESRECEPTION_DISABLE in stm32f4xx_hal_eth.c.
That breaks things completely. Evidently the 32F4 ETH
does need to process broadcasts (for network config?) but LWIP is happy to dump them.
So if I was to dump them, they would need to be dumped at the level above the 32F4's ETH controller i.e. in low_level_input, but since that is above the ETH PHY buffers discussed, what would be the point? The real gain of dumping them at the ETH level would be a high level of DOS protection.