Summary
On a live STM32H7 network, all received frames are classified as IGMP protocol (protocol byte = 2) in the IP receive path. The counter shows 6600+ IGMP frames and 0 UDP frames over 10 seconds, despite UDP test packets being confirmed on the wire via tcpdump.
Impact
- No UDP datagrams are ever delivered to the application
- The IP demux appears to always match protocol = 2 (IGMP) regardless of the actual IP protocol byte
- Debugging suggests the IP header
protocol field might not be read correctly during the flip/demux process
Location
source/hypha_ip.c — IP protocol demux after the flip operation
Investigation Notes
- MAC register shows
RA=1, PM=1 (promiscuous + receive-all), so the MAC is not filtering
- DMA is running, no missed frames
- PHY link is up
- Test UDP packets confirmed on the wire via tcpdump
- All 6600+ received frames count as IGMP per
HyphaIpStatistics_t.counter.igmp
- Underlying frames may actually be ICMPv6 (Router Solicitation, Neighbor Discovery) or IGMP queries, not actual IGMP
Suspected Root Cause
Possible IP header field misalignment in the flip table or the protocol byte extraction at the IPv4 demux in hypha_ip.c.
Summary
On a live STM32H7 network, all received frames are classified as IGMP protocol (protocol byte = 2) in the IP receive path. The counter shows 6600+ IGMP frames and 0 UDP frames over 10 seconds, despite UDP test packets being confirmed on the wire via tcpdump.
Impact
protocolfield might not be read correctly during the flip/demux processLocation
source/hypha_ip.c— IP protocol demux after the flip operationInvestigation Notes
RA=1, PM=1(promiscuous + receive-all), so the MAC is not filteringHyphaIpStatistics_t.counter.igmpSuspected Root Cause
Possible IP header field misalignment in the flip table or the protocol byte extraction at the IPv4 demux in
hypha_ip.c.