First, let's tackle TCP/IP and octets and integers. Not all computers have 8 bit bytes. Some weirdos have 6 bit bytes. I only one I know of is the CDC Cyber series, but I believe that there are more. Or were. Most everyone agrees on 8 bit bytes these days. But the designers of TCP/IP wanted it to work on all computers. They use the term octet as a politically correct term for an 8 bit quantity. TCP/IP does not deal with 8 octet integers. But it does have 2 octet integers which it called "short", and 4 octet integers which it calls "long". Both longs and shorts travel over the wire big-endian. But both are placed on the wire and extracted from it via macros. The macros are called ntohl, htonl, ntohs, and htons. (ntohl, for example, means network to host long). On hp-ux, just type "man htonl" to see a man page on them. These macros solve the problem of integers across a network. On a big-endian system like HP, they are just null macros and are removed by the pre-processor. On some other systems they expand into whatever is required.

It is obvious that this concept can be expanded in both directions. I would write new macros for 8 byte integers. And if I really needed it, I would write macros for bytes as well. It isn't hard to reverse the bits in a byte if that is truely required.

I have never worked with HDLC, and I just looked it up. I can't find proof of this, but I remain skeptical that it reverses its bytes. But if you are dumping data into the information frames with the bytes reversed, I guess that you are stuck with it.

Anyway, what is an application program doing using HDLC? HDLC is a level 2 protocol. That makes as much sense as an application program opening the ethernet device and writing its own ethernet frames. When you do stuff like that, it really starts to sound like you are talking to a directly attached device rather than using a network. Could you describe your network topology?