This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Cannot receive UDP packet from microcontroller

0

I'm currently working on a UDP communication PC <-> ATmega16 (Atmel microcontroller) through the Ethernet. The ATmega16 controls the ENC28J60 (Ethernet module) through SPI. On the PC there is an application that simulates a UDP server/client.

When the packet is sent from the PC to the ATmega16, the packet is received without errors, but when the ATmega16A sends the UDP packet back to the PC, the packet is lost somewhere (the application doesn’t receive it).

The strange thing is that WireShark captures these packets coming to the PC and it seems they are valid. When sending the UDP packets form another PC (PC <-> PC), the packets are received normally.

Turning off Firewall in Windows did not help, and also the same problems appears in Linux. I know that this topic might be wrong for this forum, but can anybody explain why WireShark captures these packets, but my application doesn’t? ATmega16 (192.168.1.3), PC (192.168.1.2), sending and receiving goes through port number 1234.

asked 11 Sep '13, 11:50

punnkt's gravatar image

punnkt
6●1●1●4
accept rate: 0%

edited 11 Sep '13, 12:05

If you can supply a packet capture - on cloudshark or any file sharing site of your choice - then maybe someone can take a look at it and see if anything stands out.

(11 Sep '13, 12:22) cmaynard ♦♦

2 Answers:

1

Based on the capture file provided, Wireshark indicates that the UDP checksum of frame 25 is incorrect, thus the packet will be dropped.

Checksum: 0x2a5b [incorrect, should be 0x2a4b (maybe caused by "UDP checksum offload"?)]

answered 11 Sep '13, 13:30

cmaynard's gravatar image

cmaynard ♦♦
9.4k●10●38●142
accept rate: 20%

The problem was in checksum. I calculate UDP checksum like checksum for ICMP.

Sorry for not answering earlier because the site thinks my comments are spam.

(14 Sep '13, 10:11) punnkt

1

On Windows please run the following command and check if the counters grow while you receive the UDP packets (highlighted below). If so, there is something wrong with the UDP packets.

netstat -s

IPv4 Statistics

Packets Received                   = 1070088
Received Header Errors          = 0
Received Address Errors         = 271
Datagrams Forwarded                = 0
Unknown Protocols Received         = 0
Received Packets Discarded      = 67898
Received Packets Delivered         = 1108133
Output Requests                    = 1979878
Routing Discards                   = 0
Discarded Output Packets           = 5809
Output Packet No Route             = 1
Reassembly Required                = 0
Reassembly Successful              = 0
Reassembly Failures             = 0
Datagrams Successfully Fragmented  = 0
Datagrams Failing Fragmentation    = 0
Fragments Created                  = 0


UDP Statistics for IPv4


Datagrams Received    = 40722
No Ports              = 352
Receive Errors      = 67544
Datagrams Sent        = 61341

BTW: Please check if the destination MAC address is probably a broadcast address (ff:ff:ff:ff:ff:ff) or the IP address (255.255.255.255)?

Please also check that the source/destination ports of the UDP packet are correct, otherwise your Windows/Linux system will not be able to match a socket.

Basically the following values should be identical in both directions (obviously in reverse order):

  • src/dst MAC address. A broadcast address may or may not work
  • src/dst IP address. A broadcast address may or may not work
  • source/destination ports

See a similar problem here: http://goo.gl/KtJPIj

Regards
Kurt

answered 11 Sep ‘13, 13:15

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 11 Sep ‘13, 13:23