Ping flood attack hangs NDK stack

Hi,

Is there any TI Enployee that could answer to this issue?

Regards,

Gilen

Gilen,

probably not... as it seems we don't have the code you are talking about. As far as I know Beaglebone is supported through our Linux and Android releases. There might be some 3P RTOS solutions too. But I am not aware about an official Sys/Bios 6 with NDK+driver package. Usually NDK release does not include the target driver.

What versions did you use and how did you create the CPSW driver?

Regards.

Dear Frank,

The versions I have used are:

SYS/BIOS 6.34.4.22

XDCTools 3.24.5.48

IPC 1.25.1.09

NDK 2.22.0.06

I have done a porting of the NSP 1.10.0.03 for omapl138 and adapted its drivers to the am335x.

I suspect that the problem is into the NDK implementation of code, because there are some other posts in this forum with the same issue and the effect of this type of crash when there is a high network traffic.

Thank you and regards,

Gilen

This maybe the case... but there is still a chance that the issue is due to differences in the MAC hardware or issues with the adaptation of the drivers. The drivers I have seen so far were not optimal in terms of error handling even in the TI released version.

Regards.

Hi Gilen,

I ran into a similar issue today. We are working on an IDK which uses the same chip as beaglebone(am335x).

Can you provide a few details on the issue you face? For example, in my case, I noted that the RX always fired(unlike the other posts which mentions TX is fired properly, but RX is not). However,  the static structure RxQueue and TxQueue are having the pHead value set to 0x00000000. This is what causes the NDK to hang(or in short never respond as the TX is never triggered). You can put a break point in the function HwPktTxNext and observe the Queues.

Let us know your observations.

Thanks,
Vinesh 

Hi Vinesh,

My application doesn't transmit any frame. In my case, the RxQueue overflow is not the reason of hang. This buffers are for application frames, but the ping frames that cause my board to hang are not passed to those buffers. The NDK stack is doing the ping frames processing and responds to them. The reason of hang has to be in the NDK itself.

I have been trying to configure my project to view into the C I/O console the messages of System_printf to debug the cause of hang, but I have not achieved. Could you see the C I/O console messages in your project?

Regards,

Gilen

Hi Gilen,

The standard printf messages can be seen on CCS console right? 

Are you sure the Ping frames are not passed to those buffers? Because in my case, these buffers(TxQueue) is used up EmacSend(later freed by TX ISR). I've also come across another issue wherein PBM_alloc returns null in RxPacket().

Either ways, the result in the end is NDK stops responding.

Regards,
Vinesh 

Hi Vinesh,

You can verify that by puting a breakpoint in GetPacket function (pPkt = Queue_pop(&RxQueue);), and sending a ping to your board IP. It doesn't break the execution of the application.

Regards,

Gilen

Hi Gilen and Vinesh,

I just wanted to update you guys.  We are able to reproduce this problem locally and are currently investigating the cause and how best to fix it.  We will respond to the forum as soon as we have some new info for you.  Thanks in advance for your patience.

Steve

Hi Gilen,

I agree about RxQueue, how about TxQueue? Try putting a breakpoint at csl_send_pkt = Queue_pop( &TxQueue ); in HwPktTxNext. You'd probably get a NULL value when the NDK hangs. Or now, more often I observe when NDK hangs, PBM_alloc in RxPacket returns NULL.

Steve, 

I wonder if these inputs would be helpful. Or let us know if you are stumbling on similar issues.

Thanks,
Vinesh 

Hi all,

My issue has been disappeared suddenly. My application has been growing and when I have done a new test of Ping Attack, the board doesn't hang and is robust to the attack. I suspect that the increasing size of the stack of each task in my application is responsible of this effect. I have changed the 512 bytes stacks to 1024 bytes with this code:

Task_Params_init(&taskParams);
taskParams.stackSize = 1024;

I have done some other changes in my source code, but do not think have connection with the resolution of the problem.

Could you try this and reply if it solves your issues...?

Thanks and regards,

Gilen

Gilen,

Which task's stack size have you increased? You application stack size? I'm not sure how that would resolve the issue. My application already has a stack size of 0x3000

Vinesh

Gilen,

It seems that the problem we reported with Flood ping was an issue with the CPSW subsystem configuration(in AM335x). The testing done on IDK is based on a single port(Port 1), but the Port 2 state was also set to “Forward”(this was done with reference to the Starterware Lwip implementation) . On digging in the forums, I found this post( http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/97467.aspx ) which reported a similar issue. Based on the information from this post, the unused ports state was left unset(by default Disabled). This fix seems to work for us and is under testing now, so far fping has not caused the NDK to hang.

Thanks,
Vinesh