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

[Rishi Khan]

Ok. Maybe the tapif.c should be updated in ports/unix/netif because  
that's where I got the hairbrained idea to remove the ethernet header.

        -rishi

P.S. I've written a unix driver that actually binds to eth0 (or other  
device) and operates there. This allows you to test inter-computer  
communication in unix (tap/tun seem to only work on the machine  
running the program and no other machine can access this). Is this  
something that is useful to the community?

On May 1, 2008, at 2:08 PM, address@hidden wrote:

> Rishi Khan wrote:
> > 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.
> Just for better understanding, the handling of ARP packets has  
> changed in 1.3.0:
> Previously they were indeed handled by the 'ethernetif' code. The  
> problem was that this way, the ARP table wasn't protected against  
> concurrent access (from receive thread an tcpip_thread - when  
> sending). This was solved by letting the tcpip_thread handle ARP  
> packets, which is the reason why ethernet netifs have to pass the  
> complete packet, not only the IP part.
>
> Simon
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users