I’m seeing this:
name state prio stack num
Green LED X 1 272 1
Yellow LED R 1 100 2
Red LED R 1 100 3
IDLE R 0 104 6
EMAC_STM32 B 6 272 7
IP-task B 5 2274 5
TCP Debug Liste B 1 551 4
(The “LED” tasks are simple blinkys with varying delays. The task list is obtained and printed as part of the “green LED” task.)
So I’m not seeing anything unexpected here. The IP-task is running at the highest priority except for the EMAC, and it is waiting on something, for many seconds. And during that time, it is ignoring SYN packets. But it will, for example, respond to an unlimited number of pings (ICMP) with practically zero latency (I see about 0.2 ms) and no dropped packets.
It does seem that other activity on the network “modulates” the deafness of the stack to TCP SYN packets. For example, if I run pings and then try to connect, it typically takes longer to SYN ACK, and the connection often times out completely. When trying to connect without pings running, it usually takes between 30-60 seconds.
Is there some way to turn up the debugging verbosity so I can see incoming packets traversing the various processing stages inside the stack?