Hi, first, there was a bug in pbuf_copy(), I don't know if your CVS snapshot is new enough, please check for changes on pbuf.c in CVS. But is not what your problem is now, only to make sure you don't run into it later.
What I'm surprised about is the following line of debug output when receiving the ping: >>> pbuf_header: failed as 0x270162 < 0x270164 (not enough space for new header size) <<< Here, the icmp code tries to move the payload pointer from the start of the icmp header to the start of the ethernet header. It does that using 2 header-length defines: PBUF_IP_HLEN for the IP header and PBUF_LINK_HLEN for the ethernet header. Since pbuf_header() failes because the pbuf is 2 bytes too small, this looks like, on receive, you have 14 bytes in your RX-pbuf for the ethernet-header (which is normal if alignment of IP-header is not needed) while PBUF_LINK_HLEN is set to 16 (to achieve IP-header and -data alignment to 4 byte). That would be a configuration fault! If PBUF_LINK_HLEN is set to 16 instead of 14, ETH_PAD_SIZE must be set to 2 (see ethernetif.c for an example of achieving alignment). Otherwise, try to set PBUF_LINK_HLEN to 14 (also the default in opt.h) and PBUF_LINK_HLEN to 0. This might solve your problem. If PBUF_LINK_HLEN is set to 16 and ETH_PAD_SIZE already is set to 2: see ethernetif.c on how to create an RX-pbuf compatible to that alignment. In your case, etharp_output might have the same problem with pbuf_header (like icmp_input) and thus, ip_output_if might return ERR_BUF instead of sending the packet. I've checked in some more debug code for icmp.c to check that. Of course, I might be completely wrong and your problem is somewhere else... Simon
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
