lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Possible bug in src/api/tcpip.c


From: Rishi Khan
Subject: [lwip-users] Possible bug in src/api/tcpip.c
Date: Thu, 1 May 2008 11:20:43 -0400

I'm using the unix port to try to get some ideas as to the performance of the lwIP stack. I think I have found a bug when the NETIF_FLAG_ETHARP is set. Typically tcpip_input expects to see a TCP/ IP packet with the ethernet header already stripped. It sends this to a MBOX which gets processed by tcpip_thread. In tcpip_thread, there is code that says:

    case TCPIP_MSG_INPKT:
LWIP_DEBUGF(TCPIP_DEBUG, ("tcpip_thread: PACKET %p\n", (void *) msg));
#if LWIP_ARP
      if (msg->msg.inp.netif->flags & NETIF_FLAG_ETHARP) {
        ethernet_input(msg->msg.inp.p, msg->msg.inp.netif);
      } else
#endif /* LWIP_ARP */
      {ip_input(msg->msg.inp.p, msg->msg.inp.netif);
      }
       memp_free(MEMP_TCPIP_MSG_INPKT, msg);
      break;

So, ip_input processes this as if there is no ethernet header, as it should. But, if NETIF_FLAG_ETHARP is set, it sends it to ethernet_input, which attempts to read the ethernet header and process it. However, there is no ethernet header at this point.

So, one of two things should happen to fix this bug:
The above code should be changed to roll back 'p' to the ethernet header like this:
#if LWIP_ARP
      if (msg->msg.inp.netif->flags & NETIF_FLAG_ETHARP) {
        pbuf_header(msg->msg.inp.p, 14);
        ethernet_input(msg->msg.inp.p, msg->msg.inp.netif);
      } else
#endif /* LWIP_ARP */

OR:
The tcpip_thread does not handle ARP packets and this is handled in the ethernet device when processing the raw packet coming in.

The tapif interface does the latter, but it has NETIF_FLAG_ETHARP == 0;

My vote would be to yank the ARP checking out of tcpip.c and let the ethernet device handle that.

        Rishi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]