Handling ARP reply when no more buffers, using Interniche and MCF52235

[Petter_fupp]

I use a variant of the Interniche TCP/IP stack in superloop mode. The following problem probably applies to other implementations as well.

This is my gdb output:

Program received signal SIGTRAP, Trace/breakpoint trap.dtrap () at ether.c:7676                      asm("halt");(gdb) backtrace#0  dtrap () at ether.c:76#1  0x000181b0 in arpReply (pkt=0x20004f6c) at net/mip/m_arp.c:300#2  0x0001844a in arprcv (pkt=0x20004f6c) at net/mip/m_arp.c:383#3  0x00018d44 in pktdemux () at net/mip/m_ipnet.c:253#4  0x0000a580 in ethernet_check () at ether.c:843#5  0x00008a72 in main_loop (loop=<value optimized out>) at router.c:762#6  0x00009494 in main () at router.c:773(gdb)

The dtrap() in arpReply() seems to be called because pk_alloc() fails to find an empty buffer. As I understand it, this can happen if I'm "busy" sending data to a few other IP's and suddenly receive an ARP request from somewhere else.

Does anyone have suggestions on how to handle this? Performing an assembly halt is not a good option.

[mccPaul]

Hi

You can reduce this problem enough for it to go away, by improving the receive ISR for the FEC.

I seem to remember that the RX ISR is pretty dumb and simply tries to pass any valid frame up the stack. You can improve matters by examining the frames and simply discard any that are not of importance.

I have modified the RX ISR so that I only bother with broadcast ARP matching my host IP address (ARP request), unicast ARP (reply), TCP, UDP addressed to me, or unicast ICMP request and reply frames. Anything else is just ignored.

The FEC sets a flag for broadcast frames,so you just need to test if the protocol is ARP to see if you are interested, all other broadcast frames are dumped. I then check if the request is for my host IP address.

For non-broadcast, check the protocol, and for ARP, TCP and UDP, check if the address matches your host address(es).

Although this adds cycles to the RX ISR, these are cycles that have to happen anyway, they are very minimal, and they will save a lot of buffers.

Paul.

[ericgregori]

This is a architectual issue with the stack,  that I have a fix for and will be available in the next release after some extensive testing.

As you stated,  the FEC ISR is very dumb,  and tends to use a lot of packet buffers for packets that the stack just throws out.

I have moved some of the initial filters from the stack into the FEC ISR.  It makes the code less modular, but more memory efficient.

[Petter_fupp]

This sounds like a great idea, Eric! I'm looking forward to the next release.

[Petter_fupp]

Thanks for a detailed and helpful reply, Paul. I really understand why you would like an svn server (or similar) for a code repository now.

The RX ISR is a bit stupid, and we might need to improve it (but we need to parse some UDP broadcast packets). For the moment, I have chosen to silently drop the ARP request if there are no more buffers. Then we need to hope the other end performs a (successful) retry later on.