Hello,
could you please help me to understand the Keil Ethernet/E-MAC Driver? I have several tasks running and started a DOS attack via TCP to test my ethernet application. The result was not what i expected.
My setup:
- STM32F439 - ARM Cmsis 5.0 - Middleware 7.3 - DFP 2.11 - Keil Ipv4/Ipv6 Core - ETH Interface and TCP sockets.
My application:
- 4 TCP sockets in listening mode - 1 main Task with priority normal - netCore Thread with priority above normal - netETH Thread with priority below normal. (I set it by myself on below normal)
I started a DOS attack with TCP fragments and UDP packets on my application. The software is LOIC. I expected that my application stops running in the main task because of the amount of packets. I tought the software will spent all the time in ETH_IRQHandler or in the netCore Thread with priority above normal.
I have a lot of ETH_IRQHandler calls but my application does not spend a lot of time in the IRQ handler or in one of the Ethernet Tasks. Why are there approxemately 0,2 ms between two calls of the ETH_IRQHandler? With main task = normal priority and netETH Thread = below normal priority my application still has enought time to work regular in the main task.
That is not the behaviour i expected. The PHY is a DP83848i with MII Interface.
Thank you
Hello Franc,
thank you for the reply.
I know that the ETH_IRQHandler just generates signals for other tasks but i expected much more ETH_IRQHandler calls. A call of the ETH_IRQHandler every approxemately 0,2 ms is extremely rarely for a DOS attack in my opinion.
Do you know why?
Check how fast the packets are delivered to your device. Might be that your router is stalling them. Anyway if your device is behaving properly, then do not worry. This is a way how the system defends itself against DoS attacks.
I guess the IRQ isn't armed again until after the thread have had time to read out data?
Better "real" network cards are using coalese just to make sure that there will not be one interrupt per received packet - so the card might be configured to produce one interrupt per 10 or 100 packets or after x us from the reception of the oldest pending packet. Having one interrupt per packet isn't anything to strive for if the hardware can buffer more than one received packet.