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