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
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users