I don't quite get it. The problem is that ethernet_input requires the
ethernet header and ip_input requires the header NOT to be there. If
you call pbuf_header and NETIF_FLAG_ETHARP==1, then the TCP/IP will
fail. You have to NOT call pbuf_header. So, if you call
NETIF_FLAG_ETHARP, they you should leave the header alone, but if you
don't call NETIF_FLAG_ETHARP, you should leave it there. Doesn't that
seem weird? Why should the TCP/IP stack handle ARP? This is
inherently an ethernet problem.
On net_if_setup, if NETIF_FLAG_ETHARP is set, it calls etharp_query
to tell all of the other nodes to update their table. If you want
this behavior, you need to have NETIF_FLAG_ETHARP on.
Anyways, the documentation for tcpip_input clearly states that it is
pointing to the ethernet header or the ip header depending on
NETIF_FLAG_ETHARP, so I guess it's ok. ... just a learning curve.
So, I will update my netif to NOT mess with the ethernet header and
just forward this on.
Thoughts?
-rishi
On May 1, 2008, at 11:46 AM, Frédéric BERNON wrote:
To my point of view, the problem is the driver you use: if your
netif got NETIF_FLAG_ETHARP=1, you have to call pbuf_header on your
pbuf before post if with tcpip_input.
----- Original Message ----- From: "Rishi Khan"
<[EMAIL PROTECTED]>
To: "Mailing list for lwIP users" <[email protected]>
Sent: Thursday, May 01, 2008 5:20 PM
Subject: [lwip-users] Possible bug in src/api/tcpip.c
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
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
