Re: [lwip-users] UDP packet sending problem

[Kieran Mansley]

On Mon, 2009-06-29 at 15:41 +0200, patrick Deflandre wrote:
> 
> 
> 2009/6/29 Yoshiki Komatsudaira <address@hidden>
>         I don't think the UDP checksum is invalid.
>         It maybe come from "Checksum offloading".
>         http://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html
>         
> 
> I think this is the most likely explanation of the checksum error
> reported by wireshark.

I'm not convinced: the TCP packets in your other capture show the
correct checksum, and you would expect them to have the wrong checksum
if checksum offloading was happening.  On the other hand, the checksum
in the text debug trace of the UDP application is different to the one
in the UDP packet capture, and so something has filled it in correctly,
so maybe checksum offload is happening. 

> None of the packet are compliant with the tftp protocol. This will
> surely make wireshark in trouble when checking an expected checksum...

No: the UDP checksum is independent of the next protocol layer, and so
won't care if the TFTP bit is correct or not.

> Defenitivily, it must not be the reason of my udp sending problem.

It is not your problem for sure, as lwIP receives the UDP packet, thinks
the checksum is correct, and sends a response.  The response gets lots
somewhere in etharp_output() before making it onto the network though.

I notice that in the udp_echo.trace.txt there is the following:

<LF>find_entry: selecting empty entry 1
<LF>etharp_request: sending ARP request.etharp_raw: sending raw ARP
packet.etharp_query: queued packet 215bf0 on ARP entry 1

This is odd for two reasons: (i) it should already have an entry for the
PC's MAC address as it's updated that entry lots already from the other
ARP requests seen on the network earlier; and (ii) the packet it sends
is not an ARP request for the PC's MAC, but a gratuitous ARP of its own
MAC.  I think there is definitely something going wrong here.

Do you have ARP_QUEUEING on?

Kieran