8

I wrote a simple application which communicates using UDP sockets (in C). Application is simple: clients sends numbers to server, and server computes the sum of them.

Now, I know how can I capture the packets exchanged by client and server, but I wonder how can I, using Wireshark, observe the difference between little endian and big endian byte order for my packets?

Improve this question
7
  • Well first, what do you mean by little endian and big endian byte order for your packets?
    – user253751
    Mar 9, 2017 at 4:26
  • @user20574: I think that user Ferdinand Beyer explained it very well here: stackoverflow.com/questions/701624/…. What I would like to do, to see it in practice. I've already have a code to send simple UDP/TCP messages, but wonder how could I use Wireshark to see this difference in real life.
    – mirx
    Mar 9, 2017 at 15:44
  • You don't need wireshark then, do you? Just use htonl or so on to convert a number and then look at the number.
    – user253751
    Mar 9, 2017 at 21:58
  • 1
    If both your client and server source code adhere to Network Byte Order protocols then this whole endian-ness thing becomes irrelevant (which is the point of having these protocols in the first place) See for example stackoverflow.com/q/19207745/31326
    – Peter M
    Mar 10, 2017 at 20:49
  • 1
    The internet packet headers are always in network byte order, i.e. big-endian. For example, the most significant byte of an IP address (e.g. the 192 in 192.68...) is sent first. The bytes of your payload otoh are in whatever order they're in your buffer when you send them. If your buffer includes an unsigned long, and you're on a little-endian machine, then the u-long will be sent with its least significant byte first (unless you've used htonl on it, which you generally should if you're writing a standard-compliant app).
    – Jamie Hanrahan
    Mar 11, 2017 at 8:49

3 Answers 3

Reset to default
5
+25

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.

Improve this answer
3

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++).

Improve this answer
3
  • 1
    A nitpick: UDP packets are no more likely to be corrupted than the TCP bitstream. Both use the relatively weak 16-bit Internet checksum. You are right in the packet loss problem, though.
    – juhist
    Mar 11, 2017 at 11:07
  • @juhist: A UDP packet may contain multiple user payloads or even partial user payloads - correctness is the responsibility of sender & receiver.
    – harrymc
    Mar 11, 2017 at 11:34
  • To elaborate on the comment of the data can only be understood one way, an example would a Byte Order Mark. For instance UTF-16 files will begin with 0xFFFE or 0xFEFF depending on their endianess.
    – Muh Fugen
    Mar 12, 2017 at 19:57
1

Observe the values in the section that describes the breakdown for you and compare to the raw hex. Look at a field that is greater than one byte and look and see if in raw hex is in little or big endian. I.e. val(16)in breakdown and in the hexdump (since its a 2 byte field) it shows: 00 10 for big endian and it would show 10 00 for little endian. Hope that helps.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .