An UDP datagram may arrive any time, or my not arrive at all But is an UDP datagram out of errors?

Yes, if it arrives, it will be error free, as error checkin is performed in one of the lower layers of the IP.

Quote:

Original post by Gruik An UDP datagram may arrive any time, or my not arrive at all But is an UDP datagram out of errors?

A UDP packet can:

1. Get lost/dropped/discarded(corruption detected via a simple additive checksum error) and never delivered (a much stronger CRC-based (polynomial) checksum^* can also be implemented by the application).
2. Get duplicated and arrive more than once.
3. Get delivered later than it was sent relative to other packets (out of order).

At the application level, either a UDP packet will show up or it won't. No errors will be generated. Any and all error checking for UDP must be implemented at the application layer (including a stronger CRC-based or cryptographic-strength integrity check). Critical data must be sent via reliable protocol, such as TCP or via a protocol built on top of UDP which implements TCP-like functionality. See this thread for more information.

^*Ethernet provides a CRC for LANs (wraps the UDP packet at a higher layer). Different WANs can use different methods (most likely CRCs). More info here.

There have been cases of routers re-writing packets for legit reasons but because of bugs they corrupt other parts of it. The router then recalculates the checksum based on the corrupted data.

This is one of the reasons why some people advocate having your own checksum even though IP provides one already.

Quote:

Original post by Anon Mike There have been cases of routers re-writing packets for legit reasons but because of bugs they corrupt other parts of it. The router then recalculates the checksum based on the corrupted data. This is one of the reasons why some people advocate having your own checksum even though IP provides one already.

...such as with router packet fragmentation and reconstruction...

Additionally, the standard UDP checksum (additive) is not as effective at detecting errors as CRC32. In order to protect against intentional modification, a cryptographic hash must be used.