Wireshark - how can I observe little endian big endian difference in byte order using Wireshark?

On Wireshark not recognized protocols you will only see TCP or UDP packets with a "non-parsed" payload field. if the protocol "is" recognized by Wireshark (BOOTP, DHCP, DNS, SMB, HTML, etc etc) you will see that Wireshark "shapes" the TCP/UDP payload area displaying the corresponding recognized higher level protocol fields.

Wireshark has included many dissectors for well known protocols and you can create your own if you want to display your particular protocol payload in a formatted way; see here. https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html

in your case your dissector can deal with the "endianness" of a particular field handling permitted values.

Please consider a byte sequence is just that, "endianness" on the other hand is the first of several nested layers of numeric information representation (like byte size, signed/unsigned, integer/floating, etc.) converting a particular byte sequence into a number.

There is no way to identify if a number was sent as big or little endian, unless there are some very strict constraints upon the numbers, such that they can only be understood in one way, meaning being too large or too little if understood in the wrong way.

The standard way of doing that sort of thing, is to append a header to your packet that supplies information about its contents, such as its payload being big or little endian. Or you could have the packages always sent in either big or little endian, with sender and receiver dynamically swapping bytes if required.

Remember that, as says Wikipedia about the User Datagram Protocol :

It has no handshaking dialogues, and thus exposes the user's program to any unreliability of the underlying network: there is no guarantee of delivery, ordering, or duplicate protection.

UDP is mostly used when data is streamed but the delivery of all packages is not important. For example, a security camera sending video, when it is acceptable for some few frames to be lost when arriving either corrupted or out-of-order.

A server that does the sum of numbers is not a good candidate for UDP, because if packages are lost or corrupted then the sum is wrong. TCP which guarantees the correct delivery is to be preferred here. Building fail-safe measures into your UDP stream, you will soon find yourself re-inventing TCP.

The simplest solution to following incoming messages is to have your server optionally print information to the console. This can be controlled by a parameter specified when invoked, or by a debug pre-processor directive (#ifdef for C/C++).